How much does it cost to build an app? The question is wrong, and here is the question that works

A founder we worked with last year forwarded us three quotes for what she called the “same” app. $18,000 from a freelancer in Bogotá. $80,000 from a small São Paulo studio. $260,000 from a US-based agency. Same product description, same wireframes, three honest estimators. All three numbers were defensible. The cheap quote was a Bubble prototype she could demo to investors. The middle quote was a working app two real customers could use without breaking. The expensive quote included the SSO directory and compliance review her enterprise pilot was going to run.

How much does it cost to build an app is one of the most-searched founder questions on Google. It is also one of the least answerable. The numbers in the listicles are technically correct in the same way that “a meal in New York costs between $4 and $400” is technically correct. The range is so wide it conveys nothing. Worse, every range is biased by the source. App builders quote ranges that flatter app builders. Freelancer marketplaces quote ranges that flatter freelancers. No-code platforms quote ranges that make no-code look obvious.

The question that works is different: what does it cost to build my app, at my scope, on my timeline, with a team I can actually trust? Cost in custom software is the output of six drivers. Once you know yours, you can name a range, defend it, and stop being sold to.

Why the standard answer is wrong

The standard answer goes like this. A simple app costs $20K to $50K. A medium-complexity app costs $50K to $150K. A complex enterprise app costs $150K to $500K. Some sources push the top end to a million.

These ranges are not lies. They are the average of the population of apps the source has seen. You are not building the average app. You are building one specific app, and the average tells you nothing about whether your number sits at $30K or $300K. The variance inside each band is larger than the band itself.

The deeper problem is that “simple, medium, complex” hides every decision that actually moves the number. An app with a single screen and a Stripe checkout is simple. An app with a single screen and an enterprise SSO integration is not. An app with five screens and a Notion-style backend is huge. An app with fifteen screens and a CRUD admin panel is small. The category labels collapse all of this into noise.

Founders who anchor on these ranges make two predictable mistakes. They pick the cheapest quote inside their target band and discover six months later that the cheap team built a different app than the one they needed. Or they assume price equals quality and pay 4x for a team that is no better than the middle option. Both mistakes start in the same place: a number that was never tied to a real estimate.

The six drivers that actually set your number

Cost in custom software is not magic. It is the product of six things, and you can argue with any estimator about any one of them. If a quote does not break the number down across at least four of these six, it is not an estimate. It is a guess wearing the clothes of one.

Scope: what users do, end to end

Scope is the largest driver, and the one founders consistently underestimate. The right unit is not “screens” or “features.” It is flows. A flow is everything a user does to accomplish one goal, from sign-up to outcome.

Most founders count features and report scope as “ten features.” A working app with ten features has roughly forty flows once you include the unhappy paths (what happens when a payment fails, when a session expires, when an email bounces, when a user wants to delete their account, when an admin needs to refund). Each flow is two to ten hours of work depending on how the system is shaped underneath. The difference between counting ten features and counting forty flows is the difference between a $40K quote and a $120K reality.

If you have not yet written down the flows your app needs to support, you are not ready to be quoted. You are ready to write a product requirements document, which is what a real estimator will ask you for anyway.

Integrations: what your app talks to

Every external system your app touches adds cost in two places: the initial build and the long tail of maintenance. A Stripe integration is cheap because Stripe invested in being easy. A bank-direct integration with a Brazilian PIX provider is not cheap, because the documentation is in Portuguese, the sandbox is unreliable, and the production quirks only show up under load.

Integrations also bring failure modes the rest of your code does not have. A Stripe webhook can arrive twice. A CRM can return a 502. An identity provider can change its consent screen on a Tuesday. Handling these well takes more code than the happy path, and a real estimator will price for them. A cheap quote that lists “Stripe integration” as one line item is pricing the happy path and discovering the rest at your expense.

Count your integrations. Most early apps have three to seven (auth, payments, email, analytics, file storage, one or two domain APIs). Each one is rarely under $2,000 of work and often $5,000–$10,000 if the provider is awkward.

Data: where state lives, who owns it

Some apps are mostly UI on top of a small Postgres table. They are cheap. Some apps are mostly the data, and the UI is a thin layer over it. Those are not.

The questions that move the number: how much data per user, how often does it change, who else needs to see it, can it be exported, does it need to be searched, how do you back it up, what happens when a user’s data is corrupted at 11pm on a Friday. Each answer either pulls in a $0 design or a $20K one. A B2C habit tracker with five fields per user is the cheap end. A B2B platform that ingests a partner’s CSV every night, transforms it, and exposes it to a customer dashboard the partner also has to log into is the expensive end. Same screen count.

If your app is the data, the cost is the data. If your app is the workflow on top of the data, the cost is the workflow. Estimators who do not ask which one you are building are not estimating; they are guessing the easier of the two.

Compliance and accounts: what law and identity force you to build

Three things break a cheap quote on contact: regulated industries, enterprise customers, and identity at scale.

Healthcare, fintech, education, and legal-tech each carry compliance overhead that is not optional. HIPAA, SOC 2 readiness, LGPD, audit logs, encryption-at-rest, role-based access. None of it is hard, but all of it is work, and adding compliance posture late costs three to five times what it costs to bake in early.

Enterprise customers are similar. The day your first real customer asks for SSO, an audit log export, custom roles, and an SLA is the day your $40K MVP becomes a $120K product. None of these are bad things to build. They are not free, and a cheap quote that says “we will add enterprise features later” is moving cost from the quote to the future.

Identity is the third silent driver. An app with a single user role is cheap. An app with admins, end users, super-admins, partner accounts, and a customer-facing read-only role is not. Each role drags a permission matrix behind it, and permission matrices have the worst bug-density of any code in your system.

Team quality: who is writing the code

Two teams quoting the same scope can produce numbers 3x apart, and the higher number is often the better deal. Junior teams write more code to do the same thing, then write more code on top of that to fix what the first round broke. The hourly rate looks like the savings. The total cost of ownership tells the truth.

A senior team writes less code, writes it more carefully, documents it enough that a future team can extend it, and ships a system that does not collapse the first time you add a second feature on top. The hourly rate is higher. The cost of building, running, and extending the app over its first 18 months is usually lower.

If you cannot evaluate code yourself (and almost none of our clients can), look at signals. How does the team talk about trade-offs? Do they ask about the business goal or only the spec? Do they push back on requests that will create technical debt? Do they show you a previous client’s running production system, not just a Dribbble screenshot? A team that cannot defend a single architectural choice in plain language is the team that will bill you twice for the same feature once it breaks. We unpacked the rest of the diagnostic in how to evaluate a software house; almost every signal on that list maps to cost.

Pace: how hard the calendar is squeezing you

The calendar is the cheapest variable to move and the one founders are most reluctant to move. Compressing a six-month build into three months does not cut cost in half. It roughly doubles the cost, because compressed builds need more people running in parallel, more coordination overhead, more rework when two parallel branches collide, and more senior time per hour.

The opposite is also true. A team that can build at a steady pace over six months will quote a lower total than the same team running a sprint to ship before your investor demo. If you have flexibility on the timeline, that flexibility is worth real money. If you do not, the quote will reflect the squeeze, and a team that gave you the calmly-paced number is going to deliver a different (worse) product when you tell them on Tuesday that you need it Friday.

Realistic ranges by stage

With the six drivers in hand, the ranges below become useful instead of misleading. They are still ranges. The drivers above tell you where in each range you sit.

Sketch / prototype to show, not to use. $5,000 to $20,000. This is a no-code build (Bubble, Glide, FlutterFlow), or a heavily-templated React app, or a designer-led clickable Figma. It demos. It does not survive a real user. Use it for fundraising, for internal alignment, or for a customer letter of intent. Do not use it as the foundation of your real product, and do not let an estimator promise you that you can.

Real MVP that two real customers can use. $35,000 to $120,000. Three to seven integrations. Two to three user roles. Compliance still light. Eight to twenty user flows. A team of two to three engineers across three to five months. This is the most common shape of a Pixel Breeders engagement, and where the variance is widest, because the six drivers stop being abstract and start producing actual hours.

Post-launch v1 with paying customers and a real backlog. $150,000 to $400,000+ over the first year. The MVP build plus the ten things customers ask for in the first ninety days that you could not have predicted. The SSO request from your first enterprise pilot. The rebuild of the queue you wired up too quickly during the MVP. The analytics you decided to skip. Founders who scope only to MVP and not to “MVP plus the first year of reality” come back asking why the second six months cost as much as the first.

These ranges assume a competent team, honest scope, and the US or Western European market. Brazil, Eastern Europe, and Latin America cut the team-cost portion roughly in half without cutting quality, if you find a real team. Geographic arbitrage works, but the worst projects we have ever heard about all started with “we found a team in [country] for half the price.”

The five-question diagnostic that tests a quote

When a quote arrives, ask the five questions below before you compare two quotes against each other. The diagnostic separates real estimates from sales theater. A real estimator answers without flinching. A guess produces vague answers, defensive language, or “we will figure that out together.”

1. What scope did you assume, in flows? Not features. Flows. If they cannot list ten or twenty flows by name, they have not estimated; they have priced your wireframes.
2. Which integrations are in the quote, and which are explicitly out? A real quote has a list. A guess says “we’ll handle integrations as needed.”
3. Who exactly will be on this team? Not the company’s collective experience. The actual three people who will be writing the code, with their LinkedIn or GitHub. A real team is happy to name names. A bait-and-switch team is not.
4. What are the three biggest risks you see in this scope? This is the diagnostic that catches the most. A senior estimator can name three risks in fifteen seconds. A junior or dishonest estimator says “no major risks, we’ve done this before.”
5. What does month seven look like if we hire you? This question forces them to think past the build into the maintenance, the inevitable feature requests, the bugs found in production. A team that has only thought through the build is going to charge you twice for that conversation later.

If a quote answers all five well and is twice the price of a quote that answers none of them, the more expensive quote is the cheaper one over twelve months.

Where founders waste the most money

We have watched the same three mistakes drain budgets for years. None of them are about the rate per hour.

Building the app you imagined instead of the app your customers will use. The fastest way to spend $80,000 you did not need to spend is to ship the product in your head and discover, after launch, that customers want a different thing. The cure is to put the smallest possible version in front of three real customers before the build, not after. We have written about why most so-called MVPs are not actually MVPs, and the principle holds for cost: the cheapest feature is the one you do not build.

Saving on the team and paying it back in rework. The freelancer who costs $25 an hour and produces code that the next team rewrites from scratch did not save you money. They cost you the build twice plus the time lost between rounds. Cheap labor on engineering work is the most reliable way to overpay.

Choosing the contract that lets the cheapness hide. A fixed-price quote on an under-defined scope creates the incentive to cut corners on everything you did not write down. A pure time-and-materials quote on a vague brief creates the incentive for the work to expand. The contract shape matters as much as the dollar amount. We unpacked the trade-offs in fixed price vs time and materials; pick the structure that lets your team be honest with you.

What to ask before you sign

Write the three things below into the contract.

A list of the flows the quote covers, and the explicit statement that anything outside that list is a change request. This protects both sides. The team is not on the hook for things that were not estimated. You are not surprised when “we’ll handle the admin panel” turns into a $30K addition.

A weekly demo of working software, not slides, not screenshots. If the team cannot show you a running version of what they built that week, they did not build it that week. The demo is the cheapest form of project management you will ever buy.

A milestone-based payment structure tied to those demos. Not “33% upfront, 33% midway, 33% on delivery.” Something closer to “5% upfront, then a payment after each fortnight’s working demo.” The team gets paid for shipping. You stop paying if the demos stop.

The cost of building an app is the cost of those decisions, made well or made badly, multiplied by the time a competent team needs to execute them. The number is not random. It is the output of six drivers you can name, three contract terms you can write, and one diagnostic conversation you can have before you sign. Founders who skip the conversation pay for it later. The ones who have it pay roughly what the app should have cost, and they end up with the app they actually meant to build.

That is the answer to the original question. Not a range. A method.

FAQ

Can I build an app for free?
You can build a sketch for free with Bubble, Glide, or a no-code tool. You cannot build a business that way. The free version demos. It does not survive real users, scale, integrations, or meaningful customization. Treat the free build as a fundraising and validation tool, then plan for a real build once demand is proven.

Why are the cost ranges I see online so wide?
Every range collapses six independent drivers into one number. A $20K app and a $200K app can have the same screen count, the same description, and the same business goal. The drivers in this article are how you turn a range into a number for your app.

How long does it take to build an app?
A real MVP with paying customers takes three to six months with a team of two to three engineers. Anyone promising less is either building a prototype, cutting scope without telling you, or about to ship something that breaks. Anyone quoting twelve months is either over-building or quietly understaffing the project.

What is the cheapest way to validate an app idea before building?
A landing page, a demo video, and three founder-led conversations with potential customers will validate more in two weeks than three months of building will. Most founders skip this step and discover after the build that the demand they assumed was not there in the shape they thought.