A lot of software projects are planned as if launch were the end. The budget runs to launch day, the team moves on, and the product is left to look after itself.
Software does not look after itself. Launch is the first day your app meets real users, real devices and real data, and the weeks after it are when you learn the most. Here is what that period actually involves.
The first weeks: real users find real bugs
No test plan covers everything that thousands of real users will do. Expect:
- Crashes on devices nobody tested. An older Android model, an unusual screen size, a phone with its language set to something unexpected.
- Flows used in the wrong order. Users will press back in the middle of a payment, open the app from a stale notification, and sign in on two phones at once.
- Data nobody imagined. Names with apostrophes, addresses in two languages, phone numbers typed with spaces and dashes.
None of this means the build was poor. It means the app is now in the real world. What matters is how fast you see these problems and fix them, which is why crash reporting and error logging should be live before launch, not added after the first complaint.
Ongoing: the platforms keep moving
Even if you never add a feature, your app has to keep up with the ground moving under it:
- Operating system updates. Apple and Google release major versions every year. Some change how permissions, notifications or background work behave, and some break things quietly.
- Store requirements. Both stores regularly raise the minimum technical standards an app must meet to stay listed or to publish updates. An app nobody has touched for a year may not be allowed to ship an urgent fix until it is brought up to date.
- Dependencies. Every app is built on libraries and services that release security fixes and retire old versions. Skipping those updates for long enough turns a routine update into a project.
- Third-party services. Payment gateways, maps and SMS providers change their APIs, prices and terms. An integration that worked at launch can stop working without anyone on your side changing anything.
The things that cost money every month
Budget for these before launch, not when the first invoice arrives:
- Hosting and servers, which grow with your users.
- Third-party services: SMS, email, maps and storage, usually billed by usage.
- Developer accounts for the app stores.
- Monitoring and backups. Cheap, and the difference between a bad hour and a lost week.
The part that is actually the opportunity
Once real people use the product, you get something you never had during the build: evidence. Which screens they use, where they drop off, what they ask support for, and what they try to do that the app does not allow.
That is the input for version two, and it is far better than anything decided in a meeting before launch. The teams that improve fastest after launch are the ones that planned for it: measurement in place, a list of what was deliberately left out, and someone with time set aside to act on what they learn.
Plan it before you ship
Before launch, agree on three things:
- Who fixes things, and how fast, when something breaks.
- Who keeps the app current with OS updates, store requirements and security fixes.
- How improvements get decided and paid for: a monthly arrangement, a budget per change, or a planned second phase.
Any of these can work. What does not work is discovering after launch that nobody is responsible. By then the first bug report is already waiting.
Written by predev. Solutions