Launching an app isn't the finish line. Operating system updates, bug fixes and user feedback keep going. Here's what to budget time for.
An app is closer to a shop than a brochure: it needs looking after. Phones update, libraries get patched and users find things you didn't. Budgeting for this up front avoids a nasty surprise six months in.
Apple and Google release new operating system versions every year and change what's required of apps. Sometimes a store will require a minimum target version. Skipping this can mean your app stops being updatable or listed.
Every library your app uses can develop vulnerabilities. Someone needs to apply updates, test them and release. The longer this is left, the harder and riskier the catch-up becomes.
Crash reporting tells you what's breaking before users complain. Decide who answers support emails and store reviews, and how bugs get prioritised.
Real usage shows what to build next. A sensible plan reserves some capacity for new features alongside upkeep. Neglect leads to what we describe in our piece on technical debt. A common rule of thumb is to set aside a meaningful yearly proportion of the original build cost for upkeep, but the right figure depends on your app.
We can support and maintain apps we built, or take over ones we didn't.
Start a conversation →Not safely. Working today doesn't mean working after the next OS release or library vulnerability.
Often, yes. We'd start with a review of the code and setup to see what condition it's in.
