Your team builds it.
We make it safe to run a business on.
Your people know your business better than any software vendor ever will. With AI coding agents they can now build the systems themselves — fast. What they cannot do is tell whether what they built will leak a customer’s data, survive a bad day, or quietly stop doing what the screen says it does. That is the part we own. And where a function would rather not build for itself, we build that system too — to the same standard, in your repositories.
The whole thing, in one picture
Every change to your software runs this loop. The rest of this page is the detail.You decide what gets built, and who builds it. Per system, not per company — and you can change your mind.
Anything that goes wrong twice becomes a check the computer enforces. A failing build, a blocked merge, a database that refuses. It cannot come back a third time — which is why each cycle costs less than the last, and why the review eventually runs out of things to find.
What you are left holding. The rulebook, the enforced checks, the pipeline, the documentation and the decision history — all of it in your repositories and your cloud accounts. It keeps working whether or not we are still engaged.
The shift you are already living through
Something changed in the last two years. The person who understands how your business actually works — how a quotation gets priced, how a claim gets assessed, how stock moves between your sites — can now build the software for it directly. No specification document. No developer to translate through. No six-month queue.
Most SMEs discover this by accident. Someone builds a tool over a weekend, it works, more people use it, and within a year it is running something that matters. It is genuinely good software in the ways that count: it fits the business exactly, because the person who built it lives in the business.
And then a question arrives that nobody in the building can answer. Is it safe?
There is a gap between software that runs and software you can bet a business on. From the outside those look identical — right up until the day they don’t.
The gap is invisible by design. Screens load. People log in. Work gets done. What is not visible is the set of questions nobody in the building can answer:
Traditionally you closed that gap by hiring engineers, or by handing the whole thing to a software company. We think there is now a third option that fits an SME better than either.
Buy the software
- You describe what you need. A vendor builds it. Your domain knowledge is transferred to them, imperfectly, over months.
- Cost scales with scope — every feature is a line item and every change is a change request.
- When the engagement ends, the capability leaves with them.
- Characteristic failure: they build the wrong thing, correctly.
Govern the building
- Your people build, with agents. The domain knowledge never leaves your building because it was never translated out of it.
- Cost scales with risk and estate size, not with how many features you want. Features are close to free.
- The capability stays and compounds. Your team gets better every cycle.
- Characteristic failure: they build the right thing, incorrectly. That is the cheaper mistake, and it is the one we are built to catch.
And where you would rather not build something yourself, we build it. Not every function of a business wants to, and some systems are not worth learning on. The difference from the left-hand column is not who types — it is that the standards, the repositories, the pipeline and the knowledge stay yours either way, and the thing we hand over arrives already governed rather than needing to be governed later. You choose per system, and you can change your mind. How that works →
Is this you?
We would rather lose a deal than take a bad-fit one. Read both columns honestly — the right-hand one matters more.
This works well when
- Your people build, or you want them to. At least one person on your side is producing working software with AI agents, or is about to. Where a particular function never will, we build that system for you — but if nobody anywhere in the business is going to build, you want a software vendor rather than this.
- The domain is the hard part. Workflow, records, quotations, scheduling, calculations, reporting, compliance. Complicated because your business is, not because the technology is exotic.
- Something already exists and nobody knows how sound it is. The most common reason people call us.
- You have no engineering function and do not want one. Hiring a competent technical lead is expensive, slow, and a single point of failure when they leave.
- You can name one person to be our interface. They do not need to be technical. They do need authority.
This is the wrong fit when
- The technology itself is the difficulty. Very high scale, real-time systems, machine learning, novel infrastructure. Buy engineers. We will say so.
- Nobody in the business has the domain depth. The model’s entire advantage is that your people know something a vendor would take months to learn. No depth, no advantage — and you are better served by a conventional software company.
- It is a one-off build with no ongoing change. Governance is for things that keep changing. A static system wants a vendor and a warranty.
- A regulator requires an accountable third-party builder. Some sectors do. We are not that.
- Nobody can absorb the findings. If you take governance without the capacity to act on it, you buy a very well-written list of problems. Take a package that includes remediation, or do not start.
The last one is the real disqualifier. We have seen it up close. An audit that produces findings faster than an organisation can fix them stops being governance and becomes an expensive source of anxiety. Before we quote, we will ask who fixes things and how many hours a week they genuinely have. If the answer is thin, we will steer you to a package that includes our hands.
What we cover
Eleven dimensions. For each: what we actually examine, what lands as a result, and which package includes it. This table is the scope of work — if something is not on it, assume it is not included and ask.
Sign-in and session handling, password and token storage, what happens when someone is removed, permission checks on every protected action, abuse and brute-force resistance, secrets handling.
Whether one customer, site, branch or tenant can reach another's records — in the code and, critically, at the database level as a backstop. Every scoped query, every shared table.
What happens when two people save at once, when a process fails halfway, when a number is computed in the application rather than enforced by the database. Concurrency, transactions, constraints.
Structure, duplication, file size, dead code, error handling, whether the next person — or the next agent session — can safely change it.
Whether tests exist on the code that matters, whether they actually run before a change merges, and whether that gate is genuinely mandatory rather than advisory.
How code reaches production, what credentials that path holds, whether an untrusted input can hijack it, whether dependencies are pinned and scanned.
Whether each business concept has one authoritative record, whether the data model will hold as modules multiply, where the system will bend under growth. In Govern and Sustain this is observation only — architecture cannot be audited into existence, only out of, expensively.
Whether a shipped feature actually performs what its screen claims — that an upload stores a file, a save persists, a record raised in one place appears in the other place it is promised to appear. This is a distinct discipline from everything above.
Whether formulas, constants, rates and statutory logic match the standard they claim to. We do not certify this ourselves — we require you to name a qualified expert, and we make their sign-off a versioned, re-checked gate.
Environments, deployment, secrets, access control, monitoring, backup and a tested restore. Ownership of the running estate, not just review of it.
What personal data you hold, who can reach it, what is logged, retention, and an access-control policy that matches the obligations you actually carry.
One thing this table cannot show. Every row above describes something we examine after it is built. Running alongside all of them is a named engineer your builders can call before they build — on payments, authentication, permissions and sensitive data. It is included in all three packages and set out under how it works, but it is not a dimension of review, so it has no column here.
What is explicitly out of scope
Stated plainly, because the fastest way to sour an engagement is a month-three surprise.
We do not
- Decide what gets built. What to build, for whom, in what order, stays entirely with you. We will build a system for you where you ask us to — see who builds each system — but the product decisions are never ours.
- Build anything that has not been scoped and quoted. Governance and build are separate lines. A finding is remediation; a new module is a project with its own scope and price.
- Certify your domain calculations. We require a named expert and enforce their sign-off. We are not that expert.
- Provide a penetration test or a security certification. Different discipline, different accreditation. We will tell you when you need one.
- Give legal or regulatory advice. We will map what you hold and who can reach it. Your counsel interprets the obligation.
- Review systems we cannot see. Third-party products and closed vendor systems are outside the boundary; we assess the integration, not their internals.
- Load-test or performance-tune beyond what a code review surfaces, unless scoped separately.
- Act as a helpdesk. Our engineer is reachable for design decisions that are expensive to get wrong — not for day-to-day development support, and not to write your features on a call.
How it works
Three mechanisms, in the order they act. Standards that reach the work before it is written. A named engineer for the decisions that are expensive to get wrong. And a review cycle that checks, on a fixed rhythm, whether it all held.
Mechanism one — the standards reach the agent, not the meeting
The usual way to raise engineering quality is code review, mentoring and habit. None of those are available here: the person building may have no engineering background, and the thing writing the code is an agent that starts every session knowing nothing.
So we deliver the rules as files the agent reads. Guidance placed inside the risky parts of your codebase, which loads automatically whenever an agent works there — so the rule arrives even when the person prompting does not know the rule exists. A durable memory file per repository recording what was decided, what nearly went wrong, and what must never be undone; read at the start of every session and appended at the end. And a rulebook of standing guardrails, each declaring how it is enforced.
This is the part that does the work. Everything else is inspection.
What we learned, and why it shapes everything: guardrails enforced by the computer — a failing build, a blocked merge, a database constraint — held every single time across our design partner’s engagement. Guardrails that depended on someone remembering held on the surface they were written for and leaked on the next one, every time. So our standing rule is simple: when the same problem appears twice, we do not write another reminder. We build one shared piece of code and one automated check.
Mechanism two — the call before the code
Some implementations are not a matter of writing code correctly. They are a matter of knowing which of several plausible designs is the safe one — and an agent will offer all of them with equal confidence, in the same tone, at the same speed.
Taking a card payment. Issuing a login session, and knowing what has to end when it ends. Deciding what may be written to a log and what must never reach one. Moving personal data from one part of the system to another. From where your builder sits, none of these look different from ordinary work. That is precisely what makes them the expensive ones to get wrong, and they are wrong before anyone reviews anything.
So we name an engineer your team can reach before they write it, rather than after we review it. In our design-partner engagement this ran throughout: payment gateway integration, authentication and session handling, and the handling of sensitive data were settled on calls, ahead of the build — alongside working sessions whenever something stopped the team outright, like a deployment path that would not behave.
This is the cheapest thing we do, and the reason is timing. A decision taken on a call costs a conversation. The same decision reached one cycle later costs a finding, a fix, a re-review and a scorecard entry — and if it touched money, credentials or personal data, possibly a live exposure in the days between. Everything else in this offering corrects. This is the one part that prevents.
What it is, and what it is not. Included in every package, bounded by package: in Govern, consultations are scheduled against the review cycle; in Sustain and Anchor, your builders raise them on demand and we respond within one working day. We advise on the approach — your team writes the code and owns the decision, which is the whole point of the model. It is not a helpdesk, not general development support, and not a route to have us build your features. If a request is really “please build this”, we will say so and quote it.
Mechanism three — the review cycle
You build
Your team ships at their own pace, on their own priorities. We do not gate the work — we gate the quality.
We review
Everything built since the last cycle, examined in parallel by multiple specialist reviewers each looking through a single lens, with every serious finding verified against the source.
You get a report
Dated, standard format. Every finding with its severity, why it exists, what it risks, and how to fix it — in language your interface can act on.
It gets fixed
By your team, ours, or both — depending on package. Nothing is marked closed until the next cycle re-reads the actual fixing code.
It cannot recur
Anything that has now appeared twice becomes an enforced check. This is what makes the engagement get cheaper instead of running forever.
Built for your people and the agents they use.
The gate does not slow the building down — it decides what is allowed to merge, and it says so in language the person who wrote the change can act on. Every rule in it started as a real finding on a real repository.
See the guardrail listOn cadence. We start close — weekly or fortnightly — and the interval widens as your numbers improve. That is not a judgement call we make in private: it follows two measures you can see. How many of your guardrails are enforced by the computer rather than written down, and how many findings arise per unit of new work, cycle over cycle. When those clear the bar, the cadence relaxes and your cost falls.
Three ways to buy it
The variable is how much of the work sits on your side. Everything else is common — the same standards, the same review, the same rulebook.
Govern
For a business that already has someone capable of acting on findings, and needs standards plus an independent check rather than hands.
- Guardrail rulebook, installed and owned
- The context system in your repositories
- Review on a fixed cadence
- Remediation scorecard each cycle
- Design consultations, scheduled against the cycle
- Maturity measurement
- You fix everything yourself
- You run your own infrastructure
Be honest with yourselfOnly works if someone on your side genuinely has hours to fix things. Most SMEs believe they do.
Govern & Sustain
For a business with strong functional builders and no engineering function. This is the shape our design partner runs, and the profile most SMEs actually have.
- Everything in Govern
- We fix findings above an agreed severity
- We own the platform — environments, deployment, secrets, backup and tested restore
- Design consultations on demand, answered within a working day
- Functional spot-checks on major surfaces
- Enablement — your team’s own output improves cycle over cycle
- Architecture corrected after the fact, not designed up front
Leaves openStructural decisions get corrected at retrofit cost. Fine for conventional domains, expensive for complex ones.
Anchor & Govern
For a business where the software carries real exposure — customer money, regulated data, statutory calculations, or output that affects safety.
- Everything in Sustain
- Design consultations on demand, plus the structural calls taken jointly up front
- We design the structural spine first — identity, data model, tenancy, money handling, integration boundaries
- Full functional assurance on every major surface
- Domain sign-off enforced as a versioned gate
- Privacy and access-control position documented
Trade-offHighest cost and slowest to start, because the foundation is laid before your team builds on it. Cheapest over three years.
Who builds each system — a choice you make per system, not per company
The packages above assume your people build. For most of your estate that is the right answer, and it is where this model earns its advantage. But it is rarely the right answer for everything. The function with a keen domain expert who enjoys building is not the same function as payroll, or statutory reporting, or the module nobody in the business wants to own.
So the choice is made system by system. The standard does not change with it — the same guardrails, the same rulebook, the same context system, the same repositories and pipelines, all of them yours either way.
Your team builds
- The default, and the reason this model is cheaper than an engineering department.
- We govern it: standards in the codebase, the escalation call, the review cycle, the scorecard.
- Best where the domain is the difficult part and someone in that function actually wants to build.
We build it
- A scoped, fixed-fee module, delivered into your repositories and your accounts under the same guardrails your team works to.
- You get the audit report on our own work at handover, at no charge — the same dated format, severity and root-cause standard as every other cycle.
- Best where nobody in that function will realistically build, or the exposure is high enough that you want it built right the first time.
Both, on one system
- We lay the structural spine — identity, data model, money handling — and your team builds the functional surface on top of it.
- The most common shape for a system that matters, and the cheapest way to avoid a retrofit later.
- Best where the structure is unforgiving but the day-to-day workflow changes constantly.
You never pay us to audit our own work. The governance retainer covers what your team builds — that is where an independent check has value and where the volume actually varies. Anything we build passes through the identical review before it is handed over, reviewed by someone other than the person who built it, and you receive that report unedited as part of the delivery. If you would prefer a third party to review our work instead, say so and we will support it rather than argue.
What happens at handover. Once a system we built is delivered, it joins your governed estate and is reviewed on the normal cycle like everything else — including the changes your team makes to it afterwards. For a warranty window agreed up front, defects in what we built are fixed by us at no cost, rather than consuming the remediation capacity you are paying for. After that window it is ordinary remediation, priced like anything else.
If nothing is built yet, start at C and step down to B. Structural decisions cost almost nothing before the first line of code and a great deal after the thousandth. Once the spine is set, your team builds on top of it and the engagement steps down.
Who does what
Most engagements of this kind fail at the boundary rather than in the work. So here is the boundary.
What you bring
- People who build. At least one, genuinely producing. This is the engine; we are the governor.
- One named interface. A single person who owns the relationship — intake, clarifying findings, accepting work, coordinating releases. They do not need to be technical. They do need the authority to say no.
- Repository and environment access for the systems in scope.
- Acceptance of the gate. Once enforcement is on, a failing check blocks a merge. That is the point. If it can be waved through, it is not a guardrail.
- A domain expert where formulas or statutory logic are involved — named, and available to sign off.
- Decisions. Deferring a finding is a legitimate choice. It needs an owner and a date, not silence.
What we bring
- The standards, installed in your codebases and readable by your agents, with an owner named in each.
- The review, on the agreed cadence, in a consistent format, with every serious finding verified against your actual source.
- The scorecard. Every previous finding re-graded against the fixing code — never against a commit message.
- The ratchet. Converting recurring problems into enforced checks so they cannot come back.
- A named engineer to call before your team builds anything where the first attempt is expensive to undo — payments, authentication, permissions, sensitive data — and when something has stopped them outright.
- Hands, in Sustain and Anchor — remediation, platform, and structural work.
- Whole systems built to the same standard, where a function would rather not build for itself — scoped and quoted separately, delivered into your repositories, and audited by us before handover with the report given to you unbilled.
- Honesty about the limits. If something falls outside what we cover, we say so in the report rather than leaving you to assume it was checked.
The first 90 days
What actually happens, and what lands on your side of the table.
Baseline
We read everything and tell you where you stand — risks ranked by consequence, with the root cause and fix for each.
You get: a baseline report and a triaged backlogFoundations
The rulebook goes into your repositories. The context system is installed. The first enforced checks go live. Severe findings start closing.
You get: standards in place, a working gateRhythm
The cycle runs properly. Your interface settles into the intake-and-acceptance routine. The platform work lands if it is in scope.
You get: a cycle that runs without us chasingEvidence
Second and third cycles show the trend. We report your maturity position and what it would take to widen the interval.
You get: numbers, not opinionsWhat you physically receive
Everything we build lives in your repositories and your accounts. The rulebook, the checks, the pipeline, the documentation. If you stop working with us, all of it keeps working. That is deliberate — an engagement you cannot leave is not a service, it is a dependency.
Where this comes from
We did not design this in a workshop. It comes from a live engagement with a construction SME whose functional team — three to five people, none of them engineers — had built a substantial platform using coding agents. They became our design partner, and Phase I ran from late June to the end of July 2026.
Four applications across five repositories went from ungoverned to governed. Here is what that produced.
The number that actually matters
Finding and fixing problems is what any competent review does. The interesting result was different.
In the first cycle, a brand-new feature shipped with a critical severity defect inside it. By the third cycle, the brand-new features shipped with nothing above medium, correct data isolation throughout, and clean financial calculations. The team’s unassisted output improved measurably in six weeks, because the standards had moved into the place where the work happens.
An engineer’s cost is flat for as long as they are there. This gets cheaper, because the floor of what your team produces keeps rising.
What we also learned, and will tell you before you ask. Five days after grading that platform at its best-ever result, a different kind of review — asking not “is this safe” but “does this feature actually do what its screen claims” — found sixteen release blockers in one module. Both assessments were correct; they measured different things. That is why functional correctness is now a named dimension in the coverage table above rather than something we quietly assume. A system can pass every security and quality check and still not work, and any provider who does not tell you that is not being straight with you.
Commercial shape
How the pricing is structured. Figures are set per engagement after the baseline, because they depend on estate size and risk rather than on ambition.
Two commitments on the commercials. Your cloud, tooling and third-party costs stay in accounts you own and control — we never resell infrastructure. And as your maturity improves the cadence widens, which means the retainer is designed to fall over time. If it is not falling by year two, either the model is not working for you or we are not doing our job, and both are worth a conversation.
Questions we get asked
Our team isn't technical. How can they possibly build production software?
They already are — that is usually why the conversation starts. The agent handles the coding. Your person handles knowing what the software should do, which is the part that cannot be outsourced without loss.
What they cannot do is judge whether the result is safe, and they usually cannot tell the difference between working and appearing to work. That gap is real, and it is the entire reason this offering exists. We are not claiming your team does not need help. We are claiming the help they need is governance, not a replacement.
Isn’t this just outsourced code review with extra steps?
Code review finds problems. This is designed to stop them recurring, which is a different thing.
Every problem that appears twice becomes an enforced check — a failing build, a blocked merge, a database constraint — so the class of problem cannot come back. A review that finds the same issue every month has failed even though it is doing its job. Ours is designed to run out of things to find, and we track whether it is.
The other difference is that a reviewer arrives after the fact. We also give your builders a named engineer to call before they write the payment integration or the login flow. No code-review arrangement offers that, and it is the cheapest thing in the engagement — the same decision made a week later is a finding, a fix and a re-review.
Some of our functions will never build for themselves. Can you just build those?
Yes, and we would expect that on most estates. The choice is made per system rather than per company — the function with an enthusiastic domain expert is not the same function as payroll or statutory reporting, and pretending otherwise produces a system nobody maintains.
What does not change is the standard. We build into your repositories and your cloud accounts, against the same guardrails your own team works to, and the system arrives already governed rather than needing to be governed afterwards. It is scoped and quoted as a project, separately from the governance retainer.
If you build it, who checks it? Are you not marking your own homework?
A fair question, and the answer is structural rather than a promise.
Anything we build goes through the identical review before handover — same harness, same severity taxonomy, run by someone other than the person who built it — and you receive that report unedited, at no charge. The governance retainer covers what your team builds, because that is where an independent check has real value and where the volume actually varies. You never pay us to audit ourselves.
After handover the system joins your governed estate and is reviewed on the normal cycle like everything else. And if you would rather commission a third party to review our work, we will support that rather than argue with it.
How is this different from hiring a technical lead?
A good one is excellent and we would not talk you out of it. But they are expensive, slow to find, take months to learn your domain, and when they leave the knowledge goes with them. For most SMEs they are also a single point of failure who has no peer to check their work.
This gives you a team of reviewers rather than one person, standards written down rather than held in someone’s head, and a cost that falls as your maturity rises. If you can afford both, have both — the two combine well and this makes a lead more effective rather than redundant.
We already work with a software company. Does this replace them?
Not necessarily, and often not at all. If they are building something genuinely difficult, keep them. This is for the growing pile of internal tools your own people are building alongside that — which is usually where the ungoverned risk actually sits.
We can also review work delivered by a third party, though we would want that arrangement to be open rather than adversarial to be useful.
How do we know AI-written code is safe?
You do not, and neither does anyone else, which is the honest answer. What we can tell you is that it fails in predictable ways, and that is a useful property.
Agents leak rules onto whatever was built most recently — a fix applied where it was found and not carried to the next surface. They also produce a convincing interface much faster than the substance beneath it, so a screen can confirm an action that never happened. Both patterns are consistent enough to build specific checks against, and we have.
What happens when we stop working with you?
Everything we build sits in your repositories and your cloud accounts: the rulebook, the enforced checks, the pipeline, the documentation, the decision memory. It keeps working.
What you lose is the independent review and, depending on package, our hands. That is a real loss — but it is a service you chose to stop, not a system that stops with us. We would rather you leave because you no longer need us. That is the intended end state.
How long before we don’t need you?
We will not pretend to a date. What we will do is show you the two numbers that determine it — how many guardrails the computer enforces rather than a person remembering, and how many findings arise per unit of new work — and report them every cycle.
When those clear the bar, the cadence widens and the cost falls. Our design partner moved from a critical-severity finding in new work to nothing above medium in six weeks. That is the shape of the curve, though every estate is different.
Will this slow our team down?
In the first few weeks, slightly — the gate starts blocking things that used to sail through, and that is uncomfortable by design.
After that it usually speeds them up. Most of what slows a small team is rework: something broke, nobody knows why, and a day disappears. Enforced checks catch that at the point of writing rather than the point of discovery. And crucially, we never gate what your team builds or in what order — only whether it meets the standard.
What if we don’t like what the review finds?
You will not, at first. A first baseline on an ungoverned codebase is uncomfortable reading, and ours are deliberately direct.
Two things make that bearable. Every finding carries a root cause and a specific fix, so it is a work list rather than a verdict. And the report is explicit that this is about the code and not the coder — the people who built it did something valuable, and finding the gaps is what the exercise is for.
Can you tell us who your design partner is?
The engagement described here is with a construction SME in our own group, which is why we can describe it in this much detail — including the parts that went wrong.
We will introduce you to them by arrangement if a direct conversation would help you decide. What we will not do is share their audit reports, since those contain a live picture of their security posture. We would extend you exactly the same protection.
Start with the baseline
Before any commitment, we read what you have and tell you where you stand. It is a fixed fee, self-contained, and yours to keep whatever you decide next. Most of the difficult decisions get easier once the picture is on paper — including the decision not to work with us.
- What has been built, and roughly how much
- Who builds it, and who could fix things
- Whether it handles money, personal data or regulated output
- Where it runs today
Governed self-build for AI-first SMEs. Figures cited are from a completed Phase I design-partner engagement, June–July 2026, and are verifiable on request under a mutual confidentiality arrangement. Coverage marked ◐ is observed and reported but not owned; coverage marked ○ is available as a separately scoped add-on. Nothing on this page constitutes a security certification, a penetration test, or legal or regulatory advice.