How do you estimate real costs before app development?

A founder sits down with a spreadsheet, works backwards from what they think the product should cost, and arrives at a number. They share it with a few agencies. One quotes close to that number, two quote higher, and one quotes something so low it barely registers as serious. The founder picks the low one, or negotiates the mid ones down to something comfortable, and work begins. Three months later, the conversations get harder. Six months later, the budget is gone. The product is not live.

Real cost estimates start with scope and discovery, not with a number in mind.

This is not an unusual sequence. According to The Standish Group CHAOS Report, 52.7% of software projects run over budget to almost double the original amount. The number is striking, but the mechanism behind it is what matters. Projects do not blow their budgets because development is unpredictable. They blow their budgets because the estimate was built on the wrong foundations before development ever started.

Getting a real cost estimate before app development requires understanding what drives cost, what gets missed, and why the cheapest quote is almost never the cheapest project. This article walks through how that works in practice, including where we have seen it go wrong and what the damage looked like.

Why App Cost Estimates Go Wrong Before a Line of Code Is Written

The most common source of a bad estimate is a brief that is too thin to price from. A vague brief produces a vague quote, and a vague quote is almost always an underestimate, because the agency fills the gaps with best-case assumptions while the client fills them with best-case expectations, and those two sets of assumptions rarely match.

We have encountered competing quotes that were so low they were not plausible as real project costs. Upon looking more closely at how those quotes were produced, it became clear the other agencies had asked very few questions before submitting them. They were not estimating the project. They were pricing to win it, with the expectation that scope changes and extra charges would recover the margin later. That strategy works well for the agency. It works poorly for the client.

A real estimate requires a real brief. That means knowing what the product does, who it is for, how complex the core flows are, what third-party integrations are needed, and what the technical constraints look like. Without those answers, any number on a page is a placeholder, not a price. The danger is that clients treat it as a commitment, and the project is already in trouble before a contract is signed.

What a Real Cost Estimate Actually Covers

Most founders think of app development cost as the cost of building the app. That is roughly half the picture. A complete cost estimate covers several distinct categories, and underestimating or ignoring any of them shifts the problem rather than removes it.

Maintenance alone runs at roughly 15 to 20% of the original development budget each year, according to Imaginovation. A product built for £80,000 carries an ongoing cost of £12,000 to £16,000 annually just to stay functional as operating systems update. That is before any new features are considered. Founders who plan only for the build end up surprised by the maintenance, and doubly surprised when the iteration budget they never set aside turns out to be necessary.

How Scope Defines Budget (and Why Founders Get This Backwards)

The standard founder approach is to decide on a budget, then ask agencies to tell them what that budget will buy. The logic feels sound. You know what you can spend, so you work within it. The problem is that this reverses the relationship between scope and cost. Scope defines budget. Budget does not define scope, at least not without a clear trade-off conversation about what gets dropped.

We had a client come to us having already asked around for quotes. They arrived with a suggested budget and a view on how we should change our process to fit it. We convinced them to run a proper discovery phase first. What emerged from that discovery was a product scope that was materially different from what they had originally described, and a budget figure that reflected what they actually needed to build.

A lower budget means reduced flexibility, not just a cheaper version of the same product.

A lower budget does not produce a cheaper version of the same product. It produces a different product, with different constraints and a narrower ceiling. The trade-off needs to be made explicit. If you want to spend less, you need to accept a tighter scope, a faster route to market, and fewer features in the first version. Problems arrive when a client wants the lower budget but rejects the limitations that come with it, and that combination is far more common than it should be.

The Discovery Phase: What It Is and What It Costs to Skip It

Discovery is the phase of work that happens before design or development begins. It covers user research, technical architecture, flow mapping, and scope definition. Its output is not a wireframe or a prototype, though those may follow. Its output is a clear and costed picture of what the product needs to be and what it will take to build it.

A rough estimate produced without discovery carries accuracy of around plus or minus 50%, according to Devtimate. A paid discovery phase typically produces accuracy within plus or minus 10 to 20%. That is the practical difference between a budget that reflects the project and a budget that reflects a guess. For a product in the £80,000 to £150,000 range, a 50% margin of error is a crisis waiting to happen.

Before accepting any quote, ask the agency what questions they asked before producing it. If the list is short, the quote is not a real estimate.

The instinct to skip discovery is understandable. It costs money and it delays the visible work. But skipping it does not remove the cost. It relocates it into the build phase, where changes are five to ten times more expensive to make. According to Forrester, £1 spent on UX research saves approximately £100 in development costs later. That ratio makes discovery one of the few expenditures in app development with a clearly measurable return.

When Skipping One Component Costs You Everything: The Messaging Feature Case

On a dating app project we ran, the central premise was verified profiles and bot prevention. The client wanted to focus the discovery work purely on onboarding and skip discovery for the messaging component. The rationale was cost and speed. They felt messaging was straightforward enough to handle without the same level of upfront work.

What we built as a result was a generic messaging feature, because that is what the brief supported. The problem was that a generic messaging system allows automated messages and fake contact attempts, which directly contradicted the verified, human-only promise the product was making in its onboarding. The two parts of the product were working against each other. The messaging section had to be rewritten from scratch, at a cost of approximately £15,000 in additional budget and two months of additional work.

The lesson here is that every component of a product needs to be understood in the context of the whole product. A decision that seems isolated rarely is. Skipping discovery on one part of the product does not save the cost of discovery. It converts it into a much larger remediation cost on the other side of the build.

Treat discovery as a whole-product exercise. Scoping one feature in isolation while leaving others undefined creates mismatches that surface late, when they are expensive to fix.

How Founder Conviction Without User Evidence Inflates Real Costs

There is a particular kind of project that consumes its entire budget in design and build without ever reaching a live product. We have seen this pattern across two projects, a fitness and wellness app and a grassroots football product, where founders with strong personal conviction in their vision continued to make changes after sign-off, rolled back decisions already made, and resisted launching until the product felt right to them rather than to their users.

The warning signs appeared early in both cases. Research, focus groups, and surveys were producing data that pointed in a different direction from the founder's instinct. In both instances, that data was set aside. The product continued to be shaped by what the founder believed it should be rather than what users were telling us they needed. We flagged the trajectory on both projects. The budget ran out before either reached a fully live version.

Pre-launch founders often prefer competitive feature mapping to user interviews because a spreadsheet gives them immediate, unchallenged validation of what they already think. User research carries the risk that someone will say the idea is wrong, or that nobody wants the product in the form the founder imagined. That risk feels uncomfortable. But building past it without evidence is how a product becomes what we would describe internally as a vanity product, one shaped by the founder's preferences rather than by the people who would actually use it.

The Hidden Cost of Scope Creep Over Time

Scope creep is usually a series of small decisions, each of which feels reasonable in isolation. A feature added here, a flow extended there, a launch delayed to include something that was not in the original brief. Each addition carries a cost. What makes scope creep expensive is not any single change but the compounding effect of changes across a project timeline.

We worked on a sports club app where the original timeline was three to four months to market. After twelve to fourteen months of development, the product had still not launched. The budget almost doubled over the course of the project. Every additional month of development carried its own cost in engineering time, design revisions, and project management. None of this was unforeseeable. The development team advised against the trajectory the project was on at the time, and those warnings were not acted on.

The practical implication for cost estimation is that a budget set at the start of a project is only accurate if the scope stays close to what was agreed. Scope changes after development begins are new work, priced at the cost of in-progress development, which is always higher than the same decision made before work started. A realistic estimate accounts for a contingency buffer to absorb small variations without derailing the whole project.

Build a contingency of at least 15 to 20% into any project budget. Treat it as part of the plan, not as evidence that the estimate was wrong.

How to Pressure-Test a Quote Before You Accept It

A quote is only as reliable as the process that produced it. Before accepting any estimate, it is worth understanding what information the agency used to arrive at their number and what assumptions they made where information was missing. A few direct questions tend to reveal a great deal.

1. What questions did you ask before producing this quote?
2. What assumptions have you made about scope that are not explicitly covered here?
3. What happens to this price if those assumptions turn out to be wrong?
4. Does this include design, QA, and deployment, or just development?
5. How is scope change managed once work begins, and how is it costed?
6. What does the post-launch phase cost, and is it included here?

An agency that cannot answer these questions clearly has not done enough upfront work to produce a reliable estimate. The quote may look attractive, but it is priced on incomplete information, and incomplete information always has a cost that appears somewhere later in the project. The question is whether it appears before the contract or after it.

Building a Cost Estimate You Can Actually Defend

A defensible cost estimate is built from the scope outward, not from a target budget inward. That means starting with a clear picture of what the product does, who it serves, and what technical decisions have been made, then pricing from those specifics rather than from category averages or historical ballparks.

The sequence matters. Discovery produces scope. Scope produces a realistic estimate. That estimate carries a contingency for change. It also carries a clear description of what is not included, because what is excluded from an estimate is as important as what is in it. Post-launch maintenance, iteration budget, third-party licensing fees, and infrastructure costs are all real expenditure. If they are not in the estimate, they will arrive as surprises.

The output of a good discovery phase is an estimate with a margin of around plus or minus 10 to 20% rather than plus or minus 50%. That is the difference between a document that can be used to make real decisions and one that is really just a starting point for negotiation. Founders who invest in discovery before committing to a build budget leave themselves in a much stronger position to defend the number they take to investors, co-founders, or their own financial planning.

Conclusion

App cost estimates go wrong in predictable ways. They are built on thin briefs. They skip discovery to save upfront cost, then pay for that decision during the build. They are accepted because they are low, without enough scrutiny of how the number was produced. And they fail to account for the full picture, leaving out maintenance, iteration, and the contingency that every real project needs.

Getting the estimate right requires doing the groundwork before the number is produced. That means a thorough discovery phase, a scope that reflects what the product actually needs to do, and a clear conversation about what a lower budget does and does not buy. It means asking the right questions of every agency that submits a quote, and being sceptical of any number that arrived without those questions being asked first.

We have seen what happens when this process is skipped. A dating app messaging feature rewritten for £15,000 extra after a discovery shortcut. A sports club app that spent twelve months in development and never launched. A fitness product that ran out of budget before it reached users. These are the ordinary consequences of ordinary shortcuts, and they are avoidable with the right process in place from the start.

If you are trying to estimate the real cost of your app before development begins, let's talk about your project.

Frequently Asked Questions