The process, in enough detail to hold us to it.

The first conversation is not a pitch. It is us trying to find out what you are actually trying to prove, who has to approve it, and what happens to the business if it takes twice as long as you hope. Most of what determines whether an engagement goes well is decided here, before anyone has written a line of scope.

What comes out of it is a written scope with an explicit out-of-scope list. The out-of-scope list is the useful half: it is the thing that stops a disagreement in month three from being a matter of memory.

Commercial terms — how the work is structured and billed — are agreed at this stage, in writing, against that scope. We do not begin design work against a verbal understanding.

Week one exists to remove the assumptions that would otherwise surface in week six as rework. It produces documents, not screens, and it is the phase clients most often want to skip.

Work runs in fixed-length cycles agreed at kickoff. Each cycle has a scope written down at the start and a demo at the end. If something has to be cut mid-cycle, it is cut visibly, with a note saying what and why — not absorbed quietly and discovered at the demo.

Design runs ahead of engineering by roughly one cycle. That gap is deliberate: it means engineering is always building against interfaces that have already been reviewed, and design always has a cycle of runway to respond to what build has learned.

The demo is the review. There is no separate reporting document dressing up the same information, because a demo cannot be optimistic about progress in the way a status report can.

A handoff that consists of sending a design file is a handoff that generates a hundred small questions, each answered by an engineer guessing. We do it differently, and it is one of the practical benefits of both disciplines being on the same bench.

Quality is a standing function here, with its own people covering manual and automation testing, rather than a task developers absorb between features. That changes the shape of the work rather than just adding a checkpoint at the end.

You get one shared channel with the working team in it — not a single account manager relaying messages between you and people you never meet. Questions that block work get asked directly, and answered directly.

There is a demo at the end of each cycle, a written note after every decision that changes scope, and a running document of open questions with an owner against each. Anything agreed on a call gets written down; if it is not written down, it was not agreed.

We do not send weekly reports that restate the demo in prose. If a cycle goes badly, you hear it as it happens rather than in a summary at the end of it.

We open with what the work was trying to do — the specific decision it is answering — before showing it. Reviewing work without restating the problem it solves is how a review becomes a taste conversation.

Feedback is collected in one pass, in one place, with a named owner and a date. Conflicting feedback goes back to the decision-maker to resolve rather than being averaged into something nobody asked for.

Where a request would change scope, we say so at the time and price it before it is absorbed, so scope creep is a decision you make rather than a discovery at the end.

Repository access is yours from day one, not at final payment. Design source files, tokens, the component library, the test suite and the deployment documentation are all handed over, editable, without conditions.

At the end of an engagement we write a transition note for whoever takes it on next — your first in-house hire, or another studio. It covers the architecture, the decisions we made and why, and the things we would do differently. A studio that makes itself hard to replace has confused lock-in with quality.