You know how it works. Whether any of it is true is a different question, and it is the one this page exists to answer.
The claim is unbelievable software.
This is what makes it safe to say.
Two things do the work here: a delivery loop that proves itself at every phase, and a fixed set of gates a build has to pass before anyone sees it. Both are open — you can walk through them yourself.
The gates
Six things every build has to prove
Not a promise about care taken — a fixed set of gates, each producing an artifact you can open. The verdict fails closed: a gate that did not run counts as a gate that did not pass, so silence can never be mistaken for success.
Plan — decide what good means, up front
Roles ratified, a story per role with its acceptance criteria, and a mockup signed off before a line is built.
Why it protects you: The only gate that can prevent work rather than judge it. Every later gate measures against what was agreed here.
Look — prove it was designed, not generated
Every screen screenshotted, accessibility clean at zero serious issues, and a design score against a written standard.
Why it protects you: Generated software announces itself. This is the gate that stops your users being able to tell.
Act — prove it works, driven rather than assumed
A separate worker opens the running app and performs the real task as each role — creates the record, checks the total recomputes, confirms it persisted.
Why it protects you: This is the gate that caught six defects on a build the compiler called clean. Loading a page and finding text is not a test.
Perform — prove it holds up
Page and action timings, behaviour under concurrency, and the queries that will hurt at ten times the row count.
Why it protects you: Performance problems arrive with your data, months after go-live, when they are most expensive to fix.
Document — prove a human can use it, and the next developer can read it
An end-user guide generated from the real screens, plus documentation coverage inside the model itself.
Why it protects you: It is what makes the system survivable without us — which is the point, not a courtesy.
Operate — prove you will know before your users do
Security tested per user role, dependency vulnerabilities, and the monitoring that tells you something broke.
Why it protects you: Security checked as a real user role catches grants pointing at roles nobody holds — which the platform's own checker scores as perfectly clean.
Any one of these on its own is a box-tick. Together they are the reason I can say “done” and mean it — and the reason a build that looks finished sometimes is not.
Every gate in detail, gate by gate How the gates sit in the delivery loop
What a passing release looks like
Six dimensions, graded, on every deploy
The gates produce this. Auditors, security teams and regulators do not accept “trust us” — so every build ends in a measured scorecard, re-run on each deploy and recorded where you can go and look at it.
Automated tests are generated to satisfy every user story and re-run on each deploy, so coverage holds as the application grows.
Every page is scanned against WCAG 2.1 AA and violations are fixed in the model — one change took a grid from 29 serious issues to zero.
Every screen is screenshotted and scored against a written design standard, so a build cannot pass by looking generated.
Checked as a real user role rather than a module role — which catches grants pointing at roles nobody actually holds.
The whole dependency tree is scanned, including marketplace modules — which are the usual source of an unpatchable finding.
Page and action timings under concurrency, so the problems that arrive with real data are found before your users find them.
The overall grade is capped at C whenever the build itself did not pass, so a scorecard can never read better than the thing it describes.
Why we do not trust a green build
The model checker scored zero errors on a build with six real defects
On a real delivery the model compiler reported zero errors on a build carrying six real defects. Driving the running application and screenshotting it is what found them.
A client watching a green dashboard would have shipped all six. That is why a human at Kinetech reviews every build-day of output — including the ones you never look at — and why that review is priced in rather than sold as an upgrade.
Measured, on real delivery
These are counted, not estimated
From a recent rewrite of a large public-sector case-management system — a multi-hundred page specification over a legacy database of millions of rows. The figures come from the agent transcripts and the issue tracker, not from a case study written afterwards.
Same tracker, same workflow, different projects. Story sizes are not normalised between boards, so read this as an order of magnitude rather than a productivity multiple — the defensible sentence is the comparison itself.
On the delivery rate. One build-day is about 11 delivered stories. Measured on a backlog averaging 7.8 acceptance criteria per story (median 6). Your backlog sets your own conversion — which is why we quote build-days, not stories.
The build console
Open it yourself
Every build, every gate, the release scorecard and the risk matrix — with the screenshots taken while the application was running. Your instance gets its own.
Real runs, real decisions
Seventy-odd builds, each with its gates and artifacts — and the approval queue, where a design or release decision sits pending until a human on your side rules on it. Approved, changes requested, and who decided, with the date.
Open the live console ↗Next
Why this conversation is happening now
Tell Marcus where you are — you will leave with a range, the assumptions behind it, and the answers that would narrow it.
Step 3 of 6 — Why believe it?
If that holds up, the remaining question is timing — and for a lot of estates the timing is no longer a choice.