Design
Design is where a technology choice gets cheap
The expensive part of a build is rarely the code. It is the four weeks spent writing code for a screen nobody had agreed on.
Every project makes the same set of decisions: native or cross-platform, custom or standardised, one product or three. Those decisions are cheap while they are still drawings and expensive once they are commitments in a repository.
Design is the period in which they are still drawings.
A prototype is an argument, not a picture
The purpose of a prototype is not to show what the product will look like. It is to end a disagreement that would otherwise be settled in month three, by which point the answer costs a sprint.
The good ones are deliberately unfinished. They are detailed exactly where the disagreement is and loose everywhere else, because polish in the wrong place invites feedback about colours when the open question is a flow.
Pick the delivery model before the stack
We deliver in three shapes: custom, standardised on our own low-code platform, and no-code for the small case that only has to validate something. Those are not tiers of quality. They are different bets about how much of the product is genuinely unusual.
Most products are unusual in one or two places and entirely conventional everywhere else. Naming those places early is a design job, and it decides more about the budget than the choice of framework ever will.
Design that survives the handover
A design hands over well when it says what happens in the unhappy cases: empty states, failures, the slow network, the user with an old phone and no patience. Those are the screens that otherwise get invented during development, at exactly the point where inventing them is most expensive.
The intersection of business, technology and design is not a slogan about being well-rounded. It is the practical fact that the three make each other cheap — and only when they happen in that order.
FAQ
- How long should a design phase run before development starts?
- Long enough to answer the open questions and no longer. In practice that is a sprint or two, run alongside the developers rather than ahead of them.
- Does a design system pay off on a single product?
- Rarely as a component library, usually as a set of decisions: type scale, spacing, states. Write those down on day one and build the components when the second product needs them.
