Which Ongoing Costs Should You Budget for After Your App Launches

How much does it cost to keep an app running? Plan for somewhere around 15 to 20 per cent of your original build budget every single year, which is the rule of thumb published by Imaginovation. The cost to maintain an app is usually at its highest in the twelve months straight after launch, then it settles into something steadier. That's the short version, and it's the number most founders only meet when the first invoice arrives.

The money you spend after launch is the money that keeps the product alive, and it's rarely in the first budget.

We worked on a well funded sports club app designed to handle finances, games, schedules and players across different sports. The client wanted everything live at once, so the build ran twelve to fourteen months instead of three to four, and the budget almost doubled before anything reached a store. All of that was forecast and advised against at the time.

The same maths applies the day after you go live. Servers charge by use, stores take a cut of every payment, operating systems change twice a year, and the things you cut to make the launch date are still sitting there waiting to be paid for. What follows is a walk through each of those costs, where they come from, and what we'd set aside.

Hosting, servers and the bills that grow with your users

Hosting is the one running cost that moves on its own. A build price gets agreed and stays agreed, but servers charge you for what people actually do, so the bill follows your success upwards.

On a niche trading platform we worked on, we modelled user acquisition at the start of each month, monthly churn, and how many transactions a person makes across the whole life of using the product. That work was done for the revenue forecast. The same figures also tell you how much traffic you're paying to serve, which is why we'd rather do the modelling once and use it twice.

The parts of app running costs that climb with usage are fairly predictable.

• Storage for photos, video and anything else people upload
• Push notifications and in-app messaging
• Third party services you pay per call, like maps, search or payments
• Transactional email and SMS verification
• Backups, logging and anything you keep for audit reasons

A quiet product costs very little to host. A product with real traction costs real money, and that's the version you want. The mistake is budgeting for the quiet version and then treating the busy version as an unpleasant surprise.

App store fees, subscriptions and payment commissions

Apple and Google take a share of everything that moves through their stores, somewhere between 15 and 30 per cent depending on your revenue and how long a subscriber has been with you, as set out by SplitMetrics. Apple charges 15 per cent for developers under a million dollars a year, and 15 per cent on subscription renewals after year one against 30 per cent in year one. Google charges 15 per cent on the first million in annual earnings and 30 per cent above it. That share never stops.

How you show your own fees matters too. We learned this the hard way on a travel product. Wrapping the platform fee into one single total price looked simpler and cleaner, and it made people anxious about hidden charges. Breaking the fee out as its own line gave them confidence they were seeing the full picture, even though we were showing them more information, because a platform fee is what they expect to see in a travel app.

Alongside the store cut, budget for the yearly developer programme fee on each platform, payment processing on any web checkout, subscription billing tools, refunds and chargebacks, and currency conversion if you sell outside your home market.

Keeping up with iOS and Android releases

Apple and Google ship a major release every year, with smaller ones in between, and each release can change how something in your product behaves. Permissions move, design rules shift, old libraries stop being supported, and a screen that worked fine in June needs attention by September.

On the sports club app, we advised launching with a single sport, on a single platform, as an MVP. The client pushed back through the whole process and wanted everything ready before anything went live. The part of that advice people tend to miss is the long tail. Every platform you keep is a commitment to keep testing, fixing and resubmitting on that platform for as long as the product exists.

Every platform you support is a yearly subscription you pay in developer time.

Practically, this means a few days of work around each major OS release, sometimes more if you lean on device features like the camera, location or health data. It also means keeping a developer account in good standing and keeping your build tools current, because falling two years behind on a framework turns a day of work into a month of work. Budget for it as a scheduled job rather than an emergency, and it stays small.

Bug fixing, monitoring and crash response

Every product ships with things nobody caught. Real devices, patchy signal and people using features in orders you never imagined will find them within days.

We worked on a football focused social media app where the client wanted a streamlined first release but had a budget that didn't match the premium experience they expected. The client wanted the low budget without the limitations that come with it. We had several conversations trying to line up expectations with the financial reality, and the product did get finished, with compromises on features because the client chose to put money into areas we considered lower priority. Compromises like that don't vanish at launch. They move into the maintenance column.

Agree a crash response window before you launch, not after. Something like "critical issues in 24 hours, everything else in the next release" gives everyone a shared definition of urgent and stops every bug becoming an emergency.

The tooling itself is cheap. Crash reporting, performance monitoring and error alerting sit in the low hundreds a month for most lifestyle products, and some tiers are free. The money goes on the people who read the reports, work out which crashes affect the most users, fix them and ship a release through review. Two or three days a month is a sensible starting point for a product with a small but active audience.

User support, moderation and running the service day to day

If your product lets people talk to each other, you've taken on a permanent human cost. There's no tool that removes it.

On a dating app project we worked on, the whole premise was verified profiles and keeping bots out. The verification during onboarding was rigorous. The messaging that shipped was generic and allowed automated messages and fake messages straight through, which undid the work that happened at the front door. A promise about safety is a promise you keep every day, with people, tools and time, long after the feature itself is finished.

Day to day running costs in this area usually cover a handful of jobs.

• Answering support email and in-app messages
• Reviewing reported content and accounts
• Password resets, refunds and account recovery
• Replying to app store reviews
• Watching for spam patterns and shutting them down

For a smaller lifestyle product, this often starts as a few hours a week for someone in the founding team. That works until it doesn't. Once volume grows, it becomes a part time role, and the honest thing to do is put a figure against it in the forecast rather than quietly absorbing it into someone's evenings.

Rework: paying for decisions made before launch

Some of the biggest costs after launch are decisions that were made months earlier, usually to save time.

On that same dating app, the client wanted to skip discovery around the messaging side and put the whole discovery budget into onboarding. What got built was a generic messaging feature that contradicted the core idea of the product, because it allowed the exact automated and fake messages the verification existed to prevent. The whole messaging section had to be rewritten. That came to roughly £15,000 of extra budget and about two months of extra work, on top of everything already spent.

Nothing about that was unusual. Discovery on one section of a product costs a fraction of rewriting it, and the gap between those two numbers is the clearest argument for doing the thinking up front. The trouble is that the saving is visible immediately and the bill arrives much later, by which point it looks like a maintenance problem rather than a planning one.

When you're forecasting your first year, leave room for one rewrite of something. Not because the team is careless, but because every product makes at least one assumption that the market disagrees with, and you'll want the money available to respond to it.

Finishing what you cut: second platforms and deferred features

Features you drop to protect a launch date are still on the books. They've been deferred, and deferred work has a price.

On a bootstrapped social football platform, the client originally wanted iOS and Android together. Scope kept growing, more features kept being requested, and the design kept changing, driven by one of their own team without much thought for the development impact. Budget got critically tight. Midway through, we decided to pause Android entirely and move all the remaining budget to iOS, so they launched with an iOS product carrying as many features as we could get through, and roughly half the potential market unserved.

That was the right call with the money available. It also created a known future cost.

Pausing Android was the right call, and it left half the market waiting.

A second platform is rarely half the price of the first, because the thinking and the backend are already done, though it's never a simple port either. Design needs adapting, testing doubles, and from then on you're maintaining two codebases through every OS release. Treat the second platform as a funded project with its own start date, decided on the evidence from the first one, rather than a vague intention sitting in a roadmap.

Marketing and user acquisition after day one

Acquisition is a permanent line in the budget, and the cheapest version of it lives inside the product.

On two projects, a gaming app for art enthusiasts and a grassroots football product, we advised against running paid social campaigns or announcing a fixed launch date until after a soft launch. Both clients picked an arbitrary date and started drip feeding social posts carrying it. Both projects then had changes and rework that pushed the launch past the announced date, so both clients had to backpedal publicly and reset expectations more than once. The posts hinting at the product were fine. The dates were the mistake, and they cost real audience trust and real marketing budget.

On a travel OTA aimed at people in their twenties and thirties booking group trips, we tried the usual tactics after launch. Referral discounts, push notifications to bring people back, social sharing of trips, email campaigns through Mailchimp. What actually moved the numbers was the booking flow itself. When somebody organised a trip, the app asked every traveller in the group to download it to communicate and submit passport details, so one person booking for ten gave us nine more users, and each of those could start a group of their own.

Before you spend anything on paid acquisition, check whether the product has a natural reason for one user to bring in another. That mechanic costs development time once and then works for free.

Security, data protection and compliance obligations

Holding personal data is an ongoing duty, and the weight of it depends entirely on what you hold.

The travel product collected passport details from every traveller in a group, which is about as sensitive as consumer data gets. That shapes the running costs from then on, because you're committing to encryption, access controls, retention rules and a clear answer whenever somebody asks what you've got on them and asks you to delete it. A beauty brand holding skin concerns and purchase history carries a lighter load than that, though it's the same set of obligations in a smaller form.

The yearly items worth putting a figure against are fairly stable.

• SSL certificates and domain renewals
• Patching libraries and dependencies when vulnerabilities are published
• A penetration test if you handle payments or sensitive data
• Privacy policy and consent updates when the law or the product changes
• Time to handle data access and deletion requests

Keep a simple list of every third party service your app talks to and what data each one receives. You'll need it for your privacy policy, and you'll need it faster than you expect the first time a user asks.

Paying for the team: retainer, in-house or ad hoc

The largest ongoing number in most forecasts is people. A team that stays close to the product is the difference between a two day fix and a two week one, because somebody already knows why the code looks the way it does.

On the sports club app, twelve to fourteen months of continuous development was the single biggest cost on the project, and the budget almost doubled over that period. Long-running teams are expensive in a way that per-hour quotes hide, which is why the shape of the arrangement matters as much as the rate.

In-house looks cheapest on a salary line and rarely is. Toptal's research, cited by Sidekick Interactive, puts the full cost of a new in-house developer at up to 2.7 times their base salary once you add recruitment, tax, benefits and overhead. For a single app with modest monthly work, a retainer usually wins. Once you're running several products with daily changes, hiring starts to make sense.

Forecasting running costs against revenue

Running costs only mean something next to the money coming in. A thousand a month is nothing on a product turning over fifty thousand and fatal on one turning over two.

The hardest forecast we've worked on was the niche trading platform, because revenue came from commission on trades rather than a flat fee. That made the modelling far more involved. We had to factor in user acquisition at the start of each month, monthly churn, how many transactions somebody makes across the life of using the product, the conversion rate between downloads and users who actually generate revenue, commission rates, platform fees and an estimate for disputes. Mapping all of that out gave us credible one, three and five year projections to put in front of investors.

A forecast that only counts downloads tells you nothing about whether the product pays for itself.

Most lifestyle products are simpler than that, though the discipline is the same. Work out what a user is worth over their lifetime, what it costs to acquire one, and what it costs to serve one for a year. If serving costs more than earning, more marketing makes the problem bigger. That's a maths problem you want to find in a spreadsheet rather than in your bank balance.

How much to set aside each year

A client we worked with came from the music world, and they knew exactly what it had cost them to produce their recordings. They wanted to recoup that within weeks of launching, which isn't how consumer app economics work. It stopped them considering a lower price or a longer volume play, because every pricing conversation kept circling back to what they'd already spent.

Working out the cost to maintain an app

Stormotion puts first year maintenance at up to 50 per cent of total development cost, dropping to around 15 to 25 per cent in the years after. That matches the pattern on products we've worked on, where year one carries the bug fixing, the rework and the features that were cut to make the date.

1. Take your total build cost and set aside half of it for year one.
2. Split that pot into fixed costs, hosting and fees, and flexible costs, which is development time.
3. Ring-fence a slice for one rewrite of a feature the market rejects.
4. Drop to around a fifth of build cost from year two, and review it every quarter.

Write the yearly running cost into your first business case, before the build starts. A product you can afford to build and can't afford to run is the most expensive outcome available.

Conclusion

The honest answer to how much it costs to keep an app running is that it's a yearly commitment of roughly a fifth of what you spent building it, with a heavier first year while the product settles. Hosting grows with your users. The stores take their cut of everything. Apple and Google change the ground twice a year. The features you deferred and the discovery you skipped both turn up later with a price attached, as the £15,000 messaging rewrite on that dating app showed.

None of this is an argument for spending longer before launch chasing a perfect product. You're far better off launching something that works, listening to what resonates with the market and what doesn't, and then putting the next slice of budget into the thing people actually asked for. That only works if the budget for the next slice exists, which is the whole reason to plan running costs before you start rather than after.

If you're weighing up what a product will cost you in year two and year three, we're happy to think it through with you. Let's talk about your app running costs.

Frequently Asked Questions