03 / Process

How the work runs

Four stages, in order, each ending with something you can hold. The same shape whether the project is a marketing site or a system that runs the business.

Understand

We map the real workflow, constraints, and success signal with the people closest to the work.

Before anything is designed we find out how the work is done now, including the parts that never made it into a process document. This is the cheapest stage to be wrong in, so we spend it deliberately.

You get: a workflow map + an agreed success metric

Sessions with the people doing the work

We talk to the operators, not only the sponsors. The constraint that decides the whole design is usually held by someone who was not in the kickoff.

One success metric, agreed in writing

We name the number that has to move before we design anything to move it. It settles scope arguments later, at the point where they get expensive.

Shape

We prototype the critical path early, test the assumptions, and agree what belongs in the first release.

Shaping is where the risk gets taken out. We build the uncertain part first, in a form you can click, so the open questions are answered by evidence rather than by opinion.

You get: a clickable prototype + a first-release scope

The critical path, prototyped first

We build the riskiest screen before the easy ones. A week with a clickable prototype answers what a specification argues about for a month.

A first release you can defend

We cut to what earns its place in version one and write down what was postponed, so it stays a decision rather than an omission nobody noticed.

Build

Design and engineering move together in short, visible cycles with working software every week.

Design and engineering run as one track rather than two. Every week ends with something you can open, which is what keeps a build honest about where it actually is.

You get: working software, demoed every week

Working software every week

You see progress in the product rather than in a status report. When a direction is wrong, it is caught in the week it happened, not at handover.

A core built to be changed

Typed, tested, and documented where it matters. The second year of a system costs more than the first, so we build for the second year.

Evolve

We launch carefully, measure what happens, and keep improving the system where it creates leverage.

Launch is a stage in the work, not the end of it. We release in steps, watch the metric agreed in the first stage, and stay available for the changes that only become obvious in production.

You get: a measured launch + an improvement loop

A launch that is measured

We release in stages, watch the number we agreed on, and keep a rollback path open until the behaviour under real load has settled.

An improvement loop that keeps running

After launch there is a standing line for fixes and changes. A system that stops changing starts drifting away from the business it serves.

Where does your project sit?

Most start at stage one, some arrive with the map already drawn. Tell us which and we will pick it up from there.

Start a project