How we think.
The whole method in one line: understand the business first, decide what should exist second, build third. What follows is what that means in practice, stage by stage.
Building is the easy part.
Development is a solved problem in the sense that competent people can be found to write code. What is scarce is the judgement that happens before it: deciding what should exist, what should not, and in what order.
A project fails far more often because it built the wrong thing well than because it built the right thing badly. The wrong thing is expensive in a particular way, too — it works, so nobody can point at a bug, and it quietly fails to change anything.
So we spend the early time on questions rather than estimates. Not because it is more interesting, though it is, but because that is where the money is decided.
Six stages, in order.
Each stage produces something you can read, question or reject. No stage ends with "trust us".
We spend time on the business before the build. What it sells, who buys and why, how an order or an enquiry actually travels through the company, who touches it, where it stalls, and what people have quietly built workarounds for. This is conversations, a look at how the work runs now, and, where it helps, time with the people who will use the thing.
You receive
A written summary of what we understood, in your language rather than ours. If we got something wrong, this is where it becomes visible and cheap to fix.
Typical duration
One to two weeks
We decide, together, what should be built. That means naming the objective in a form that can be checked later, agreeing what is in scope and what is deliberately out, and being explicit about constraints — budget, deadline, existing systems, the people who will maintain it.
You receive
A scope document: what will exist, what will not, what it is for, and how we will know whether it worked. This is also where we say plainly if we think the project should be smaller, staged differently, or not done at all.
Typical duration
Three to seven days
The skeleton. Information architecture, page or screen inventory, user flows for the paths that matter, data models, permissions, and the states each screen has to handle. Nothing here is decorated; it is the shape of the thing.
You receive
A structure document and flow diagrams. Dull to look at, and the cheapest possible place to change your mind.
Typical duration
One to two weeks, depending on complexity
Layout, interface, typography, tone and behaviour. We design the difficult states first — the empty list, the very long name, the failed payment, the slow connection — because those are where products actually feel broken. Visual polish comes after the states work.
You receive
Designs for the key screens plus their states, and the component set the rest of the build is assembled from.
Typical duration
Two to four weeks
Development in reviewable stages, with something you can open and use as early as it is useful. Technology chosen against the four questions on the What We Build page. Code written to be read by whoever inherits it.
You receive
Working software in stages, a test environment, and documentation for anything that needs it.
Typical duration
Varies with scope; the estimate is given at the end of stage 02, not before
We ship it, watch how it is used against the objective agreed in stage 02, and fix what the first real week reveals. After that, improvement continues only where the project justifies it. We are not interested in a retainer that bills for maintaining momentum.
You receive
A live product, handover of everything needed to run it, and an honest view of what is worth doing next.
Typical duration
Ongoing, by agreement
What we need from you.
The method only works if it runs in both directions. Three things make the difference between a good project and a slow one.
Access to the people who do the work.
Not just the decision-maker. The person who processes the orders knows things nobody has written down.
Honesty about constraints.
The real budget, the real deadline, the internal politics, the system you are contractually stuck with for two more years. We can design around a constraint we know about.
Decisions at the points that need them.
We will flag them clearly and give you what you need to decide. A project waiting three weeks for an answer is a project getting more expensive quietly.
In return: we will not surprise you with an invoice, a scope change or a technical decision you did not agree to.
How a project usually starts.
Nothing formal, at first.
Start with a description.
A paragraph about what you are building is enough to begin. You do not need a specification, a budget, or a decision.
Discuss your idea