With the First Move. In one or two working sessions we take your brief and come back with a working prototype of your business, its flows, roles and data, running as software. That is usually days, not months. Then phase zero: the whole system end to end on seeded data, with your methods and setup and sandboxed connections, so every assumption is closed and the blueprint is signed before anyone commits to a date or a fee. You judge us on something real, early.

Phase zero exists so that the price can be honest. Until the assumptions are closed, nobody can quote a build without padding it, which is why most software quotes are either too high or wrong. Once the blueprint is signed we quote a fixed fee for the build. From then the risk of it running long sits with us, not with you. Commercials are sized per engagement from exactly these inputs, so there is no rate card to publish.

You stop, with no commitment beyond that point. You keep the complete specification, which is a full description of the system in numbered lines, enough for any competent team to continue without us. The First Move is deliberately small enough to see the end of, so the decision to go on is made with evidence in front of you, not on trust.

Everything. The platform, the code, the data and the intellectual property live in a repository you control. Every release ships with current documentation and a machine-readable inventory of every component and licence. Acceptance includes building the whole system from scratch on a clean machine, demonstrated in front of you, which is the proof that nothing depends on us. No licence, no lock-in, no residual supplier rights.

The same team that built it. Running it means continuous monitoring, point-in-time backup with restores tested every week, versioned deployments that can be rolled back and security patching against defined service levels. That comes to about a day a week of an engineer. Enhancements are new work, sized per change, delivered in days rather than quarters.

Less than you expect, because we do the thinking. We come to you only for the judgments that are yours to make: where the boundaries of your business fall, what should block a release, what must never be allowed to happen. Every phase has a fixed date and hands over something that works on its own, so there is no open-ended stream of workshops.

Because the standard is held by the build, not by whoever happens to be maintaining it. In most teams quality is held by people being careful and it bends a little at every deadline, every departure, every replacement and it does not bend back. Here every rule is a check the pipeline runs. A standard enforced by the build cannot be waived on a Thursday, so month eighteen looks like month one.

South Africa and the United Kingdom. Write to info@33signals.com. The people who take the first call are the people who do the work, so you are not handed on after the first meeting.

Most of the code is written by a machine and we say so. Writing code was never the hard part. Keeping a build accurate is: deciding what correct means for your business, proving every change against it and holding that standard at module forty as firmly as at module one. That is where the people are. The machine writes only inside controls people have already decided, every test it must pass was written before the code existed and seven automated gates check every change. The machine turns the lights green; a named human ships it.

Faster because nothing is built twice and nothing waits for a meeting. Cheaper because the human hours go where judgment is needed, deciding what correct means and checking that the tests prove it, while the machine takes the typing. On our builds to date that is about half the elapsed time at roughly a quarter of the human effort. The catch is honest: your own decisions and your third parties then set the pace and no method shortens a third party's onboarding.

Not into typing. Into rework and coordination. Every defect found late travels back through hand-offs and every hand-off is a meeting. We remove both: every requirement becomes one signed specification, the single hand-off, read identically by every person and by the machine. Tests are written from it before any code exists, so a defect fails a gate on the change that introduced it and never becomes a loop.

Because the standard is held by people and people bend under a deadline. Any team can write clean code in month one. The question is what the codebase looks like after the tech lead has moved on and a hard deadline has passed through it. We hold the standard in the build instead: seven gates, no human override on red, the hundredth module written to the same rules as the first.

It can write code to a standard without tiring, which is not true of people at four o'clock on a Friday. It cannot decide what correct means for your business. So people decide, with you: where the boundaries fall, which rules apply, what must never happen. The machine then implements until green inside those decisions. You are not buying a system with controls attached. You are buying the controls, with a system attached.

Software that is updated by the work, not by the people doing the work. Most tools make people feed them through forms and dropdowns and what comes back is thinner than what went in. A work system reverses that: your people answer an email, take a call or do the job and the record fills itself. Your people should recognise their own jobs in it on day one.

Yes and you can check without taking our word for it. Every change traces to your signed specification, which describes the system in numbered lines and the tests that prove each line were written before the code existed. What you agreed and what was built are the same document.

Built so that it does not fall apart at month six. The system is made of isolated modules with enforced boundaries, so a change in one place cannot quietly break another. The wrong call between modules is a compile error or a failing test, never something left to a reviewer to notice.

Someone checked, systematically, every time. Tests come from the requirement first, are locked once mature and the whole suite runs again at every step. We also test the tests: deliberate faults are planted in the code and the tests must catch them or the build breaks.

No. Not a single record or document can silently disappear. Every database change is reversible by design and is tested against both an empty system and the previous one and backups are continuous with a restore proven every week. This gate has no amber. It is green, or the release is blocked.

Nobody gets in and nobody sees across. Security scanning happens on every commit rather than as a review before launch, every named control is tied to the threat it answers and we test that one client cannot reach another's data by trying to. An independent penetration test is welcome as a condition of acceptance. No amber here either.

Yes. Every path through the system is observable in production, with health checks, defined service levels that raise an alert and a written procedure for every known failure. Rollback is armed on every deployment, so if something breaks we know before you do and production puts itself back.

Yes, anything, to any reviewer you choose. Audit readiness is built into the pipeline rather than done before an audit. Every action is logged in one tamper-resistant shape, an engineer who did not write a module signs its audit at a specific point in the code's history and an evidence bundle for every module is archived and cannot be changed.

A large test suite can still prove nothing, because a test that never fails is not testing anything. Mutation testing answers it: deliberate faults are injected into the code and the tests must catch them, or the build breaks. The first time we ran it on our own work it exposed exactly this and each gap became a named test.

Project references, banned symbols and architecture tests make the wrong call a compile error or a failing test. It is never left to a review comment, which is where boundary breaches normally slip through when the reviewer is busy.

The specification comes before the test and a person reviews the failing tests before any code exists, so a wrong rule is caught as a wrong sentence rather than a wrong number. The figures the system must reproduce come from your own records, reconciled exactly, so the system is checked against reality, not against itself.

The tests are the contract, so nobody can quietly rewrite the contract to fit the work. A test changes only in its own reviewed change and only when the written requirement changes. The pipeline refuses any code change that edits the tests it must pass.

Every behaviour has a numbered line in a signed document and a test that names it. A new engineer, or a new machine session, starts from the same files the last one did. Knowledge lives in the repository, not in heads, so it does not leave when people do.

Standard, open tooling throughout, nothing proprietary and nothing you cannot hire for. The repository, configuration and all evidence transfer whole at sign-off, with no residual supplier rights and acceptance includes building the system from scratch on a clean machine.

The written description of what the system must do, in numbered lines, signed by you before code is written. It is read identically by every person and by the machine and every test names the line it proves.

The stage after the prototype. The whole system runs end to end on seeded data with your methods and setup, so every assumption is closed and the blueprint is signed before anyone commits to a date or a fee.

An automated check that every change must pass before it can be released. There are seven: requirements, engineering, testing, data, security, operations, audit. Green ships. Amber ships only under a written waiver with a named owner and an expiry. Red has no human override.

The opposite of a black box. At any point you can see not just what the system does but why, because every rule traces back to the requirement behind it and every test names the line it proves.

Software that is updated by the work people already do, rather than software people have to stop and feed. The record fills itself as a by-product of the job getting done.

Testing the tests. Deliberate faults are planted in the code and if the test suite fails to notice them the build breaks. It is how we know a passing test is proving something.