Your developer will charge you for things I didn't design.

Process · 5 min read

I design 30 screens. Your developer comes back with a quote based on 45. You look at the numbers and think someone's made a mistake. Maybe the developer is padding the quote. Maybe I missed something. But the truth is simpler and more important than either of those. The design file shows the happy path. The developer has to build everything else.

This catches almost every first-time founder off guard. And I'd rather explain it now than have you feel blindsided when the development quote arrives. Because understanding this gap between design and development is one of the most useful things you can learn before you start building.

The screens you don't see in the design

When I design an app, I focus on the core user journey. The screens a user sees when everything works perfectly. You open the app, you log in, you see your dashboard, you complete a task, you get a confirmation. That's the happy path and it's what the design needs to communicate clearly.

But the developer has to build what happens when things don't go perfectly. What does the screen look like when the list is empty because the user hasn't added anything yet? What shows up when the internet connection drops halfway through saving? What's the error message when someone enters an email address without the @ symbol? What does the loading state look like while the app fetches data from the server?

Every one of those states needs to be coded. A loading spinner is a design decision. An empty state illustration is a design decision. An error message is a design decision. I document as many of these as I can through annotations and notes in the design file. But I don't create a fully designed screen for every single edge case, because that would triple the design timeline and the cost. Instead, I provide guidelines and the developer interprets them. That interpretation takes time, and time costs money.

Why the gap exists

Design and development serve different purposes at different stages. The design proves the concept works for users. It establishes the visual language, the interaction patterns, and the flow. Development turns all of that into a functioning product, and functioning means handling every possible state, not just the ideal ones.

The Standish Group's research found that scope creep was responsible for cost blowouts in 52% of failed software projects. The gap between design and development isn't scope creep. It's expected scope. But when clients don't know about it ahead of time, it feels like scope creep. And that feeling leads to frustration, mistrust, and sometimes the wrong decision to cut corners on things that users will actually encounter.

Good design documentation reduces this gap but never eliminates it entirely. The annotations I write explain behaviour that isn't visible in the screenshots. "When this list is empty, show a message that says 'No items yet' with a button to add the first one." That annotation saves the developer from guessing. But the developer still has to build it, test it, and make sure it works across different devices and screen sizes.

How to prepare for the quote

When the development quote comes back higher than you expected, ask the developer to break it down by screen and by feature. Look for the items that aren't in the design file. Loading states. Error handling. Empty views. Offline behaviour. Push notification logic. Authentication edge cases like password resets and session timeouts. These are all real work that users will interact with, even if they never appeared in a design presentation.

The better the design documentation, the fewer surprises you'll get. That's one of the reasons I spend time on annotations and developer notes rather than just producing pretty screens. Every decision I make in the design phase and document clearly is a decision the developer doesn't have to make on the fly. And decisions made on the fly during development are how scope creep actually starts.

So when you see 30 designed screens and a quote for 45, don't panic. The extra 15 aren't padding. They're the reality of turning a design into a product. And knowing that ahead of time is the difference between feeling confused by the quote and understanding exactly what you're paying for.

Sources
CHAOS Report 2020 (Standish Group) - Scope creep caused cost blowouts in 52% of failed software projects. Better upfront decisions reduce downstream cost.

Related blog posts:

Scope creep starts with "while we're at it" →

Why your quote came back double →

What happens between the prototype and the App Store →