Why your developer built more than I designed.

Process · 4 min read

I designed around 30 screens for a client's app. That was the scope. That's what fit in the budget and the timeline. When the developer came back with their quote, they'd scoped for closer to 40. The client panicked. "Did the scope change? Is this going to cost more?"

It didn't. And the scope didn't change. What happened was the developer looked at the 30 designed screens and understood what was implied between them. The loading states. The empty states. The error messages. The edge cases where a user does something unexpected. All the in-between screens that a design doesn't typically show but a working app absolutely needs.

Design shows the ideal path

When I design an app, I'm designing the experience. The happy path. What happens when everything works the way it should. The user taps the button, the data loads, the screen transitions. That's what you see in a Figma prototype. That's what you tap through on your phone.

But a real app has to handle the unhappy path too. What happens when the data doesn't load. What happens when the user hasn't added anything yet and the screen is empty. What happens when they lose connection mid-task. What happens when they enter something wrong. A good developer anticipates all of that without being told.

That's why the quote comes back with more screens than the design. The developer isn't adding features. They're filling in the gaps that the design intentionally left out to keep things focused.

This is a sign of a good developer

If a developer quotes on exactly the number of screens in the design and nothing more, that's not a good sign. It means they're building exactly what they see without thinking about what the app needs to function. You'll get the happy path and nothing else. Every edge case will be a surprise. Every "what about this?" will be a change request with an invoice attached.

A developer who quotes on more than the design is telling you they've thought about it. They've looked at the flows and asked "what happens if the user does this instead?" That's experience. That's what you're paying for.

Design and development are different scopes

The design scope and the development scope will almost never be the same number. Design defines the experience. Development builds the system. The system needs more screens, more states, and more logic than the experience does. That's normal.

If you're a first-time founder and you get a development quote that's bigger than the design scope, don't assume something went wrong. Ask the developer what they added and why. If the answer is "loading states, empty states, error handling, and edge cases," that's a developer who's going to build something solid.

The gap between design and development isn't a problem. It's proof that both sides are doing their job.

Related blog posts:

The difference between a designer and a developer →

Your developer is not your vendor →

Why your quote came back double →