In This Article
Search this question and you'll be told an app costs nothing, or that it costs three hundred thousand dollars. Both answers are on the first page of Google right now. Neither one is lying, exactly. They're just being given by people who want very different things from you.
I build apps, so I'm not neutral either. But since you came here for a number, here's mine before anything else: most of the apps I've built for small businesses land between $8,000 and $15,000 by the time everything is done, plus a monthly amount for maintenance, improvements, and the compliance work that never really stops.
That's a long way under what the industry publishes. The rest of this explains why, and how to tell which kind of project you have.
The short answer
That gap has nothing to do with discounting or cutting corners. Most of what a small business needs is simply narrower than what the published numbers describe, and narrower is the whole reason it costs less.
For context, here's what gets published, and roughly where it's accurate:
- A web app that runs in a browser and works properly on a phone: often $8,000 to $40,000, and it's what most businesses asking for an app need.
- A straightforward native app on one platform, doing a few things well: commonly $25,000 to $75,000.
- iOS and Android, with a real backend behind them: $60,000 and up.
- Anything with payments, live syncing, or regulated data: six figures, and the compliance work is a bigger share of that than people expect.
Those are market ranges from Business of Apps and the larger development firms, and they're not wrong. They're just describing bigger builds than most small businesses need. The ranges have never really been the problem. The problem is that nobody explains why a project lands where it lands, so you end up holding a number with no way to judge it.
Two industries answer this question, and they disagree wildly
Look at who's on page one. Bubble and Base44 sell no-code app builders, and their answer starts at free and tops out around $150 a month. Appinventiv, Topflight, SparxIT and Soltech are development firms, and their answers run from $40,000 to $400,000 and beyond.
Both groups are describing something real. They're just describing different things, and each one is describing the thing they sell.
Watch what happens to a single phrase. "A simple app" costs $5,000 to $50,000 according to Business of Apps. Soltech puts small apps at $50,000 to $75,000. Presta says simple apps start at $40,000. Base44 says you can do it yourself for nothing. That's not a range, that's four different definitions of the word simple, each one shaped by what the source needs you to believe.
When the cheapest answer comes from someone selling a platform and the most expensive comes from someone selling a build, the honest number is rarely at either end.
Most of those numbers are for a different business than yours
The part almost nobody flags: Nearly all the app cost content online is written for funded startups building consumer products. Topflight says the typical funded first version lands around $80,000. That's a real number for a venture-backed company trying to win a market.
It has very little to do with a plumbing company that wants its crews to stop filling in paper job sheets.
Those are different projects with different economics. The startup app has to delight strangers who owe it nothing, survive an app store, and scale to numbers it doesn't have yet. Your internal tool has to work for eleven people who already have a reason to open it. The second one is dramatically cheaper, and most of the published guidance quietly prices the first.
First question: do you need an app?
This is the cheapest question in the whole process, and skipping it is the most expensive mistake in this category.
Most businesses that ask me to build an app want a web app: something that runs in a browser, works properly on a phone, updates the moment I ship it, and never waits on an app store review. It's faster to build, cheaper to maintain, and nobody has to install anything.
Native earns its place when the thing needs the device. Camera, GPS, push notifications, working offline in a basement with no signal. Or when your customers expect to find you in the App Store, which is a marketing reason rather than a technical one, and is still a legitimate reason.
Building a native app for an audience that was never going to download it is how businesses spend $60,000 to get something worse than a web page. That decision gets made early, usually in a meeting, usually because an app sounded like the more serious answer. I go through the split in more detail on the custom software and app development page.
What moves the number
Five things, roughly in order of how much damage they do to a budget.
1. How many platforms
iOS and Android are not one project with a checkbox. Even with a shared codebase, you get two sets of store rules, two review processes, two sets of devices to test, and two things to keep working when the operating systems update in the autumn. Launching on one platform first is the single biggest lever you have, and most businesses can name which one their customers use.
2. Whether it has to talk to anything else
An app that stands alone is a small project. An app that reads your inventory, writes to your CRM, takes payments, or logs people into an account is a different category of work. Every connection is a place where somebody else's software can change under you, and that risk gets priced in whether or not anyone names it out loud.
3. Accounts, payments, and regulated data
The moment an app knows who you are, it has to handle passwords, resets, sessions, and what happens when someone loses their phone. The moment it takes money, it inherits a compliance surface. If it touches health or financial data, that surface grows again. None of that is visible in a design, which is exactly why it surprises people in the invoice.
4. Who writes the content and supplies the assets
Same as any build. If the copy, the photos, the product data and the legal text arrive late, the project sits. A stalled project costs money, and the stall is almost never the developer's to fix.
5. Whether the scope can move
Apps get discovered by using them. The first version always teaches you something the plan got wrong. Budgets that assume the spec is final tend to break, and budgets that expect to change direction once or twice tend to hold. That's not a license for chaos, it's an argument for shipping something narrow early enough that changing course is still cheap.
The costs that never show up in the quote
The build price is what people compare. The running cost is what decides whether it was worth it.
- The stores. Apple charges $99 a year to keep a developer account. Google Play is a one-time $25. Small, but they never stop, and if the Apple account lapses your app comes down.
- Maintenance. The industry rule of thumb is 15 to 25 percent of the build cost every year, and it's roughly right. Phones get new operating systems annually, and an app nobody maintains eventually stops opening.
- Hosting and infrastructure. Modest at first, and it scales with use rather than with time. A tool for your own staff is predictable. Something customers use is less so.
- App review. Apple can reject a build for reasons you didn't anticipate. Budget calendar time, not just money.
- Getting people to install it. Nobody downloads an app because it exists. If it's for customers rather than staff, there's a real acquisition cost sitting behind the build, and it's frequently larger than the build.
That last one deserves emphasis, because it's the one that turns a fine app into a wasted one. An internal tool has a captive audience. A customer app has to earn every install, one person at a time.
Can't I just build it with AI?
Partly, and more than last year. AI tools will get you a working prototype fast, and for simple things they'll get you further than that. If you're trying to see whether an idea has legs before spending real money, that's a good use of a weekend.
Where it gets expensive is everything after the demo. Accounts and permissions, payments that reconcile, data that survives a bad network, app store requirements, privacy rules, and the part where it still works in eight months when the phones have updated twice. Those are the parts that carry risk, and they're the parts that are hardest to check if you can't read the code.
I've written about what an AI-built project gives you and what it's still missing, and the same logic applies here. Use it to find out whether the idea is worth building. Be careful about shipping it to customers without someone who can tell you what it's hiding.
How to compare two quotes that look nothing alike
When two numbers are far apart, the gap is almost always information rather than greed. Ask both people the same questions:
- Web app or native? If native, why, specifically?
- How many platforms, and can we launch on one first?
- What has to connect to systems we already run?
- Who owns the code, the store listings, and the accounts it runs on?
- What happens after launch, and what does it cost per year?
- What's the smallest version that would still be useful?
That last question is the most revealing one on the list. Anyone who can't describe a smaller version of your project either hasn't thought about it or doesn't want to, and both are worth knowing before you sign anything.
Why that's a range and not a quote
I gave you my number at the top because I think withholding it wastes everybody's time. But a range is not a quote, and I'd rather say why than let you assume.
A rate card works when what you're selling is standardized. Two businesses ask for "an app" in identical words, and one needs a five-screen tool for their crew while the other needs iOS, Android, payments and a customer login. Quoting both from the same table means overcharging one and underdelivering to the other. The $8,000 to $15,000 band is where most small business projects land. Some sit under it. A few, usually the ones with payments or regulated data, sit well over.
What I'll do on a first call is tell you which of those you are and why, in enough detail that you could take it to someone else and get a sensible comparison. That includes the times the answer is that you don't need an app at all. If you want that conversation, here's what I do on the web and software side, and if you're weighing a website in the same breath, what a website costs covers the other half of the question.
