The build is the deposit, not the price
App budgets are written for the launch and consumed by the years afterwards. The recurring line items are predictable, and almost nobody puts them in the quote.
Plan for a meaningful annual cost that continues whether or not you change anything, because both mobile platforms release a new version every year and an app that is not updated eventually stops being accepted. The recurring items are platform upkeep, dependency updates, store compliance and the ability to ship a fix quickly.
Why an unchanged app still costs money
Mobile platforms move underneath you. Every year brings a new operating system version, new device sizes, new permission rules and a raised minimum for what the stores will accept from a new submission.
An app nobody touches does not stay still, it drifts out of compliance. The first sign is usually a rejected update at the worst possible moment, when a fix is urgent and the app now needs a month of catching up before anything can be shipped at all.
The lines that recur
None of these are surprises. They are simply absent from most build quotes, which is why the second year feels like a new project rather than a continuation.
- Developer accounts on both stores, renewed annually
- Yearly platform updates and testing on current devices
- Dependency and security updates for libraries you did not write
- Backend hosting, notifications and file storage
- Crash reporting, and somebody who reads it
- Store listing upkeep, screenshots and privacy declarations
A worked example, with your own numbers to fill in
Suppose the build is quoted at one hundred thousand of your currency. A common way to plan is to reserve a share of that figure each year for upkeep, then add hosting and store fees on top, and treat anything new as a separate budget.
The point of the exercise is not the percentage, which will vary with how much the app does. It is that the number is not zero and it is not optional, so it belongs in the approval alongside the build rather than arriving as a surprise in month fourteen.
How to make the number smaller
Fewer dependencies, fewer platforms and less custom infrastructure. Every library added is a thing somebody else may break, and every service you run yourself is a thing you must patch.
The largest saving is deciding honestly which parts must be in the app at all. Content, help pages and anything that changes often are cheaper and faster to serve from the web inside the app than to release through a store review.
What to take from this
- 01The platforms change every year whether your app does or not
- 02Store accounts, dependency updates and crash reports are permanent lines
- 03Budget upkeep in the same approval as the build
- 04Fewer dependencies and less custom infrastructure directly lower the annual cost
Ask the question directly
- What if we simply do not update it?
- It keeps working on installed devices for a while, then breaks for people on new phones, and eventually a required update cannot be submitted without significant catch-up work first.
- Does a cross-platform framework reduce this?
- It reduces duplicated development. The framework itself has major releases you must follow, so it moves the upkeep rather than removing it.
- Who should hold the developer accounts?
- Your company, always, with the agency added as a user. The accounts hold your app identity and your reviews, and moving an app between accounts is possible but tedious and best avoided.
Related answers
Web development
New builds, rescues and re-platforms, measured against what the site earns rather than against how it looks. The brand system that carries it is built in the same engagement.
Bring the decision you are stuck on
A call, forty five minutes, no deck. We will tell you if we are the wrong firm.