How much does it cost to build an app? What the figure doesn't tell you

You are raising funds, or applying for funding, to have your app built. You need a figure. Your investors are asking for one, and so is your financial plan.

“How much?” is a fair question. Yet it is only part of the answer. The same amount can pay for an app nobody uses, or for an app your customers have been using for months. What makes the difference is not the sum. It is how the app is built with that sum.

How an app budget is usually set

The guides that answer “how much does it cost to develop an app” nearly all follow the same method. You list the features. You give each one a number of days, depending on whether it is simple, medium or complex. You add a margin for the unexpected, then the first year of maintenance. Out comes a range.

This method rests on two things: an estimate and a feature list. We rely on neither.

We explain in detail why an estimate remains a guess in our article on budget overruns. Here, it is the list we are interested in. Its flaw is less visible. It shifts attention.

Martin Fowler has a name for this shift: FeatureDevotion. It is the state in which ticking off features is valued more than what the project actually achieves. A budget built line by line from a list leads there almost naturally, since every line ticked off becomes proof that the money was well spent.

A goal to reach, not features to deliver

This is where the most common mistake lies. The goal gets confused with the things to build. People assume that delivering the planned features will achieve it.

Yet a feature list is only a hypothesis about how to get there. Dave Farley points to what the industry’s data says: even at the best software companies in the world, two ideas out of three produce no value, or negative value (Modern Software Engineering, p. 51). Nobody knows in advance which ones. At Microsoft, Ronny Kohavi and his colleagues come to the same conclusion (“Online Experimentation at Microsoft”, 2009): only about a third of the ideas meant to improve a metric do improve it.

Allen Holub puts it in one sentence: “Building the wrong thing on time and in budget doesn’t buy you much.”

So what matters is knowing whether the goal has been reached. Not knowing which features were delivered.

An app that works from the first month

The little you build has to be on target. From the first month of development, the app works. It does little. But what it does delivers value where it matters most to the people you want to sell it to.

After that, it keeps working, at all times. That is what Continuous Delivery is for: every change is checked before it reaches the app, so that what worked yesterday still works today.

It is not about doing a lot. Every day, the question is the same: what is the most useful thing to do today? That is what the adaptive approach makes possible. It gets to what matters most, fast. Then, every day, it keeps attention on the value expected that day.

Building the app with the people you want to sell it to

The people you want to sell the app to are the ones who know what matters most. Asked in advance, they cannot always say. Farley sees this too: even when you ask users what they want, they don’t know (p. 51). Put a working app in front of them, on the other hand, and they react.

So the feedback loop starts as early as possible. The app goes into their hands. You listen to what they say about it. You adjust. And you start again.

Even before building, an idea can be tested: that is what an MVP is for.

Waiting six months for the first feedback

Suppose the loop only opens after six months of development. It is no longer a loop. It is several loops at once.

The feedback arrives all together: what is missing, what gets in the way, what is of no use. Each piece calls for a change. You no longer know where to start. And six months of development on a list fixed at the outset have used up a good part of the budget.

Running out of money, for that matter, is almost never the root cause. CB Insights studied 385 venture-backed startups that have shut down since 2023. Of these, 70% ran out of money. The report points out that this is almost always the final cause of the shutdown, not the original problem. For 43% of them, the product had not found its market (CB Insights, March 2026).

What quality code means

When months have gone into building things nobody needed, one lesson goes unlearned. That is what we find most regrettable. Nobody has explained what quality code is, or what it is worth.

Quality code is code that is easy to change.

Farley puts it his own way: you often find out whether a design is good or bad when you try to change it (p. 108). He also points to the subtitle Kent Beck chose for his book on Extreme Programming: Embrace Change. According to Farley, everything else follows from this idea: keeping the ability to change your mind, your code, your technology, as you learn (p. 155).

For an app built from its users’ feedback, this ability decides everything. Every piece of feedback calls for a change. If every change is expensive, or breaks something else, the loop slows down, and the budget goes on repairs. Farley sums it up this way: over time, you are not choosing between better software and software that is faster to produce, you are choosing between “better software faster” and “worse software slower” (p. 154).

So how much should you budget to build an app?

For a funding round, you still need a figure. You do not get it by adding up features. You get it by deciding what you invest each month, and for how many months you want to be able to learn from your users before the next decision.

Holub makes the same argument. When the team spends the same amount every month, the budget and the date become one and the same. If the budget is fixed, the only variable left is scope. Martin Fowler arrives at the same place: a fixed price is possible, a fixed scope is not. The most useful features are chosen together, along the way.

The adaptive approach predicts what is predictable: the monthly budget and the development days per month. It does not try to predict what is unpredictable: what your users will do with a feature before they have it in their hands.

That is how we work. We develop your custom app for a fixed budget, invoiced at the end of each month for the work done. It is usable within a month. Usable does not mean finished: your teams use it from the first month. When their use of a feature teaches us something, we apply it the same day.

What is fixed is the budget and the problem to solve. Your budget buys ongoing work to ease this problem, starting on the first day of development. We aim to solve it completely, but we cannot guarantee that or put a date on it. You do not wait for that day for the problem to start easing. Each month you see what comes out of it, and you decide whether to continue.

Further reading

Fixing both the price and the feature list, or paying for time spent: who carries the risk when requirements change is the subject of our article on fixed price and time and materials.

Are you raising funds to develop your app, or looking for the right budget? Shall we talk?

Sources

• M. Fowler, “PurposeOfEstimation”, martinfowler.com (FeatureDevotion).
• M. Fowler, “FixedPrice”, martinfowler.com (fixed price without fixed scope).
• A. Holub, “NoEstimates, An Introduction”, holub.com (“Building the wrong thing on time and in budget doesn’t buy you much”; fixed budget, scope as the only variable).
• D. Farley, Modern Software Engineering, Addison-Wesley, 2021: p. 51 (two ideas out of three with no value; users do not know what they want), p. 108 (a design’s quality shows when you change it), p. 154 (“better software faster” and “worse software slower”), p. 155 (Embrace Change, keeping the ability to change).
• CB Insights, “The top 9 reasons startups fail”, 5 March 2026 (431 companies shut down since 2023, reasons identified for 385).
• R. Kohavi, T. Crook, R. Longbotham, B. Frasca, R. Henne, J. Lavista Ferres, T. Melamed, “Online Experimentation at Microsoft”, Microsoft ThinkWeek, 2009, p. 8 (about a third of ideas improve the target metric).