Design the App Properly Before Anyone Writes Code
User flows, screens and a prototype you can tap through on your own phone — so the arguments happen while changes still cost minutes instead of weeks.
Design Is Where Changing Your Mind Is Still Cheap
Every product decision gets more expensive the later it is made. Moving a step in a design file is a few minutes of work. Moving the same step after it is built means changing the screen, the navigation, the tests, sometimes the data model underneath, and re-checking every device size the app supports. Nothing has broken — that is just what built software costs to rearrange.
So we deliberately front-load the disagreements. The design phase is where you discover that the onboarding has four steps too many, that two of the screens are really one screen, and that the feature everyone argued about for a month is not needed at all. All of that is free to find out in a design file and expensive to find out in week nine of a build.
How design fits into an MVP buildHow the Design Phase Runs
Two to four weeks for a typical MVP, narrowing from the whole problem down to a build-ready specification.
1. Discovery
Who the user is, what job the app does, what already exists, and what success looks like
2. User flows
The paths through the product, including the ones that fail, before any screen is drawn
3. Screens and design system
Wireframes into finished interface, built from reusable components rather than one-offs
4. Clickable prototype
A tappable version on a real device, tested with real people, then signed off
Design runs in parallel with technical planning, so the architecture and the interface are decided against the same set of facts.
A Pile of Screens Is Not a Product
Most people arrive with a list of screens: a home screen, a profile, a settings page, a checkout. That list says nothing about whether the product works. What matters is the path — what a person is trying to achieve, what they see first, what they have to decide, and where they get stuck.
So we map flows first, on purpose, before anything is made to look good. A flow forces the unglamorous questions into the open: what happens when the search returns nothing, when the card is declined, when the email never arrives, when the user backs out halfway through. Those states are most of the real work and they are the ones missing from almost every set of designs we are handed.
- One flow per thing a user actually wants to get done
- Every branch drawn, including the ones where things go wrong
- Screen count falls out of the flows rather than being guessed at first
- Steps that exist only because a document said so get deleted here
Four Versions of Every Screen
A screen with content in it is the easy one. Designs that only include that version leave the developer inventing the rest, which is how apps end up with a blank white page when something goes wrong.
Empty
Day one, nothing added yet. Usually the most important screen in the app and almost always the last one anyone thinks about.
Loading
What the user sees on a slow connection. A skeleton layout rather than a spinner over a blank screen wherever we can manage it.
Error
What went wrong, in plain words, and what to do next. Not a code, and never a dead end with no way forward.
Full
Realistic volume and realistic text lengths. Long names, long addresses, twelve items, none of which the pretty mock-up had.
A Clickable Version, and What Signing It Off Means
The most useful thing produced in the whole design phase, and the moment the project becomes concrete.
What the prototype is
- Real screens linked together, opened on your own phone rather than viewed in a slide
- The main flows tappable end to end, including the failure paths
- Something you can hand to somebody who has never heard your pitch and watch them try
- The specification the fixed price is attached to
- Shareable with investors, a co-founder or a first customer weeks before any build exists
What it is not
- Working software — there is no database, no account, no payment behind it
- A guarantee that every animation will be pixel-identical in the build
- A contract you cannot revisit — later changes just go through the written change process
- Something to skip because the screens already look finished
Test it on five or six people
Not a focus group. A handful of people who have the problem, given a task and left alone while somebody watches where they hesitate. That is enough to expose the serious problems in an interface.
Comments on the screens, not in email
Feedback goes on the prototype itself, pinned to the thing being discussed. No version four of a PDF with notes in three different threads.
Then it gets signed off
One written approval that the flows, screens and wording are what gets built. After that, changes are priced as change requests — which is exactly what makes a fixed price possible in the first place.
Why a Component Library Saves Money Later
The least visible deliverable and the one that decides what version three costs.
A design system is just the defined set of pieces every screen is assembled from: the colour roles, the type scale, the spacing steps, the buttons in each state, form fields, cards, alerts, empty states, error states. Instead of drawing each screen from scratch, both designer and developer assemble from the same kit.
The saving is not in the first five screens, it is in everything after. A new screen becomes an afternoon of arranging existing components rather than a week of new design plus new front-end code plus a new round of review. Change the button style once and it changes everywhere, including on the screens nobody remembered existed.
It also keeps the product coherent as more people touch it. Products that grow without one accumulate four shades of grey, three button heights and two different date pickers, and eventually somebody proposes a redesign to fix a problem that was really a consistency problem.
Named tokens, not hex codes
Colours and sizes given roles rather than values, so theming, dark mode and a future rebrand are edits in one place.
Every component state drawn
Default, pressed, disabled, focused, loading and error — so developers implement behaviour instead of guessing at it.
Mirrored in code
The same components exist in the codebase with the same names. When design and code drift apart, both stop being trusted.
Sized to the product
A five-screen app does not need a formal system and we will not sell you one. Anything that will keep growing does.
The Basics, Done From the Start
Cheap while designing, expensive to retrofit, and increasingly something buyers ask about before they sign.
Contrast that survives sunlight
Body text checked against the usual 4.5 to 1 ratio, larger text against 3 to 1. Pale grey on white looks refined on a designer monitor and disappears on a phone outdoors.
Touch targets people can hit
Controls big enough and far enough apart to use one-handed, on a moving train, with a thumb. Both platforms publish minimum sizes and both are regularly ignored.
Text that scales
Layouts tested with system font size turned up, because a lot of people run it that way permanently. Fixed-height boxes with text inside are where this usually breaks.
Never colour alone
Status shown with an icon or a word as well as a colour, so the meaning survives colour blindness and a greyscale screenshot.
Labels for screen readers
Every control named in the design file, so VoiceOver and TalkBack read something meaningful instead of announcing an unlabelled button.
Motion you can turn off
If someone has reduced motion enabled, the app honours it. Large parallax and spring animations make some people genuinely unwell.
We do the basics as standard. Formal conformance work for a specific standard is a separate, larger exercise — tell us early if you are selling into somewhere that requires it.
What Developers Actually Need
A folder of pretty images is not a handoff. This is the difference between a build that matches the design and one that approximates it.
Inspectable source files
Real spacing, type and colour values readable from the file, not measured off a screenshot. Components, not flattened images.
Responsive intent written down
What happens between the smallest phone and a tablet: what wraps, what stacks, what is allowed to scroll. Otherwise a developer decides for you.
Assets exported at every density
Icons as vectors where possible, images at the scale factors each platform needs, named consistently so nothing has to be re-cut mid-sprint.
Final copy, not placeholder
Real button labels, real error messages, real empty-state text. Wording written late is wording written badly, and it changes layouts.
Interaction notes
What is animated, what is a transition, what happens on a long press, which list refreshes on pull. Short notes, attached to the screen they describe.
The designer stays reachable
Questions come up in every sprint. Design is not finished and forgotten at handoff — whoever drew it reviews the built screens against it.
If You Already Have Designs, or a Designer
Plenty of clients arrive with work already done. We do not insist on redoing it.
A design review first
A short paid review before anything is committed. We check that every state exists, that the flows are complete, that the layouts hold at both extremes of screen size, and that nothing drawn is wildly expensive to build for the value it adds. You get the gaps in writing with a price to close them.
Working with your designer
Perfectly normal. Your designer owns the look; we own feasibility, states and platform conventions, and we review each sprint together. The one thing we ask is a single person who can make a final call, because two design authorities is slower than either alone.
Design on its own
You can buy flows, screens, a design system and a prototype without committing to us for the build. The files and the prototype are yours to take to any developer — a good number of people use it to get honest quotes from several.
What Happens Either Side of Design
MVP Development
Scope cut down to a first version, priced as one fixed number, with design as the second phase.
Learn moreMobile App Development
Where the signed-off prototype becomes iOS and Android builds, and then store listings.
Learn moreOur Process
How design, build, testing and launch fit together across a full project timeline.
Learn moreDesign Questions We Get Asked
Why does design have to happen before development starts?
Because changing your mind gets more expensive every week. Moving a button in a design file takes a minute. Moving it once it is built means changing the screen, the tests, sometimes the data behind it, and re-checking every device size. Design is the only phase where you can restructure the whole product for the cost of an afternoon, so it is the cheapest place to have the arguments that matter.
What exactly am I agreeing to when I sign off a prototype?
That the screens, the flows between them and the wording are what gets built. From that point the prototype is the specification the fixed price is attached to, and changes go through the written change request process rather than being absorbed silently. What you are not signing away is the right to change your mind later, or anything about colours and copy that can still be adjusted cheaply before build starts.
What is a design system and do I really need one?
It is the defined set of colours, type sizes, spacing, buttons, form fields, empty states and error states that every screen is built from, rather than each screen being drawn from scratch. For a five-screen app it is barely worth naming. For anything that will grow, it is the difference between adding a new screen in a day and adding one in a week, and it is what stops version three looking like a different product from version one.
I already have designs from a designer. Can you just build those?
Often yes, and we start with a short paid design review rather than a guess. We check whether every state exists, not just the happy path, whether the layouts hold at the smallest and largest screen sizes, whether the flows are complete, and whether anything drawn is disproportionately expensive to build for the value it adds. You get that review in writing with a list of gaps and a price to fill them, and you are free to have your own designer fix them instead.
Do you do user research and testing?
At a scale that suits a first version. That means a handful of structured conversations with people who have the problem, and putting the clickable prototype in front of five or six of them to watch where they hesitate. That is usually enough to expose the serious problems. Large scale quantitative research is a different exercise, and for most early products the real evidence arrives after launch from analytics on actual behaviour.
How long does the design phase take and what does it cost?
For a typical MVP, roughly two to four weeks running alongside the technical planning, and somewhere in the region of fifteen to twenty-five percent of the overall project budget. Design can also be bought on its own if you want flows, screens and a prototype before deciding who builds it. In that case the files and the prototype are yours to take anywhere.
See Your App Before It Is Built
Tell us what you have — an idea, a spreadsheet of features, or half-finished designs. You get a written scope and a budget range back within two business days.