Not accepting new projects. The spec is what drives development, and our engineers are at capacity writing them. Write to us anyway and we will tell you when that changes.
Accepting new projects. We have engineer capacity for spec work and can start a first feature spec with you.
Manifesto
You can read exactly how your work will be specified, tested, released and billed before you commit to anything, and hold us to it afterwards.
Eliminate the human as a bottleneck in the development cycle without giving up control over what gets built. Control is not exercised by reading code: it is exercised over the specs and over the tests, artefacts that are smaller and more stable than a diff.
This method applies to new projects. It does not apply to inherited codebases, because it presupposes that every existing behaviour is specified, and in pre-existing code that does not hold.
1. The spec is the contract. There is a product spec and a technical spec. The technical one is derived from the product one. Agents use both and the client has access to both.
2. What is not in the spec does not exist. No agent may add unspecified behaviour, however obvious or beneficial it seems.
3. Code is not reviewed. The spec is reviewed and the tests are reviewed. The diff does not pass under a human eye.
4. Tests are approved before an implementation exists. A test approved after seeing the code guarantees nothing: it may have been shaped around it.
5. Whoever writes the tests does not write the code. The test agent receives the spec and the public interfaces. Never the implementation.
6. The implementation agent does not modify tests. It may read them. An implementation commit that touches test files is rejected automatically.
7. Ambiguity stops the work; it does not divert it. An agent that cannot derive behaviour from the spec halts and opens an issue. It does not decide on its own.
8. Every assumption is declared and reviewed. Each agent delivers, alongside its work, the list of assumptions it made. Any engineer on the team reviews it against the spec: every assumption must correspond to an existing requirement. One that does not is an ambiguity and blocks the merge.
9. Every requirement is traceable. A requirement with a unique identifier, the tests that cite it, the commits that implement it. A requirement with no test covering it blocks the pipeline.
10. The client sees what we see. Specs, state, open issues and unresolved ambiguities, in the same dashboard and in real time.
11. A feature spec the client cannot verify alone is not finished. Its acceptance criteria are stated as observable claims the client can check without help from the team.
Technical specs are derived from product specs. Feature specs are agreed with the client, who has access to both groups.
The set of specs hanging off a feature forms a file with its own identity, rooted in its feature spec. It is not a spec type: it has no requirements and no template, and its state is derived from that of its members.
It is the unit that is billed, the unit the client approves in the showroom, and the root of traceability.
Every requirement generates happy-path coverage, the edge cases declared in the spec, and invariant properties verified by property-based testing and fuzzing. The invariant properties are not optional: they are the only defence against an implementation that satisfies the written cases and misbehaves outside them.
An incomplete, ambiguous or contradictory spec is a defect of the method, not an expected accident. When it happens, the agent stops and records it on the spec's card in the dashboard. The ambiguity is resolved by modifying the spec to cover it, generating the corresponding tests and re-approving them. How often these stops occur per spec is the primary health metric of the method.
Ambiguity is classified on detection according to whether it affects observable behaviour.
It is observable if it changes something the client or end user can perceive: API contract, interface, data persisted and returned, error messages, calculations with an economic effect, or perceptible temporal behaviour. The client resolves it.
It is not observable if two different resolutions produce the same external behaviour. The team resolves it and documents it in the corresponding technical spec.
When classification is in doubt, the ambiguity is treated as observable.
Scope is not estimated: it is derived from the traceability graph between requirements, tests and technical specs.
Every spec has a state visible in the dashboard: draft, in client review, approved, in implementation, delivered, amended.
Client approval is a formal act recorded in the dashboard, with identity, date and spec version. It binds to that specific version.
The client does not have to draft. Drafting is the team's work, even when the requirement originates with the client. What is not delegated is approval: there is no mode of operation in which a feature advances without the client having formally approved it. A client who does not accept that condition cannot work with this method.
No agent may work on a feature spec that is not in the approved state. An amendment affecting observable behaviour returns the spec to client review and requires new approval. A non-observable amendment is notified to the client without requiring their approval.
The work is iterative. There is a periodic meeting with the client where new specs are defined, existing ones amended, and the accumulated observable ambiguities resolved. The default cadence is fortnightly and is adjusted to the project.
That cadence is the method's latency floor: an observable ambiguity waits until the next meeting. The method assumes that wait and compensates for it by keeping work moving in parallel on unblocked requirements.
Pending ambiguities are visible in the dashboard from the moment they are detected, not from the meeting.
When an amendment invalidates tests covering already merged code, that code is marked as debt and reimplemented. The debt is not silent: the tests corresponding to the amended spec are generated, approved, and left red until the reimplementation satisfies them.
A requirement in debt appears as unsatisfied in the dashboard, with the same visibility to the client as any other state. No requirement may be listed as delivered while it has approved tests that do not pass.
Whether code in debt stays in production is decided on the same axis as ambiguities. If the current behaviour is not observable, it stays deployed. If it is observable and contradicts the current spec, it is reverted or disabled. If it is observable and merely different from what was amended, the decision belongs to the client and is recorded in the dashboard.
Every failure detected in production with the suite green is classified by asking what the spec determined about that case:
The proportion between the three categories indicates where the method is losing: in test generation, in spec writing, or in definition with the client.
A failure reported by the client enters immediately if it is described with its template and with no ambiguous fields. Validation has two steps: an agent checks the report against the template and flags incomplete or ambiguous fields, and an engineer confirms admission. If it cannot be described that way, it waits for the periodic meeting, where the description is completed before admitting it.
An admitted failure whose correction cannot wait for the batch is handled as a hotfix. The hotfix has its own spec type and template, is approved like any other, and is deployed straight to production, outside the batch.
It is not an exception to the method: it generates its tests and passes the same gates. The only thing that changes is the route to production.
An amendment preserves requirement identifiers: unaffected requirements keep their tests, their history and their approval.
A rewrite generates new identifiers, forces the whole suite to be regenerated and re-approved, requires new client approval of the entire spec, and breaks the link between the old requirements and already merged code.
Rewriting pays off when maintaining the traceability of a fragmented spec costs more than regenerating it whole. The dashboard flags specs whose proportion of requirements affected by corrective amendments exceeds the agreed threshold, and the decision is taken at the periodic meeting.
An agent that fails to turn an approved suite green stops when it exhausts its budget of attempts and opens an issue. It does not continue indefinitely.
Diagnosis has two steps. First it is checked whether the suite is inconsistent, that is, whether it contains tests demanding mutually incompatible behaviours. If it is not, it is examined whether the spec is unrealisable with the current architecture and constraints.
Both outcomes are resolved the same way: amendment of the spec, regeneration of the affected tests and new approval.
No test is modified to unblock an implementation. An approved test changes only by spec amendment. If that rule is broken once, prior approval of the suite stops guaranteeing anything.
Every merge is deployed automatically to a showroom environment. The step to production requires client approval of what they see in the showroom.
These are two distinct approvals at distinct moments: the spec approval fixes scope before building, the showroom approval authorises publication of what was built. If the client rejects in the showroom something that satisfies the approved spec, what is described under Scope and changes applies: it is a change of requirement, not a defect.
The step to production happens in a batch after the periodic meeting, where client and team jointly decide what goes in. The meeting cadence therefore governs the total time to production, not only the resolution of ambiguities.
A failure detected in the showroom is treated the same as one in production and follows the same classification. The record notes which environment it was detected in: in the showroom means the method contained the failure, in production means it escaped, and that distinction is what makes the metric useful.
Product and cross-cutting specs are written in parallel with the first feature. Neither can be completed in isolation from the other.
During that start-up, structural amendments are frequent and block entire files. That is an accepted cost of the method, not a sign of failure, and should be read as an alarm only if it persists beyond the first few features.
The approved spec defines the scope. A delivery that satisfies the approved spec is a correct delivery.
The client may reject it. That rejection is not a defect: it is a change of requirement, it enters the cycle as an amendment, and it is billable. Formal approval of the spec is the moment at which scope and its cost are fixed, which is why the spec must be verifiable by the client before they approve it.
A new requirement introduced outside the periodic meeting waits for the next meeting.
The billing unit is the approved feature spec. Formal approval fixes both the scope and its price.
That unit creates an incentive to fragment features into small specs. The signal that detects it is the number of requirements per spec, which is already recorded: a sustained drop in that figure indicates fragmentation, not simpler features.
Invoicing dates and how an amendment is billed are agreed with each client. They are contract terms rather than part of the method, and fall outside this document.
The dashboard exposes five metrics:
Each project fixes its thresholds in a document of its own. The manifesto establishes the default values that document overrides. The current values are starting points to be calibrated with real data:
The size of a feature is measured by its number of requirements, which traceability already records. Team capacity is expressed in simultaneous requirements per engineer, not in features, and its value is fixed per project once there is data.
The spec dashboard also works as the issue tracker, and the client has access. They see states, requirements, open ambiguities, debt and pending approvals.
Specs are readable and downloadable from the client area in every version. Each approved or amended version is additionally sent by email, so that a record exists outside the system.
A requirement is delivered when it is deployed in production, with all its approved tests green and with no associated debt. Neither the merge nor the showroom deployment counts as delivery.
The metric of time from spec approval to delivery is measured against that definition, and therefore includes the wait for the production batch.
A migration that only adds structure over existing data is reversible and poses no problem. The risk appears when the operation transforms or destroys data already present: dropping a column, changing a type, splitting or merging tables, adding a constraint that existing rows may violate, or deriving values from other fields. In that case the failure is not corrected by retrying, because the loss is irreversible and no later test undoes it.
This is not an exception to the principle of not reviewing code. The migration is specified in natural language inside the spec, and the agent translates it into SQL. What is reviewed is the spec, as with any other requirement.
Nobody verifies that translation by reading it, so every migration that transforms or destroys existing data is first rehearsed in the showroom against a copy of the production data. The rehearsal is a condition of entry to the batch: an unrehearsed destructive migration is not deployed.
The method guarantees behaviour that can be expressed as a test. What cannot be expressed that way falls outside that guarantee: typography, visual hierarchy, the tone of the copy, the sense of fluidity and, in general, every aesthetic or perceptual judgement.
Two mechanisms narrow it. The view spec specifies in advance everything that does admit a statement — structure, states, copy, interaction behaviour — and a UX engineer exercises the feature against that spec before merge. That check verifies conformance; it does not issue an aesthetic judgement.
What falls outside both is settled at the showroom approval, when it is already built: there the method detects the problem but does not avoid the rework.
That rework is classified by its scope. If it affects the layout of a specific view, it is an amendment to its view spec. If it affects the global design system, it depends on whether it was specified: what was specified and not met is a defect, and what was not specified is a new requirement.
Fast iteration and features delivered in days. The human cost concentrates on writing precise specs and approving tests, two activities that scale better than reading diffs.