33signals signal over noise

Regulated-grade engineering.
Fast by design.

How we build, in the short version: three questions, four stages, seven gates, when the risk is retired and the time and effort side by side - each with the picture that shows it. The full framework is one click away.

From first principles

Strip the problem to what has to be true and the method follows. Three questions, three answers and everything on this page is a consequence of them.

01Where does software time actually go?

Not typing. Rework and coordination. So we remove both: every requirement becomes one signed specification, the single hand-off and tests are written from it before any code exists - a defect fails a gate on the change that introduced it and never becomes a rework loop.

02Why does good software go bad?

Because the standard is held by people and people bend under a deadline. So the standard is held by the build: seven gates, no human override on red, the hundredth module written to the same rules as the first.

03What can a machine do and what can it not?

It can write code to a standard without tiring. It cannot decide what correct means for your business. So people decide, with you - boundaries, rules, what must never happen - and the machine implements until green inside those decisions.

Accuracy is the speed. Nothing is built twice, nothing waits for a meeting and the standard is enforced by the build itself.

Rework is a loop; we build in a line. A traditional cycle of build, test, find and fix repeats every sprint. Ours runs once, from specification to shipping. TRADITIONAL every sprint Build, test, find, fix - and back again. OUR FRAMEWORK specifytestbuildgateship once A defect fails a gate. It never travels back.

Rework is a loop. We build in a line. The specification is the only hand-off and every gate is a check the pipeline runs rather than a meeting someone must hold.

How an engagement runs

Stage 1Understand it

One or two working sessions in, you're looking at a working prototype of your business - flows, roles, data - running as software.

Stage 2Prove it

Phase zero: end to end on seeded data, every assumption closed, the blueprint signed. Part ways here and you own the full specification.

Stage 3Build it

Written fresh to the blueprint, module by module, each accepted before the next - under seven automated gates.

Stage 4Maintain it

Watched, drilled and patched against defined service levels - about a day a week of an engineer.

The seven gates

Nothing ships unless seven questions answer green - and the pipeline, not a person, holds the line:

1RequirementsDoes it do exactly what was agreed?
2EngineeringIs it built right?
3TestingIs it proven, not promised?
4DataCan it lose or corrupt anything?
5SecurityCan it be breached?
6OperationsCan it be run, watched, fixed?
7AuditCan we prove it all, to anyone?

Red has no human override - the only way past it is to fix the code. The machine turns the lights green; a named human ships it.

When the risk is retired

Traditional builds carry their risk to the end: integration is discovered at hardening, tests catch up last and the slips live exactly where the time has run out. We sequence the other way: the highest-risk, least-known items are attacked first, in design, analysis and phase zero. What remains on the critical path is your own decision loop and third parties - which puts the schedule in your hands, not ours.

Unretired risk over the engagement: the traditional line stays high until the end; ours falls steeply through phase zero and stays low. highlow startphase zero endsgo-live risk still open Traditional: risk retired last, at hardening Ours: assumptions closed in phase zero What stays open after phase zero is your own decisions and third parties - the same in both.

Measured, not promised

The anchored build from the model on the full framework, at its defaults. The ratios come from that build's plan and are deliberately more conservative than the pace we have measured on our builds to date - offered as the shape of the answer, not a guarantee.

Traditional teamOur framework

Elapsed time to go-live: 13 months traditional against 7 months this framework. Human effort to go-live: 97.5 person-months against 25.3. Elapsed time to go-live months Traditional Traditional: 13 months 13 Our framework Our framework: 7 months 7 1.8× faster Human effort to go-live person-months Traditional Traditional: 97.5 person-months 97.5 Our framework Our framework: 25.3 person-months 25.3 3.8× less human effort

A ten-person team at typical allocation over thirteen months, against a central build team of three engineers in parallel streams. Effort is human person-months; the machine's work is not part of that number.

The full framework - lifecycle, gates, effort, risk and the evidence behind every claim - is one page deep. Read it, then put it in front of your technical reviewers.

Read the full framework

We welcome the interrogation - it's what the whole framework is built for.