Nothing reaches production until the release gate passes.

The last release passed every check.

The figures come from the last full release of our own platform, the client portal and the operations console behind it. A system we build for you passes the same kind of gate, against a suite written for it.

Every release runs the whole suite.

On 10 September 2026 the suite held 2,584 automated checks, and none failed. It grows with every change, because each new or fixed behaviour arrives with the test that proves it.

The suite covers five areas:

• Money arithmetic, with totals, tax, deposits and milestone amounts tested one function at a time.
• Integration against a stand-in ERP, including the tests that stop one payment from becoming two invoices.
• Golden renders, which hold the contract reviewed on screen and the PDF signed to the same bytes in both applications.
• Parity between the client portal and our operations console, so the two never describe one record differently.
• The shared core both applications rely on.

Some checks guard wording. The warranty terms are written once in the source, and a test fails if the contract text disagrees with them. A phrase retired from our documents is refused by the gate wherever it reappears.

It is sealed off from the live books. A stray call hits a closed local port and fails, and the gate will not start against the production ERP.

What happens if one check fails?

Nothing ships. A failing gate pushes nothing to either application. The defect is fixed together with a test that fails on it first, and then the whole suite runs again from the top, with no partial pass.

The server runs a second set of checks.

Our operations console is deployed by pulling, never by pushing, so nobody copies files onto the server. The server fetches the merged main branch and applies it itself, and its deploy script adds four safeguards of its own:

• A render audit of every client document, which must find no missing values.
• A forward guard, which compares the candidate with what is live and refuses anything that would silently delete or revert work.
• A health-checked swap that returns to the previous image by itself if the new one does not answer.
• A lock, so two deploys can never overlap, and a release number that only ever goes up.

I

f

a

n

y

o

n

e

o

f

t

h

e

m

r

e

f

u

s

e

s

,

n

o

t

h

i

n

g

s

w

a

p

s

a

n

d

t

h

e

r

u

n

n

i

n

g

v

e

r

s

i

o

n

c

a

r

r

i

e

s

o

n

u

n

t

o

u

c

h

e

d

.

The previous release waits in the other slot.

The client portal runs on two identical environments, blue and green. A new release starts in the idle one, and its readiness check must find a served stylesheet and a live session store before traffic moves. The previous release stays in the other slot as the recorded rollback target.

Going back is a single command that points traffic at the other slot. There is nothing to rebuild or restore first.

The technique is borrowed. Martin Fowler described blue-green deployment in 2010, including its use as a rapid way to roll back, and our part is the discipline around it: a gate before the switch, a recorded rollback target after it, and an operator's explicit approval before production traffic moves.

In DORA's terms, it keeps two software delivery measures in view: change fail rate, the share of deployments that need immediate intervention, and failed deployment recovery time.

Your system passes a gate of its own.

Its suite is written as the system is built, and nothing ships until that suite passes. The system launches beside the old version, on your infrastructure or ours, with the rollback proven before anyone needs it. On full payment the source, with its tests and deployment scripts, is yours (§06 of the agreement).

The figures on this page come from our own platform because our contracts, invoices and client records live there, and it takes the full gate on every release.