After launch — questions we get asked
These come from founders who have watched an app go quiet after launch, with bugs nobody fixes and store updates nobody makes. Behind them is the worry that the build is the easy part and running it is where the cost hides. The answers cover maintenance, defects, changes, outages, and taking over platforms other teams built.
10 questions · answered by Taimoor Sikander, founder
Do you leave at launch?
No. A platform that stops working stops paying people. Maintenance is standard on every build. Launch is when real customers find what testing missed, so we stay for it. We operate FindWorker ourselves, so we know a marketplace needs looking after for every week it is live, not only the week it opens.
What does maintenance cover?
Fixes, dependency and store updates, monitoring, and small changes. Dependencies are the outside libraries and services the platform relies on; when they change, the platform has to keep up. Monitoring means we watch for errors rather than wait for a report. Maintenance is priced monthly once the included period, agreed in your scope, has ended.
What does a defect cost?
Nothing. If we built it wrong, we fix it. A defect is anything that does not work the way the written scope says it should. Fixing it is our cost, during the build and after launch. That is one reason every scope is written down: it is how both sides can tell a defect from a change.
What does a change cost?
We price it before we build it, and you decide. Nothing gets added quietly. A change is anything that differs from the written scope, such as a new feature, another payment rail or a different flow. Small changes can fall under maintenance; larger ones become a phase of their own, scoped and priced the same way.
What happens if the platform goes down?
We fix it, and you hear from us while we do. Monitoring is part of maintenance, so the aim is to know before your customers tell you. If the cause is a defect, the fix costs nothing. If it is a third-party outage, such as a payment provider or hosting company, we tell you what is affected and what we are doing about it.
How do we report a bug after launch?
In the shared channel, with what happened, on which device, and a screenshot if you have one. We confirm we have it, tell you whether it is a defect or a change, and fix defects at no cost. A clear report from your team or a customer is the fastest way to a fix, so we ask for the same details every time.
Will the platform cope as we grow?
It depends on three things: how many people use it at the same time, how much data each job creates, and which third-party services it relies on. We build for the scale in your scope and tell you what would need to change beyond it. Scaling work is priced as a phase when your numbers justify it, not bought up front on a guess.
Can we hire our own developer and still work with you?
Yes. Your repository and accounts are yours, so adding your own developer is a matter of giving them access. We agree who looks after which part of the platform, so two people are not changing the same code at once. The handover documents are written for exactly this: someone new picking the platform up.
What happens if we stop paying for maintenance?
The platform keeps running, and it is still yours. Nothing is switched off. Over time, though, store requirements, phone operating systems and third-party services change, and an app nobody updates will eventually break or be removed from the stores. If you stop, the handover documents let another team or your own developer take the work on.
Can you take over a platform another team built?
Yes, after an audit. Sometimes it is cheaper to replace than to keep; we tell you which. The audit looks at the code, the accounts and who holds the keys, because inherited code is sometimes missing the parts you need to run it. Support for a platform another team built is priced separately, because we have to learn it first.
Plan your build in two minutes.
No call. A few guided questions, then a tailored quote — usually within one business day.
Or send us the idea in three sentences on WhatsApp, or email support@codingwitht.com.