ENGINEERING QUALITY
Correctness isn't reviewed. It's tested.
Every change runs against the full automated suite before it reaches the main branch. No exceptions, no matter how small the change. Here's what's in that suite and why it's shaped this way.
Run in full before every change reaches the main branch.
Before a feature counts as done — not before it counts as started.
Three levels, each catching what the others can't.
Drawn the way it is actually shaped: the base is the widest because most of the truth is checked there.
End-to-end tests
Every endpoint, exercised as a genuine HTTP request from start to final response.
Integration tests
Run against a real database and a real message queue, not mocks. Real bugs — transaction conflicts, unique-constraint violations, queue behaviour — only appear against real systems. Mocking them means testing your assumptions instead of the system.
Unit tests
Business logic, calculations, validation, and domain rules. Fast and isolated.
We list every scenario before writing a single test.
Before any test is written, the possible scenarios are enumerated explicitly. Then each one gets its own test.
- The success path
- Every failure path
- Boundary conditions
- Authorisation
- Concurrency
- Error handling
Which makes test-writing a systematic process rather than an act of imagination — and means no branch quietly ships untested because nobody thought of it at 6pm on a Friday.
No endpoint ships without all five.
Not five suggestions. Five tests that must exist and pass before an endpoint is called finished.
01
Unauthenticated request
Must be rejected.
02
Insufficient permission
Must be rejected.
03
Invalid input
Must return a precise, specific error.
04
Success, verified against the database
Not just a 200 response. The record must actually have changed, correctly. Checking the HTTP status alone is how “it works” becomes “it silently didn't.”
05
Another user's data
A two-user ownership test proving one account cannot reach another's records.
Security isn't a separate review afterwards.
Security scenarios sit on the mandatory list for every relevant feature. A feature isn't complete until they pass — security is part of “done”, not a phase that happens later if there's time.
- Cross-organisation data leakage
- Permission escalation
- Upload restriction bypass
- Formula injection in exports
- Abusable payment links
Every endpoint has a number.
Alongside functional correctness, each endpoint is measured against a defined millisecond target using a real load tool — not a stopwatch in a test run. The measured figure is recorded and tracked over time, so gradual slowdown is caught early rather than discovered by a customer.
“It feels fast” is not a measurement.
Nothing merges without passing all of it.
- Type check
- Lint
- Format
- All tests green
- Build succeeds
Run for every change, however small. There is no fast lane.
Docs that can't drift.
The API documentation is generated from the same definitions the code uses, so it can never diverge from the real implementation. On top of that, a conformance sweep runs across the entire API surface — five rules, checked against every endpoint there is:
- 01Every protected endpoint must reject an anonymous request.
- 02Every error must use the standard envelope, with a registered code.
- 03Every successful response must declare its shape.
- 04Every list must paginate.
- 05No new unbounded input may be introduced.
Every exception has to write down its reason.
Ask us the uncomfortable question.
Test coverage, incident history, how we handle a regression — we'd rather answer now than after you've committed.
- We reply within one working day
- No sales sequence, no drip campaign
- NDA before the call if you'd prefer