Why your quote came back double.

Strategy · 6 min read

I had a client who went through the full design process with me. We scoped the app carefully. We discussed what was in and what was out. By the end, the client had a rough number in mind for development. It felt reasonable. Then the developer quotes came back and the number was nearly double what he expected.

He wasn't happy. And honestly, I understood why. When you've been told a ballpark early on, and the real number lands way above it, it feels like someone got it wrong. But the truth is more nuanced than that. The ballpark was right for what we knew at the time. The quote was right for what we knew after the design was done. The gap between those two numbers is where most of the important decisions live.

What changes between the estimate and the quote

Early in the process, when you're talking about your app idea in broad strokes, the cost estimate is based on assumptions. How many screens, roughly. What the core features are, roughly. Whether there's a backend, probably. Those assumptions are educated guesses, but they're guesses.

Then you go through the design process. And in the design process, you discover things. You discover that your "simple" user flow actually needs three different paths depending on the user type. You discover that the feature you described in one sentence actually requires five screens, a notification system, and a backend API. You discover that what felt like one app is actually two or three experiences stitched together.

That discovery is the whole point of design. It's supposed to surface complexity before development starts, when changes are cheap. But it also means the thing you're quoting on at the end of design is bigger, more detailed, and more honest than the thing you estimated at the start.

The features that double the cost

It's rarely one feature that blows the budget. It's the accumulation of things that sounded small when you said them out loud. "We'll need notifications." That's a push notification system with backend logic, permission flows, and timing strategy. "Users should be able to share their profile." That's a PDF export, an email integration, and data formatting across multiple fields. "The admin needs a dashboard." That's a separate application.

I've sat in meetings where a client describes a feature in ten seconds that would take a developer ten days. Not because the client is wrong about wanting it. Because the gap between describing a feature and building a feature is enormous. And that gap is invisible until someone with technical knowledge points it out.

This is why design matters. By the time we're done, every feature has been mapped, every screen has been drawn, and the developer can quote on something real instead of something imagined. The quote is higher because it's accurate. The early estimate was lower because it was a guess.

What you can do about it

First, expect it. If your developer quote comes back at exactly the number you had in your head, something's probably wrong. Either the developer didn't read the spec properly, or they're planning to hit you with change requests later. A thorough quote should reflect the full scope of what's been designed.

Second, use the design to negotiate. Because every screen and every feature has been specified, you can have a real conversation about what to cut. Not "make it cheaper" but "what if we remove this feature and add it in version two?" That's a productive conversation. It puts you back in control of the budget without gutting the product.

Third, get multiple quotes. Different developers use different technologies, different approaches, and different pricing models. Some use AI-assisted development tools that reduce cost. Some charge more but deliver faster. The design spec makes this comparison possible because everyone's quoting on the same thing. Without it, you're comparing apples to oranges.

Sources
CHAOS Report (Standish Group) - Software project cost overruns are the norm, not the exception.
Why Good Projects Fail Anyway (Harvard Business Review) - How scope discovery during design prevents larger overruns in development.

Related blog posts:

The real cost of designing and building an app →

What is an MVP? →

A prototype is not an MVP →