An app costs more to keep running than it cost to build, and most founders only budget for the build. A working app is less a thing you own outright than a thing you rent from the platforms it runs on, and the rent comes due whether you touch the code or not. A common industry rule of thumb puts yearly maintenance at fifteen to twenty-five per cent of what the app cost to make, and the first year often runs higher while the rough edges get sorted out. Over three or four years that comes to more than the original invoice. If your plan stops at launch day, it is missing most of the cost.
So what does that money buy, because maintenance sounds like fixing bugs and it is a good deal more than that. Some of it is keeping the lights on: the servers the app talks to, the services you rent to send email or take payments, the developer accounts themselves. Apple charges ninety-nine dollars a year to keep an app in its store, or the app comes down. Google charges twenty-five dollars once. Those are the small, predictable costs. The bigger ones are the work behind them: fixing what breaks, closing security holes before someone else finds them, and keeping up with the phones the app runs on.
That last part is the one people do not see coming. Apple and Google ship a major update to their operating systems every year, and each one can break something in an app that worked fine the week before. An app nobody maintains does not sit still, it rots. It starts crashing on the newest phones, then gets flagged, then gets pulled from the store for being too far behind. Leaving an app alone does not save the money, it defers a bill that grows while you look away, because a year of skipped updates is a harder and dearer job to catch up on than a year of small ones.
It helps to split the yearly cost in two, because the halves are not the same purchase. There is keeping it alive, the hosting and the fixes and the security, which is not optional and does not make the app any better. And there is making it better, the improvements you choose once real people are using it. The first is a running cost you should assume from the day you decide to build. The second is where the app earns back what you spent, and it is the part worth a real team, because it takes someone who knows the product and can tell a change that matters from one that only feels busy.
Then there is who does the work, and the cheapest-looking answer is often the expensive one. The team that built the app is usually the fastest to maintain it, because they already hold the whole thing in their heads. Handing it to a cheaper freelancer later can work, but only if the app was built cleanly enough for a stranger to pick up, and you will not know whether it was until they try. This is the quiet case for caring how an app is built in the first place. A tidy codebase is cheap to keep. A rushed one charges you every year for the corners that were cut to save money at the start.
How much should you set aside, then. Take what the build costs and plan for at least a fifth of it again each year, before you have added a single new feature. If the app is central to the business, budget nearer a third and treat the improvement as part of the product rather than an afterthought. And ask, before the build even starts, what the running cost will be, because a studio that cannot answer that has not thought past launch day.
Before you approve a number to build an app, ask for the second number: what it costs to keep running for the next three years. Put the two side by side and you have the full price of the decision, which is the one you want to be weighing. If nobody will give you that second number, better to learn it now, while it is still a conversation and not a live app slowly falling behind.