← All posts

How much does an app cost? A price list nobody will honor

How much does an app cost? A satirical menu of classic app requests, then the real cost drivers - roles, platforms, integrations, offline - and how to pay less.

Every studio gets the question at least once a week. Usually as the first message, sometimes as the only one: “Hi, how much does an app cost?”

It’s a fair question. It’s also roughly like walking into a car dealership and asking how much a vehicle costs. Bicycle? Truck? Does it need to fly? Is it for dentists?

So we did what any reasonable studio would do when asked a question with no answer. We wrote a menu.

The menu

Seasonal, subject to change, and binding on absolutely nobody. The kitchen reserves the right to ask follow-up questions.

Starters

  • “Just a simple login” - Email and password. Then “forgot password”. Then Google login. Then Apple login, because the App Store has opinions about social logins. Then two-factor, because someone read an article. Served with a side of GDPR. Price: never simple.
  • “A landing page, but make it an app” - A website wearing a trench coat. Price: ask first whether it needs to be an app.

Mains

  • “Like Instagram, but for dentists” - Photo feed, comments, likes, notifications, profiles, moderation and a very specific audience. Comes with the quiet hope that the original never really needed all those engineers. Price: market price. The market is not in a good mood.
  • “Uber, but for X” - Two apps (one for customers, one for whoever X is), live maps, payments, ratings, dispatch logic, and an admin panel for when it all goes sideways. Price: three apps, for the price of three apps.
  • “The everything app” - Chat, payments, a shop, a social feed, and a calendar “for later”. Price: the kitchen has gone home.

Sides and add-ons

  • “Can you make it pop?” - A design request with no measurable acceptance criteria. Price: one more round of revisions, recurring.
  • “It should also work offline” - Delicious. Requires local storage, sync, and a plan for when two people edit the same record on a train between two dead zones. Price: check the bill twice.
  • “Can we add AI?” - Garnish. Occasionally the main course. Price: depends on what it’s supposed to do, which nobody has said yet.
  • “One small change before launch” - Never small, always before launch. Price: the launch date.

Dessert

  • “Maintenance” - Nobody orders it. Everybody eats it. Price: monthly, until the app stops existing.

Why the menu has no numbers

Because the honest answer to “how much does an app cost?” is a range, and that range depends on decisions you haven’t made yet. A studio that sends a fixed number after one message is either guessing, or quoting the smallest possible version and planning to discover the rest together with you later - at a different price.

Here’s what actually moves the number. This is the part of the post that isn’t a joke.

The real cost drivers

1. User roles. An app where everyone sees the same thing is one app. An app with customers, staff, managers and an admin is effectively four apps sharing a database. Every role adds screens, permissions and test cases. In our experience this is the most underestimated driver of all.

2. Platforms. iOS, Android, web, or all three. Fully native apps mean a separate codebase per platform. Cross-platform frameworks like Flutter or React Native let you share most of the code, which is usually the sensible default unless you need deep hardware access or very platform-specific behavior. Our mobile app development page goes into the trade-offs.

3. Integrations. Payments, maps, calendars, your existing ERP or CRM, a shipping provider, a fiscal system. Each one is a relationship with someone else’s API, with its own documentation, quirks and outages. A well-documented modern service is quick to connect. The fifteen-year-old system in the back office that only one person understands is not.

4. Offline support. “Works offline” sounds like a checkbox. It’s architecture. The app needs local storage, a sync mechanism and rules for resolving conflicts. If you need it, say so early - retrofitting it later is the expensive way.

5. The admin panel. Every app with content, users or orders needs a place where someone manages them. Your customers never see it, which is why it rarely appears in the first brief, and it can easily be a sizable chunk of the work.

6. Design depth. There’s a big difference between a clean app built from well-made standard components and a fully custom experience with its own illustrations, animations and micro-interactions. Both are legitimate. One costs considerably more. “Make it pop” lives here.

7. Backend. Somewhere a server stores the data, sends the notifications, takes the payments and enforces the rules. Sometimes a managed backend service covers it. Sometimes you need a proper backend and API built around your logic. The thing on your phone is often the smaller half of the project.

8. Store release. Apple and Google review apps before they go live, with guidelines on privacy, payments, login and content, and they do reject things. Budget time for developer accounts, store listings, screenshots, privacy declarations and at least one round of “please explain why this app needs the camera”.

9. Maintenance after launch. Operating systems update every year. Libraries get security patches. Store requirements change. An app nobody looks after starts breaking quietly sooner than you’d think. Plan for ongoing care from day one, not as a surprise in year two.

Why honest studios answer with a range

A serious estimate comes after scoping: a proper conversation, sometimes a short paid discovery phase, where roles, platforms, integrations and must-haves get written down. A decent software brief shortens this a lot. Then you get a range, and the range narrows as decisions are made.

If someone gives you a precise figure before knowing whether you need an admin panel, they’re not being efficient. They’re being optimistic on your behalf.

How to actually make it cheaper

  • Cut scope without mercy. List every feature, then mark the ones the app cannot launch without. It’s usually fewer than half.
  • Build an MVP. The smallest version real users can use (and ideally pay for). Launch it, watch what people actually do, then build the next thing.
  • Go cross-platform. One codebase for iOS and Android is usually cheaper to build and cheaper to maintain than two.
  • Rent the solved problems. Login, payments, push notifications and maps already exist as services. Don’t rebuild them out of pride.
  • Ask whether it needs to be an app at all. A good web application runs on every device and skips the app stores entirely. Sometimes that’s the right answer, and we’ll say so.
  • Change your mind on paper. Rewriting a sentence in a spec is free. Rewriting a feature in code is the most expensive way to make a decision.

So, how much does an app cost?

Somewhere between “less than you fear” and “more than the cousin who knows computers quoted you”. Exactly where depends on everything above.

If you’ve got an idea and would rather have an honest range than a menu, tell us about it. We’ll ask a lot of questions. That’s the cheap part.