Your data stays your data
No extract from your database, no client document, no personal data is submitted to a third-party service without written agreement and a defined scope. Test data is generated or anonymised.
Method
The workshop is open.
There is nothing to hide in a way of working: the hard part isn't knowing it, it is holding to it every day. Here is ours, safeguards included.
The cycle
Four stages
They change neither with the size of the project nor with the client. Only the length of each stage varies.
Scope it, and write it down
Every structural decision fits on one page: the problem, the option chosen, the options ruled out and the reason for ruling them out. These pages are numbered, dated, version-controlled alongside the code, and never rewritten — a new one is added that supersedes the previous.
Why: eighteen months later, nobody remembers why that choice was made. With no written record, it gets replayed — usually worse.
Show before promising
Clickable screens within days: complete journeys, edge cases, error messages, empty states. Corrections are made on something visible, before a single line of business code exists.
Why: it is the only moment when changing your mind costs almost nothing.
Deliver in increments
One increment = one usable feature, its tests, its documentation, in the same commit. Continuous integration is the final word: a green suite on a developer's machine is not a delivery.
Why: a project that delivers every fortnight cannot drift by six months.
Operate, then hand over
We hold production, publish a readable monthly report, and write down everything someone else would need to take over: deployment, restore and secret-rotation procedures.
Why: an irreplaceable supplier is a risk, not an asset.
The tooling
What the machine does,
what the human keeps
Our tools write code, review code, test code, and produce a good part of the documentation. That is what explains our lead times. It is not what makes the result good: quality comes from what we don't entrust to them.
Anything generated and not reviewed is a draft. A merged draft is debt. So the boundary is written down, and it does not move with schedule pressure.
Entrusted to the tooling
- Writing the first version of a module from a written specification.
- Producing the tests for a behaviour that has already been decided.
- Reviewing a diff and flagging what smells wrong.
- Migrating repetitive code, renaming, reorganising at scale.
- Writing and maintaining the technical documentation.
Kept by the human
- Deciding the architecture and owning the call.
- Approving anything touching money, personal data or security.
- Signing off the merge. Always: nothing goes in without a human reading it.
- Telling the client what is wrong, and when to give up on something.
- Carrying responsibility for what is delivered. That cannot be delegated.
Safeguards
Five rules that are not negotiable
They appear in our contracts. A client who asks for them to be relaxed gets a refusal, not an exception.
No secret travels
API keys, passwords, tokens: never in the code, never in an external tool, never in a message. Stored encrypted, rotatable, and rotated when anyone who had access leaves.
Human review is mandatory
Nothing is merged without having been read by a human who takes responsibility for it. No emergency, no demo, no commercial milestone justifies an exception.
Everything is traceable
Dated decisions, complete history, an up-to-date changelog. Who decided what, when, and on what basis can be reconstructed — two years later.
You remain the owner
Repository, infrastructure, domain names, service accounts: in your name from day one. An exit that has to be requested isn't one.
And when we get it wrong
We say so, we fix it at our expense when it is our doing, and we write down what was missing so it doesn't come back. That is the only guarantee worth anything.
The proof
What blocks a delivery
A machine, not an opinion. The pipeline runs on every change; as long as one light is red, nothing ships.
| Stage | What it checks | If it fails |
|---|---|---|
| Type checking | No type errors, no shortcut hidden by a build cache. | blocking |
| Linting | Project conventions, dead imports, hard-coded untranslated strings. | blocking |
| Unit tests | Business behaviours, without ever touching a real database. | blocking |
| Integration tests | The modules together, on a throwaway database, with time zone and locale forced. | blocking |
| Load & concurrency | On the points where two simultaneous customers could tread on each other. | blocking |
| Image build | That what goes to production is exactly what was tested. | blocking |
| Pre-deployment check | Variables present, every migration referenced, a recent backup in place. | blocking |
Date tests run with the production time zone and locale forced. Without that, a green suite can lie: it happened, once. Only once.
Interested in this way of working for your own team?
That is exactly what we set up for you: the tools, the safeguards, and how to use them without losing your grip. With our expertise, on your code.