Welcome back! We'll look at what keeping an app healthy costs after launch — no surprises. 📊
| Quick answer: plan a yearly maintenance budget, not a surprise invoice; updates, backups and store fees keep running whether you touch the app or not. |
Apps do not die at launch; they die at month eight 🧾, when the build budget is spent, the store has pushed an update, and somebody has to be paid to keep the thing running. Budget this before you budget the build — it is the difference between an asset and an expensive experiment.
The Recurring Lines
| Line | Typical cost | Frequency |
|---|---|---|
| Hosting and database | R300 – R3,000 | Monthly |
| Store developer accounts | Annual fees | Yearly |
| Notifications and messaging | Per use | Monthly |
| Maintenance and updates | 15% – 20% of build | Yearly |
Why Updates Are Not Optional 🔄
Phone operating systems change how permissions, notifications and background work behave. Third-party services change their rules and their prices. An app that is never updated does not stay neutral — it drifts out of compliance until a store update or a service change breaks the part your customers use most.
Support Is the Real Cost 🛡️
Someone must answer when a driver cannot log in at 6am, or a payment fails on a Saturday. Agree the support terms in writing: hours, response time, and what counts as a bug versus a new request. Most budget blowouts come from that boundary being vague, not from the work itself.
The First Ninety Days After Launch
Month one: watch everything. Every crash, every confusion, every question someone asks twice. Month two: fix the top three causes of support tickets, not the prettiest suggestions. Month three: make the first honest decision about adding features, based on what people actually do rather than what they said they wanted in the planning meetings.
Apps that get this rhythm right become cheaper to run every quarter, because complaints turn into fixes instead of repetition. Apps that skip it keep the same five complaints forever and slowly lose users to workarounds — a spreadsheet here, a phone call there — until only the developers still believe the app is being used.
What a Healthy Support Contract Looks Like
Named hours, a stated response time, a bug-versus-request boundary, and a monthly summary of what was fixed. Add a small retainer for improvements so minor updates do not each become a formal project. Pricing varies in South Africa, but the shape does not: predictable, written down, and reviewed quarterly.
One number to insist on: how many hours are included. “Unlimited support” is marketing. A stated bucket, with an agreed hourly rate beyond it, is a relationship you can budget for and a developer can staff for.
A Simple Repair Menu
Most maintenance work falls into a handful of categories with fairly predictable effort. Knowing the shape of them lets you budget instead of brace.
Minor screen or content fix: hours. A broken integration or payment gateway: a day or two, plus the provider’s own delays. Operating-system updates and re-testing: periodic, budget a small block each quarter. New features: quoted per feature, and should always arrive with a written scope. Emergency outages: priced at an increased rate, which is fair — and worth avoiding with the routine maintenance that stops most of them from happening.
Questions for Your Maintenance Provider
| Ask | A good answer sounds like |
|---|---|
| What hours are covered? | Named hours, stated plainly |
| What is the response time? | A number, not “as soon as possible” |
| What counts as a bug? | A written boundary you both agree on |
| How are changes priced? | An hourly rate, or blocks of hours |
| Who else can access the code? | You, on request, at any time |
Five answers, one page, agreed in writing. Apps with this page attached cost less per year than apps without it, mostly because nobody argues about scope while the system is down.
Two Ways Owners Save on Support
Bundle your requests. A list of six small fixes sent as one job costs far fewer hours than six separate messages across six weeks, because every separate job carries setup, testing and deployment time. Book a fortnightly or monthly slot and collect items for it.
Then report bugs so they can be reproduced. A screenshot, the step that caused it, and what you expected takes a minute to capture and can halve the billable time spent guessing. Providers who receive that kind of report solve problems faster, and the savings compound quarter after quarter.
Neither habit reduces quality. Both reduce the two costs that grow fastest without anyone deciding they should: repetition and diagnosis.
Frequently Asked Questions
Can I stop paying maintenance?
The app keeps working for a while, then breaks in small ways. Treat maintenance as part of the product, not a subscription you can cancel without consequences.
What does an update actually cost?
Small compatibility updates are hours; feature updates are projects. Both are predictable if you keep a written list.
How do I keep the budget honest ⏳?
Ask for a monthly summary: what was updated, what was requested, what it cost. Transparency is the cheapest feature you can buy.
Who owns the app if we part ways?
You do, if the contract says so and the accounts are in your name. Download the source code every quarter, keep the store listings in your own account, and store credentials somewhere the business controls — never only with the developer.
Who fixes the app if the developer closes down?
If the code and accounts are yours, any competent team can take over — which is why ownership is the first line of the contract, not the last. Keep a copy of the code yourself, off any single provider’s systems.
Do I need to update the app for new phone models?
Not for models, but yes for operating-system versions: permissions, notifications and background rules change most years. That work is exactly what the maintenance budget exists for.
Stop guessing what your app will cost. See how apps are priced, phase by phaseGet my free app quotation |
