Urgency does not create understanding
Modernisation usually begins with a real trigger:
- a platform is losing support;
- a vendor has raised prices or is leaving the market;
- regulation requires changes the system cannot absorb;
- operation has become too fragile or expensive;
- essential knowledge is leaving with key people;
- product change is too slow for the business;
- a previous replacement has failed.
AI can survey source material and generate a new implementation quickly. It cannot decide what should survive. Recovery of intent is the scarce work.
Recover the product, not just the code
The operating truth is usually distributed across source code, documentation, tests, data, interfaces, runtime behaviour and the people who use and support the system.
We keep those sources distinct and connect claims back to their evidence. Where they disagree, the client’s accountable people decide the intended behaviour. Where the answer remains unknown, the risk stays visible.
The result is not perfect knowledge of an entire estate. It is a defensible boundary for the first useful change.
Improve the delivery system around it
A modern codebase still creates slow, risky outcomes if product direction and delivery remain disconnected, testing is mostly manual, infrastructure is handcrafted, deployment is infrequent and frightening, release cannot be controlled independently, or production gives little useful feedback.
Those are continuous-delivery gaps. We identify which of them must change for the first modernisation outcome, then establish the necessary foundations as part of delivering it — so the second wave is cheaper than the first.
How we modernise
1. Establish the outcome and baseline
Define why change matters, who depends on it and how success will be measured. Map the bounded system across repositories, running components, interfaces, state, environments, ownership, dependencies and critical journeys.
2. Decide what survives
Separate behaviour that must be preserved from behaviour that should change and architecture that should be left behind. Keep evidence, decisions, conflicts and unknowns reviewable.
3. Design operable transitions
Describe the target and the states needed to reach it, including coexistence, data movement, cutover, rollback and production controls.
4. Establish the path to production
Add the automated verification, infrastructure, pipelines, observability and release controls needed to deliver the first wave safely.
5. Deliver a bounded outcome
Use senior practitioners, coding agents and our spec-driven delivery engine to refine reviewed intent, implement the change and verify it against declared checks.
6. Release, learn and update the baseline
Put the outcome into operation under appropriate controls. Feed accepted behaviour, decisions, test evidence and operational learning into the next wave.
The role of the delivery engine
Our spec-driven delivery engine sits around AI coding, not in place of it.
For an existing system, the engine coordinates two connected loops: system archaeology establishes reviewed evidence, coverage and architecture; bounded delivery then carries reviewed plans and specifications through implementation and verification. This keeps the work anchored to durable change facts rather than allowing a coding agent’s conversational context to become authority.
The precise boundaries of what the delivery engine and our runtime do and do not do are stated plainly in how we deliver.
Land in a shape you can keep changing
The replacement runs on our WebAssembly runtime: application behaviour in sandboxed components, infrastructure in the host. Coding agents implement the reviewed business behaviour without redesigning the technology stack for each wave.
Reusable Terraform and GitHub Actions patterns provide the path to production. Supported backend substitutions later do not start as an application rewrite. Data movement, provider semantics and operational equivalence still require explicit planning and verification.
See how we deliver
What an accepted wave leaves behind
Depending on the boundary, a completed outcome includes:
- working software in production or ready for controlled release;
- reviewed specifications tied to available evidence;
- automated checks and their results;
- repeatable infrastructure and deployment assets;
- updated architecture and operational documentation;
- decisions, known gaps and deferred work;
- product and delivery measures;
- a stronger baseline for the next change.
You own the code, evidence, infrastructure, pipelines and deployment.
Price what can be responsibly bounded
The initial readiness work establishes whether the first outcome can be defined and what foundations it needs. Where the evidence supports a stable boundary, subsequent work can be priced around an accepted outcome rather than only around hours.
We do not manufacture certainty to offer a premature fixed price. Unknowns are either resolved, explicitly bounded or treated commercially as unknowns.
A responsible first move
Do not begin by asking how quickly AI can rewrite the system. Begin by deciding which business outcome matters, what behaviour it depends on and what must be true for the organisation to release it safely. The first wave should also be the start of a cheaper second wave.
See AI Delivery Readiness
See how each delivery improves the next