How we work
Every engagement starts with discovery: we come in, learn what your organization needs and which problem is worth solving, then write a proposal to fit. From there our own development tooling, built to get the most from agentic development, holds every change to five gates.
Five gates on every change.
-
Spec
Scope, the files it may touch, how it is tested and how it ships, written before any code.
You read it in plain English. -
Build
Built one small slice at a time in an isolated copy of your code, under these same gates. Nothing else is touched.
The spec is the boundary. -
Tests
Lint, types, unit and browser tests, every time. Red does not move forward.
Your project's own checks. -
Review
An independent review reads every diff for security, errors and accessibility, and files findings. It never fixes.
The author fixes, the reviewer re-reads. -
Sign-off
The lead engineer reads the record, the tests and the review, then approves or sends it back. A human signs off before anything ships.
Their name is on every release.
What you see at each gate
Spec
Every engagement starts with discovery. We come in, learn how your organization works and what problem actually needs solving, on site when the work happens in the field, and turn that into a proposal sized to fit. Once you approve it, each change gets a written spec: what it does, which files it may touch, how it will be tested and how it ships. You read it in plain English and approve or change it before work starts. If the work later needs to go past that boundary, the spec is rewritten and approved again first.
Build
We built our own development tooling to get the most from agentic development without loosening the discipline around it. Each change is built one small slice at a time, in an isolated copy of your repository that can only touch the files the spec lists. The tooling runs the gates in order, so nothing reaches your product until it has passed the tests, an independent review and the sign-off, and you get a short record of what changed and why.
Tests
Every change runs your project's own checks: formatting, lint, type checks, unit tests, browser tests and an accessibility scan. A red result stops the change where it is. A fix for a review finding ships with a test that reproduces the original problem, so the same bug cannot quietly come back.
Review
A reviewer that did not write the change reads every diff for security holes, error handling and accessibility, and files each problem as a finding with a severity. A finding reads like the ones in the log below: two staff saving at once can double-book a slip. The reviewer never fixes it; the author does, and the reviewer reads it again.
Sign-off
The lead engineer reads the spec, the test results and the review record, then approves the release or sends it back. A human signs off before anything ships, and you keep the record: what changed, what was checked, and who approved it.
The same day, replayed
An example, not a client: a booking portal for a boatyard, invented to show the method. Every change goes brief, spec, build, tests, review, then sign-off. The names and numbers are illustrative.
- changes signed off and shipped
- 1
- test runs, all green before shipping
- 2
- review findings fixed before shipping
- 1
- 08:40 brief Replace the booking spreadsheet with a portal customers can log in to.
- 08:52 spec scope: 3 pages, 1 table, files it may touch listed. sent to the client
- 09:05 client spec approved
- 09:06 build working in an isolated copy of the code
- 09:48 build +212 −0 across 4 files
- 09:49 tests lint ok, types ok, 18 tests pass
- 10:02 review 1 finding: two staff saving at once can double-book a slip
- 10:15 build fixed, with a test that reproduces it. +14 −3
- 10:16 tests 19 tests pass
- 10:19 review re-read, 0 findings
- 10:24 lead engineer reads the record. signed off, shipped
Questions about the process
Who is actually writing the code?
AI tools write much of the code, inside the boundary the spec sets. That changes how fast it gets written, not who answers for it. Every change still passes your project's tests and an independent review, and our founder signs off on every release.
What happens when a test fails?
The change stops. It does not reach review until every check passes, and a fix for a review finding ships with a test that reproduces the original problem. You never get a release with a red check in it.
Can I see a real record?
Yes. Ask on a call and we will walk you through the record of a real change: the spec, the test runs, the review findings and the sign-off. The log on this page is an invented example, so you can see the shape before you ask.
Who hosts it, and who owns the code?
We host, monitor and support what we build on a monthly plan, on dedicated accounts we manage, so it stays patched, backed up and watched around the clock. You own the code: it lives in a GitHub organization you own from day one, with docs written as we build. If you would rather run the hosting in your own name, ask and we will set it up that way.