Launched, and then nobody
The app went live and people use it. Customers book through it, or staff run part of the business on it. The team that built it was a project team: an agency, a contractor, a developer who has since left. Their job ended at launch.
Now small things pile up. A customer reports that password reset emails never arrive. The iOS version gets a warning from Apple about an outdated SDK. Someone wants to add a field to a form, and nobody knows where to start. You are not even sure who would get an email if the server stopped responding.
Why software does not stay finished
An app sits on top of things that keep changing, even when your own code does not.
| What changes underneath | What happens if nobody responds |
|---|---|
| Operating system and browser updates | Layouts break or features stop working on newer devices |
| App store requirements | Updates are rejected, or the app is eventually removed from listings |
| Libraries and frameworks | Security fixes stop, and upgrading later gets harder |
| Third-party APIs (payments, email, maps) | Old versions are switched off and features fail |
| Certificates, domains, keys | They expire, usually on a weekend |
Build teams often do not plan for this because it is not part of the build contract. So the app looks finished on launch day and starts decaying the next morning.
What an unmaintained app costs
At first, very little, which is why it gets ignored. Then a payment provider retires an API version and checkout stops. Or a security flaw in a library gets published and your app is running the vulnerable version. Or a small change request that should be simple turns into a big job because the framework is now several major versions behind.
Security is the part people underestimate. Public vulnerabilities in popular libraries are published and then actively scanned for. An app that has not been updated since launch is exactly what those scans look for, and the first sign of a problem may be customer data appearing somewhere it should not.
The staff cost is quieter. People work around the bugs. Enquiries about the app go to whoever is most technical in the office, who then spends an afternoon searching forums.
How we take over maintenance
- Take stock. We get access to the code, hosting, app store accounts and third-party services, confirm they are owned by your business, and list everything the app depends on.
- Get it building. We set up a local and staging build, because an app that nobody can build cannot be patched when something urgent comes up.
- Add monitoring. Uptime checks, error tracking and alerts for things like certificate expiry go to named people, so faults are seen before customers report them.
- Schedule updates. Dependencies, frameworks and SDKs are updated regularly in small steps, tested on staging first, instead of in one painful jump years later.
- Run a single queue for fixes and small changes. You raise requests in one place, see their status and agree priorities with us.
- Keep documentation current. Setup, deployment and the reasons behind changes are written down in the repository, so you are not locked in to us.
How much maintenance an app needs varies a lot. A simple internal tool may need little beyond updates and monitoring. A customer-facing mobile app with payments needs more attention. We look at yours and say which it is.
Day to day, afterwards
When something breaks, someone already knows, and there is a known person responsible for it. Updates happen on a schedule rather than in a crisis. Small improvements your team asks for actually get built. And you have a written record of how the app is put together, so the next conversation with any developer starts from facts.
Is this you?
- The people who built your app are no longer involved.
- Nobody would notice quickly if it went down.
- Change requests have been waiting because there is nobody to do them.
- You have had warnings from app stores, hosting providers or third-party services that you have not acted on.
- You are not sure whether the libraries it uses are still supported.