Home / Journal / Why Development Quotes Vary So Much

Why two studios quote wildly different numbers for the same brief

We once quoted twenty-five thousand pounds on a brief another studio priced at a hundred and eighty. Neither of us was lying. We had read the same document and priced two different projects.

JournalarticleIndexableWall & Fifth

Why this matters

A brief describes what you want. It rarely describes what has to be decided to get there.

Two studios read the same document and price two different projects. Not because one is dishonest, but because the document left the expensive parts unspecified, and each filled the gap with a different assumption. The spread between the quotes is a measurement of that gap.

01

The brief has holes

Every brief does. The price differs by how each studio guessed at what was missing.

02

The exclusions differ

One quote assumes the product logic is decided. Another includes deciding it. Same document, different work.

03

The definition of finished differs

Deployed and handed over is a different endpoint from running in the App Store with someone answering the support email.

How to read a spread

The useful question is not which number is right. It is what each number assumed.

A large spread on identical documents is information. It tells you the brief has ambiguity in it, and it tells you where. Rather than picking the middle number, use the spread to find the ambiguity and close it.

1

Ask each quote what it excludes

The inclusions will be similar across quotes. The exclusions will not, and that is where the money is.

2

Ask who decides the product logic

If nobody has priced for it, it will still get decided, silently, by whoever is closest to the keyboard on a deadline.

3

Ask what finished means

Code delivered, or product live? Store submission included? Who handles the rejection if it comes back?

4

Rewrite the brief and requote

Once the ambiguity is named, the spread usually collapses. The remaining difference is the real one, and it is the one worth judging on.

What actually drives a quote

The interface is the cheap part. The logic underneath is where the cost lives.

The things that genuinely move a number: how many kinds of user exist and what each is allowed to do, whether the product logic is settled or still being worked out, custom workflows, API complexity, payments, admin and dashboard requirements, deployment and store submission, edge cases, and the testing burden that all of the above creates.

None of these are visible in a description of what the product does. All of them are the work.

What founders think drives it

Screen count is the most misleading number in a brief.

Twenty simple screens with one user role and no payments is a smaller build than six screens with three roles, a permissions model, and a payments integration. Founders price the first as bigger, because they are counting the thing they can see.

This is why quotes seem irrational. The founder is comparing them against a mental model of drawing screens. The studios are pricing a model of decisions, integrations, permissions, data structure, and launch requirements. The two models do not track each other at all.

A seven-times spread

The same brief, quoted at twenty-five thousand and at a hundred and eighty thousand.

This is a real brief and two real numbers. The founder assumed one of us had misunderstood the project. In a sense both of us had, because the brief did not contain enough to be understood the same way twice.

The gap was not margin, and it was not quality. It was scope. One reading assumed a defined first version with the product logic already settled. The other assumed a full platform with the roles, permissions, admin environment, and integrations that implies. Both readings were available in the document. That is a problem with the document, not with either quote.

A seven-times spread is not a sign that someone is wrong. It is a sign that the brief is doing far less work than the founder thinks it is.

The unpriced thinking

The cheapest quote is often the one that has not priced the thinking.

If the product logic is not settled, someone has to settle it. A quote that assumes the founder has done that work will be lower than one that includes doing it together. Both can be honest quotes.

The risk is not that the cheap quote is a scam. The risk is that the decisions get made anyway, without anyone being paid to make them carefully, and the cost surfaces later as a rebuild rather than as a line item. That is the mechanism by which a cheaper build becomes more expensive.

When the high number is the right one

Sometimes the expensive quote is reading the brief correctly and the cheap one is not.

Payments, multiple user roles, a real permissions model, an admin environment somebody has to operate daily, integrations with systems you do not control. These are not padding. A studio that has priced them has understood what you asked for.

The signal is not the number. It is whether the quote can explain itself. A studio that can tell you which specific requirement produced which part of the cost is thinking about your product. One that hands over a single figure is not.

How to narrow the spread yourself

Most of the variance is removable before anyone quotes anything.

Write down the user roles and what each can do. Write down what is deliberately excluded from the first version. Write down what has to be true on launch day for the product to count as working. Name who owns the code, the accounts, the keys, and the store listing.

A brief with those four things in it produces quotes that are close to each other. The remaining gap is a real difference in approach, and you can judge it. That is a much better position than choosing between numbers whose meanings you cannot compare.

Where Wall & Fifth sits

The scope conversation is the work. It happens before the quote, not after it.

What the first version is for, what it deliberately excludes, and what has to be true on the day it launches. Those three answers determine the number, and they determine whether the number holds.

For a defined first version, that is New Builds. Where the product direction needs to stay open while the software takes shape, it is usually Embedded Partner.

This is written for founders who

This is written for founders who

  • Are holding two or more quotes and cannot explain the difference between them
  • Have been given a single figure with no breakdown behind it
  • Suspect the cheap quote has left something out but cannot name what
  • Are writing a brief and want fewer surprises when the numbers come back

FAQ

Questions people usually have before the next step feels obvious.

Why would two studios quote very different numbers for the same document?

Because the document is incomplete, as every brief is. Each studio fills the gaps with different assumptions about user roles, product logic, integrations, admin tooling, testing, and what counts as finished. We have quoted £25,000 on a brief another studio priced at £180,000. The spread measured the ambiguity in the brief rather than the honesty of either studio.

Does a higher quote mean better quality?

No. It means a larger scope was assumed, or more of the thinking was priced in, or both. The useful test is whether the studio can explain which requirement produced which part of the cost. A quote that cannot explain itself tells you nothing at either end of the range.

Is the cheapest quote always a risk?

Not if the product is fully specified and you are buying implementation. It becomes a risk when the specification is incomplete, because the missing decisions still get made, just without anyone being paid to make them well.

How do I get quotes I can actually compare?

Specify the user roles and their permissions, state what is excluded from version one, define what must be true on launch day, and confirm who owns the code and the accounts. Quotes against that brief tend to converge, and where they still differ, the difference is real and worth judging.

What is the most common thing left out of a low quote?

Admin tooling, testing, deployment and store submission, and edge-case handling. None of these appear in a description of what the product does. All of them appear in the work, and someone pays for them eventually.

Related pages

Useful next step

A brief with its exclusions written down produces quotes you can actually compare.

The spread narrows when the ambiguity is named. What is left is a real difference in approach, and that is the thing worth choosing on.

See New BuildsStart a conversation
Explore Embedded PartnerSee New BuildsAbout Wall & Fifth