Software that runs is not software you can trust.
A domain expert who knows how a bar bending schedule is really calculated, or how a snag list moves between an architect and a site contractor, can now build the software for it directly. Viya had produced a substantial platform this way before we were involved at all.
The gap is invisible from outside. The application looks finished: users log in, screens load. What you cannot see is whether one customer’s data can reach another’s, whether a departing employee’s access actually stops, or whether the thing the screen said it saved was ever saved at all.
The applications were real and working. What they lacked was everything that only becomes visible when something goes wrong.
Four things asked of us. Two pieces of work, two standing capabilities.
Audit and raise to standard
Examine what the team had already built, find everything that would stop it being run as a production system, rank it by severity, explain each root cause and specify the fix. The first pass is a baseline; after that it becomes a weekly gate.
Two new modules
Payroll processing, and a bar bending schedule tool with paid per-project access and offline payment approval. Built to the standard the audit defines rather than audited into it afterwards.
Infrastructure they own
Move code and hosting off personal accounts and third-party platforms onto infrastructure the business owns and controls, with access that survives someone leaving.
Guardrails and support
Turn recurring problems into standing rules that reach the team while they build, and be reachable between cycles for the decisions that are expensive to get wrong.
They build. We hold the standard.
Five layers, read top to bottom: what the business gets, who builds it, how the rules reach them while they are building, the loop that governs the result, and the mechanism that makes each cycle cheaper than the last.
A six-step loop, once a week.
The step that matters is the last one. Each cycle is supposed to make the next cycle’s problems less likely — not merely fix this week’s.
- Step 1 Build The team builds features on its own priorities. Where the work touches payments, authentication or sensitive data, the approach is settled with us before it is written. Client · we are on call
- Step 2 Audit Everything built since the last cycle is reviewed against the standard: security, data isolation, correctness, tests, deployment. Us · weekly
- Step 3 Report A dated report in a fixed format. Every finding with its severity, why it exists, what it risks, and how to fix it. Us · same day
- Step 4 Clarify Questions on the report are raised and closed, so nobody starts remediation from a misreading. Both
- Step 5 Remediate The team fixes, in the order the report sets out. The next cycle verifies the fix against the code rather than the commit message. Client
- Step 6 Ratchet Anything that appeared twice becomes an enforced rule. This is the step that makes the arrangement get cheaper. Us
An audit finds it once. A guardrail stops it returning.
A guardrail is a standing rule created because a problem happened more than once. Phase I proved the two kinds are not equally effective.
Held one hundred percent of the time.
The code will not compile, the tests fail, the deployment is blocked, or the database refuses the write. A required test run before any merge; a constraint that makes a mismatched record impossible. Once it is in place there is nothing left to remember.
Held until the week got busy.
Written guidance placed where the work happens, so it reaches the agent and the person automatically. Better than nothing, and materially better than a wiki nobody opens — but it degrades exactly when pressure rises, which is when you need it most.
The part of the work that leaves nothing behind.
The audit, the guardrails and the guidance in the codebase are all artefacts — they exist as documents and every claim here traces to one. There is a fourth mechanism, and it produces no record at all.
Throughout the engagement we were reachable while they were building — on calls and in working sessions — for the specific implementations where a wrong first attempt is expensive to undo.
An audit cannot answer these, because an audit arrives afterwards. They are the moments where a domain expert with a coding agent can produce something that runs and has no way to judge whether the design underneath it is the safe one. The agent will offer several approaches with equal confidence; choosing between them is experience, not instruction.
It is the point at which a non-technical builder is genuinely on their own — and the cheapest place in the whole arrangement to spend an hour.
The fix lands where it was found. The next surface never gets it.
Across three cycles one pattern appeared often enough to be called a law rather than a lapse. A problem is found and properly fixed. Then a new surface is built — a new user type, a second portal, another importer — and the same problem is there, untouched. In the third cycle, eight of the twelve new findings were exactly this.
The fixes got dramatically better. The discipline of applying a fix to every surface it belongs on did not — because that discipline was enforced by memory. This is how agent-assisted development fails: not randomly, but predictably, on whatever was built last.
Two reviews, five days apart, both correct.
The weekly audit asks whether the code is safe, isolated and tested. It does not ask whether the feature does what its screen says it does.
Medium-to-low riskZero high-severity findings — the strongest result of the engagement.
48 findings, 16 blockersA drawing upload that confirms success on screen and never sends the file anywhere.
Both are true because they measure different things. Finding that out five days apart is the most useful thing the phase produced — it changed what we review, not just how often.
“An application” turned out to be an estate.
One platform serving four kinds of user, two standalone applications, and two more still being scoped. Sizing the estate honestly is the first piece of work, every time.
Guardrails went in eleven days before the first audit.
Five roles, and one of them is the constraint.
Roles rather than names, because the arrangement is what transfers. Two sit with us; three sit with the client.
The remediation role is the throughput constraint on the whole loop — findings are raised faster than one person can close them. Naming that early is more useful than discovering it in month three.
Four applications went from ungoverned to governed.
Every claim below was verified by re-reading the fixing code, not accepted from a commit message.
The work is not finished.
Roughly eighty findings remain open across three applications, and the functional gap the late review exposed is being worked through rather than closed. Phase I is a floor, not a finish line.
They still build. We never took it over.
The domain knowledge never left the building, the team kept shipping at its own pace, and what changed is that somebody can now say with evidence whether the result is safe to run a business on.
You build. You buy assurance, not output.
Phase I was a delivery engagement. It was also, without setting out to be, a working prototype of an operating model for any business with deep domain knowledge and no appetite for an engineering department.