Flows mapped before pixels, a clickable prototype you can put in front of real users, and a component system your next engineer can extend. Included as standard in every build — there is no separate design line on the quote.
Screens drawn without knowing what the data can do produce beautiful mockups and an argument in week three. Because the same people build it, the design is checked against real constraints as it is drawn — what the API returns, what an empty state looks like, what happens on a slow connection.
Not a slide deck of screens. A clickable prototype of the actual flow, which is the only artefact that reveals whether a product makes sense to someone who has not been in the meetings. You get one before any quote, at no cost.
Type scale, spacing, colour with contrast checked, and components that compose. This is what stops the twentieth screen looking unrelated to the first, and what makes your next engineer able to add a page without a designer.
What the product is for, who uses it, and what they are trying to get done. Usually a call, plus whatever you already have — competitor products people are used to, support tickets, and the internal spreadsheet everyone actually works from.
The paths through the product, sketched at low fidelity where changing them is free. Most of the value in a design engagement is created here, and most of the cost is created by skipping it.
The core flow, real enough to click through and misunderstand. Put it in front of two or three people who resemble your users; their confusion is worth more than any opinion in the room, including ours.
Type, colour, spacing and components — with accessible contrast as a constraint rather than a check afterwards. The output is a system that composes, not a set of unique screens.
Figma files with components and states, tokens, and the annotations engineers actually need: what is interactive, what happens on error, what an empty list says. Where we build it too, this step is mostly redundant — which is a saving.
On most quotes, design is a separate line you can shrink to make the number smaller. Not here — it sits inside every build quote alongside engineering, testing and deployment, and there is nothing to remove. That is not generosity. A product designed badly is more expensive to build, not less, because the cost reappears as rework, arguments about what a screen was supposed to do, and features nobody uses.
It also means the free prototype you get before any quote is genuine design work, done before you have committed to anything. If you look at it and walk away, you owe nothing and you keep what you learned about your own product.
How pricing works lists everything the quote covers.
Sometimes, with an honest caveat about what we are. This is a studio that ships software, and design here is strongest precisely because the people drawing it know what it costs to build and will have to build it. Design-only work fits well when it leads somewhere — you have an in-house team who will implement it, or you are validating a concept before committing to a build. It fits badly when you want a pure design agency relationship with brand strategy, illustration and campaign work; that is genuinely a different discipline and you would be better served elsewhere. Tell us which you are on the call and you will get a straight answer rather than a proposal for work we are not the right people to do.
No. Design is inside every build quote as standard, alongside engineering, testing, deployment and the SEO and performance work — it is listed in what the quote covers on the pricing page. There is no separate design line and no phase you can decline to make the number smaller, because a product designed badly costs more to build, not less. The practical consequence is that the free prototype you get before any quote is real design work, done before you have committed to anything, and if you walk away you owe nothing for it. Design-only engagements without a build are quoted separately, since there is no build for them to sit inside.
A clickable prototype of the core flow, and Figma files structured as a working system rather than a gallery: components with their states, type and spacing tokens, and colour with contrast ratios checked. Alongside that, the annotations that decide whether a build goes smoothly — what each interactive element does, what error and empty states say, what happens on a slow connection or a small screen. You own all of it outright, in your own Figma, from the start. When we also build the product, much of the formal handover documentation becomes unnecessary, and we would rather spend that time on the product than on documents nobody reads.
Proportionate to the decision, and we would rather do a little well than a lot ceremonially. For most products at this stage that means putting the clickable prototype in front of a handful of people who resemble your users and watching where they hesitate — which reliably surfaces more real problems than a formal study, costs almost nothing, and can be repeated. We will also read whatever evidence you already have, since support tickets and sales objections are research most teams are sitting on and not using. What we do not do is large-scale quantitative research or formal usability labs; if a decision genuinely warrants that, it warrants a specialist and we will say so.
Yes, and it is usually the better outcome — a product that looks like the rest of your business beats one that looks better in isolation. Send whatever exists, however partial: a logo, a colour, a font choice, an existing site to match. We work within it and will flag the specific places where a brand guideline built for marketing does not survive contact with an interface, which is common and normal. Brand colours frequently fail contrast requirements at small text sizes, and display typefaces chosen for a homepage become unreadable in a dense table. In those cases we propose the smallest adjustment that keeps the brand recognisable and the product usable, rather than quietly doing one or the other.
The specific decisions that decide whether an early product gets used are in the five UX decisions that make or break an MVP.