What It Really Costs to Launch a Mobile App

What It Really Costs to Launch a Mobile App

My team and I are currently building a consumer mobile app. I won’t tell you what it is just yet; that moment will come. But over the past few months I’ve been asked the same question again and again by founders who want to build an app of their own: “How much does it cost?” And every time, I’ve answered with another question: “How much does what cost, exactly?”

I’m not dodging. Most people who ask are only thinking about the coding. And coding is often just one part of the bill. So I’ve put down on paper, as honestly as I can, where the money actually goes when you launch a mobile app. No made-up numbers and no pretty case studies. Just the categories you only notice after you’ve paid for them.

Discovery and design: the part everyone wants to skip

Before anyone writes a line of code, you need to know what you’re building and for whom. That means talking to potential users, sketching flows on paper, wireframes, then interface design (UX/UI) and a prototype you can put in someone’s hands. It looks like a luxury. It isn’t. Every hour spent here saves you days of code that would end up in the bin.

A few years ago I wrote about how to evaluate a startup in 30 minutes. The first question applies just as much to apps: what problem are you solving, and who has it badly enough to install your app? If you can’t answer that clearly, the most beautiful design in the world won’t save you.

Development: it’s not one app, it’s four products

When you say “an app”, you’re really saying at least four things: the iOS app, the Android app, the backend (servers, database, the logic behind it all) and an admin panel, where your team moderates, replies and sees what’s going on. The admin panel is almost always forgotten in the budget and almost always needed from day one.

Then comes the choice of technology. Native apps, written separately for iOS and Android, give you the best performance and full access to the phone’s features, but they mean two codebases to maintain. Cross-platform frameworks such as Flutter or React Native let you use a single codebase for both. For most early-stage consumer apps, cross-platform is a sensible choice: you ship faster with a smaller team. It isn’t magic, and some features still need native code, but the cost difference is real.

Infrastructure and third-party services: the bill that grows with success

Here’s the elegant trap: at the start, everything looks cheap. Cloud servers, push notifications, SMS for phone number verification, transactional email, maps, analytics, storage. Many services have free tiers or low prices at low volume.

The problem shows up when the app works. Most of these services are pay-as-you-go: per SMS, per thousand requests, per gigabyte stored or transferred. If your app has video, be very careful: storing and especially streaming video are among the most expensive things you can put into a consumer app. Run the numbers for ten times, then a hundred times, the users you expect in month one. If the figure scares you, better to find out now.

App stores: small fees and big commissions

To publish on the App Store you need an Apple Developer Program membership, which costs 99 dollars a year. For Google Play you pay a one-time 25 dollars. Those are the small amounts.

The big amounts are the commissions. If you sell subscriptions or digital content inside the app, Apple and Google take 30% as standard. For small developers, through their dedicated programs, the commission drops to 15%. Either way, it’s a serious slice of revenue, and it has to be in your business model from the start, not discovered on the first payout. There’s a hidden cost here too: the review process. Apple can reject a release, and every rejection means days of delay and extra hours for the team.

Testing, legal and moderation

Quality assurance (QA) doesn’t mean the founder checks it on their own phone and says it works. It means different phones, different operating system versions, small and large screens, weak connections. Either you buy a few devices or you pay for real-device testing services. Either way, it costs.

The legal side is mandatory too: a privacy policy, terms and conditions, GDPR compliance (the EU’s data protection rules), agreements with the vendors that process your data. I once wrote a practical guide to GDPR for online stores, and the principles are the same. And if users can upload text, photos or video, you need moderation: rules, automated tools and people. Moderation isn’t a project; it’s a monthly cost.

Launch marketing: the biggest and most underestimated cost

This is where almost everyone gets it wrong. They pour their whole budget into building the app and arrive at launch day with empty pockets. But there are millions of apps in the stores. Nobody stumbles onto yours by accident.

User acquisition, whether through paid ads, influencers, or content and PR, is usually the largest line in the budget. My view, strictly as opinion and very roughly: for a consumer app, it’s healthy to expect first-year marketing to cost at least as much as the build, and often more. If your business plan doesn’t have this line at all, you don’t have a plan; you have a hope.

Maintenance: an app is never “done”

Every year Apple and Google release new versions of iOS and Android. Some things break, others need adapting, and store rules change. On top of that: bugs, user requests, support, security updates, libraries that need upgrading.

Again as opinion: it’s prudent to budget a meaningful share of the original development cost every year for maintenance. And don’t forget the cost nobody sees in the spreadsheet: the founder’s time. The months you spend writing specs, testing, answering reviews and making decisions are months you aren’t doing anything else.

What I tell founders who want to launch an app

  • Build an MVP. The smallest version that solves the core problem. Everything else can wait.
  • Measure retention before you spend on acquisition. If people don’t come back after a week, ads just fill a leaking bucket.
  • Own the code and the accounts. The developer accounts, servers, domain and source code should belong to your company, not to the agency or freelancer who built them.
  • Budget for 12 to 18 months, not for launch day. Launch is the beginning, not the finish line. The iterations after launch are what make an app good.
  • Put store commissions into your model from day one. 15% or 30% of revenue changes the maths completely.

It’s the same logic I apply when I choose the startups I join for equity: I care less about how good the product looks in a pitch deck and more about whether the team understands what it costs to keep it alive. It’s not a technology principle. I described it too when I wrote about starting an online store from scratch: start small, measure, then grow.

Instead of a conclusion

A mobile app isn’t a project with a beginning and an end. It’s a product that lives, consumes resources and, if you’ve done things right, gives back more than it takes. The right question isn’t “how much does it cost to launch?” but “how much does it cost to stay in the game until the app proves its worth?”

What cost did you underestimate the most when you launched a digital product?