Discover. Commit. Ship.
Playbook
01 · Why we publish this
Why we publish this
This page is the standard the work is held to, from first contact through handover. It applies to the practice leads and to the engineering team behind them without variation.
02 · How an engagement runs
How an engagement runs
Every engagement runs the same three phases, in the same order, whatever the size of the work.
Discover
Discover establishes whether an engagement should run at all. It opens with a single qualifying conversation and closes with a priced proposal.
| Stage | What it covers |
|---|---|
| Qualifying call | Who the work is for, what the system actually is, and the budget standing behind it. This call decides whether the rest proceeds. |
| What we ask for | The brief, existing documentation, access where it matters, and the one question that decides the engagement for you. |
| What we do | Read, interview and return with questions. |
| What you receive | A proposal stating the architecture, an estimate in hours, the risks identified, and a capped price for Commit. |
Commit
The proposal fixes three things. Each is stated before work begins, and none of them moves without a written change.
| Fixed | What it means |
|---|---|
| Scope | One approach, carried through. We do not hedge across parallel options. Where an architecture proves wrong we say so at the next demo and re-scope in writing. |
| Cap | The maximum hours the build can take, and the ceiling on what you pay. |
| People | The Named senior, assigned per project and named in the proposal, and the project manager who owns the schedule. Contract-touching work is rank 1 and carries two reviewers. |
| Service Classification | The proposal also states whether the engagement concludes at handover or constitutes an ongoing service. Regulated clients require that classification for their register of information, so it is drawn at the outset. |
Ship
Delivery is visible weekly. Working software on staging is the status report, and no separate progress document is produced.
| Ship | What it means |
|---|---|
| Weekly demonstration | Working software on staging, from the first week that has anything to show. |
| Findings | Logged where you can see them, each with a severity and a fix date. |
| Incidents | Reported the day they are known, with what happened, what it touched, and the remediation in progress. A written post-mortem follows. |
| Handover | The repositories with history, the deployment pipeline, the runbook, the architecture record, and a working session with whoever takes it on. |
| Done | The system runs in your environment, under your keys, with your people able to change it. |
03 · What we do not take on
What we do not take on
A project built to ride a narrative
A product with no PMF, riding a hype wave that is fading, so the date is whatever is left of the wave. The build gets cut to fit, and the token that ships pays the people who got in early out of the people who get in next.
Staff augmentation by the hour with no scope
Our sign-off process requires a scope to sign against. The right kind of company in this situation is an outstaffing firm, we can put you in contact with two companies we would vouch for.
A product we could not take on morally
A gambling app, a swipe app, an AI girlfriend, a vape that pays per puff, a game that pays for the hours, DeFi where it becomes evident the users end up financially ruined. If it sounds like something unethical, we decline it in Discover.
04 · How we price
How we price
Builds run to a capped price, billed by milestone against the hours actually spent. Land under the estimate and you pay less, run over the cap and the difference is ours to absorb.
- What sets the cap. The complexity of the system, the length of the engagement, and how much of the team it holds.
- What changes a price after Commit. A scope change you request, a dependency supplied late, or a decision deferred past the date the plan requires it. Each is priced before it happens.
We publish no rate card. A rate quoted without the work in front of it is a guess, so the number arrives in the proposal, before anything starts.
05 · Sign-off
Sign-off
Four rules govern every engagement, regardless of who does the typing.
| No | Rule |
|---|---|
| 01 | Architecture set by the practice lead who owns the engagement. |
| 02 | Every pull request ranked for security impact and reviewed by the practice lead whose domain it touches. |
| 03 | The rank determines the reviewer. A deadline does not change the rank. |
| 04 | Weekly demonstrations, working software, and honest attribution in every report. |
The mechanics behind those four rules are set out in the security practice below.
06 · Security practice
Security practice
Every pull request is ranked for security impact when it is opened, and the rank determines who reviews it and what must be true before it merges. Ranking at that point is deliberate: the reviewer is assigned before anyone knows whether the change is running late.
| Rank | Scope | Reviewed by | Conditions of merge |
|---|---|---|---|
| 1 | Smart contracts, and anything else that can move value | Nick and Dominik, both | A written threat model. The review checklist run in full. Fuzzing and invariant tests passing in CI before review is requested. No rank 1 change merges on one signature. |
| 2 | Infrastructure configuration: networking, identity and access, secrets management, deployment pipelines | Nick, or the project's Named senior | Never reviewed by its author. Secrets do not appear in a diff, and a rotation follows anything suggesting one did. |
| 3 | Databases: schema, migrations, access paths | Named senior, with Nick where the data is personal or financial | Every migration ships with the rollback that undoes it. |
| 4 | Backend services | Named senior | Dependency updates are read. A version bump alone does not merge one. |
| 5 | Front-end services | Named senior | Standard review. |
The rank 1 checklist covers access control, reentrancy and external calls, arithmetic and precision, upgrade paths, events, and off-chain assumptions.
Three conditions apply across all five ranks:
- Key material. We hold none of yours at any point. Custody is HSM, MPC or client-held, agreed per engagement and recorded in the proposal.
- Formal audit. Performed by a recognised third party. We prepare the code, the documentation and the scope, and remediate what they find.
- Incidents. Reported the day they are known, with a written post-mortem to follow.