One brief, six disciplines: how a launch actually runs

Most software projects do not fail at the keyboard. They fail in the gaps — between the designer who never heard about the rate limit, the engineer who found out about the compliance requirement in week nine, and the person who has to keep it running and was never in the room.

Agencies usually manage those gaps with process: a document per hand-off, a meeting per document. We took the other route and hired across all six disciplines, so there is no hand-off to manage. This is what that looks like on an actual project.

Week zero: the brief is one paragraph, not a specification

We ask for the problem and who has it. Not a feature list — a feature list is already a set of answers, and it is usually the client guessing at our job. A good brief sounds like: "Our four support agents spend most of the morning answering the same twenty questions, and we are losing evenings entirely."

From that, one plan goes back. Not six plans stapled together — one document that names the disciplines the project needs, the order they enter in, what the first release contains, and a price. If two disciplines are not needed, they are not in the plan and not in the price.

Weeks one and two: the expensive decisions, made early

The decisions that are cheap now and ruinous later all get made in the first fortnight, in one room:

• The data model. Almost every painful rewrite we have been called in to fix was a data model decided by whoever happened to be building the first screen.
• Where it runs, and in whose account. Infrastructure in the client’s own cloud account from day one, because moving it later is a project of its own.
• What "done" means for the first release, written as the list of things a real user must be able to finish.
• Whether the product needs to work offline, and on which platforms. Offline is a data-layer decision, not a feature you add in month four.

QA is in that room too, which surprises people. A tester’s first question is usually "how would I know if this broke?" — and asking it before anything is built changes what gets built.

The build: a working thing every week

Every week ends with something you can open and click through, deployed somewhere you can reach, plus a short note on what changed and what is next. Not a screenshot, not a status percentage. A percentage is an opinion; a build you can use is a fact.

This is also the honest part of the arrangement. A weekly build makes it obvious very early if we have misunderstood you, which is uncomfortable in week two and catastrophic in month four.

A percentage is an opinion. A build you can open is a fact.

Launch: the boring version is the good version

By the time a release goes out, the pipeline that ships it has already shipped it many times, to a staging environment that matches production. Launch day is the same reviewed action as any other day, which is why it is uneventful.

Three things are in place before we call something live: automated tests covering the paths that would embarrass you if they broke, error and performance monitoring with alerts routed to a person who can act, and a rollback that has actually been tried rather than merely documented.

After: the same people

The engineers who built it keep it running. This is partly a promise to clients and mostly a design constraint on ourselves: a team that will own the thing in eighteen months makes different choices in week three. Nobody who has to carry the pager cheerfully ships a clever hack.

None of this is exotic. It is what a good in-house team does. The only unusual part is buying it from outside your company — and the reason that is rare is that most agencies are organised around one discipline and subcontract the rest.