Ideas are not the constraint.
Product engineering for the AI era — new builds, modernisation of systems that still earn money, and the platform work underneath that decides how fast anything can change.
We build the whole stack, and we run it afterwards.
Bring the change that is currently taking too long. That tells us more than an architecture diagram.
This is for you if
If none of these are true we are probably not the right call yet, and we will say so.
- A product exists, and every change to it is getting slower
- The team owns the screens but not the platform underneath
- A rewrite has been proposed and nobody can size the risk
- Delivery is the constraint, not the ideas
What an engineering owner is judged on.
How long it takes to get a decided change in front of users. It is the honest measure of engineering health, and the one that quietly decays until a rewrite looks like the only option.
Whether shipping on a Thursday afternoon is routine or an event. Test coverage, environments and observability are what move it, not process.
What the platform costs to run and to change a year after launch — including the parts nobody budgeted for, like the on-call rota and the data pipeline nobody owns.
Before you sign anything
Ask the harder questions.
The four questions engineering owners ask once the capability list is out of the way.
Most rewrites are the expensive answer.
A full rewrite is proposed because the system is hard to change, but that is usually a boundary problem rather than a language problem. We size both routes against your actual change-failure points and say which one we would fund — including when the answer is to leave it alone.
- Change-failure points measured, not guessed
- Strangler-pattern migration where it fits
- Rewrite costed against modernisation honestly
- Risk of each route stated up front
- No rewrite recommended to create work
- Existing behaviour captured before anything moves
Faster, without the review debt.
AI-assisted delivery is how we cover more ground with a small team, but generated code that nobody understands is a liability with a delayed invoice. Everything shipped is reviewed by the engineer who owns it, and the tests are written to fail.
- Every change human-reviewed before merge
- Tests written to fail, not to pass
- Generated code held to the same bar
- Architecture decisions stay with people
- Throughput gains measured, not asserted
- No black boxes handed over
Built to be run by your team.
The work is done when your engineers can change it without us. That means the runbook, the alerting and the deployment path are part of the build rather than a document written at the end.
- Runbooks and alerting built alongside
- Your CI, your cloud account, your keys
- Handover rehearsed before it happens
- We can operate it, but you are not locked in
- On-call arrangements explicit in the contract
- Exit does not require our involvement
Priced against a scope you can hold us to.
Fixed-price where the scope is genuinely knowable, retainer where it is not. What does not happen is a fixed price quoted against a vague scope and then recovered through change requests.
- Fixed-price on knowable scope
- Monthly retainer for evolving work
- Change requests raised before work starts
- Estimates carry their assumptions
- Burn reported against plan monthly
- Exit terms settled before work starts, not after
Most rewrites are the expensive answer.
A full rewrite is proposed because the system is hard to change, but that is usually a boundary problem rather than a language problem. We size both routes against your actual change-failure points and say which one we would fund — including when the answer is to leave it alone.
- Change-failure points measured, not guessed
- Strangler-pattern migration where it fits
- Rewrite costed against modernisation honestly
- Risk of each route stated up front
- No rewrite recommended to create work
- Existing behaviour captured before anything moves
Six capabilities across the stack
Nought to one, with architecture chosen for where the product is going rather than the demo it starts as.
Incremental strangulation of systems that still earn money — no big-bang rewrite, no feature freeze.
AI in the delivery process itself: code, tests, migration and review — used where it measurably helps.
Native and cross-platform experiences, including voice, vision and document input as first-class.
Lakehouses, pipelines and API contracts other teams can build against without asking permission.
CI/CD, observability, SRE practice and on-call — the layer that decides whether any of it survives.
Nobody survives a big-bang rewrite.
The rewrite is always proposed first, and it is always the highest-risk option on the table: a feature freeze, a switchover date, and a year where the business gets nothing.
- 01Route by route
The legacy system keeps serving traffic while individual routes move behind a facade. Every step is independently reversible.
- 02Data last, not first
The database is migrated after the behaviour is proven, because a data migration is the step you cannot roll back on a Friday.
- 03Ship during, not after
Feature work continues throughout. A modernisation that requires a feature freeze will be cancelled halfway through, and then you have two systems.
- 04Delete the old path
The legacy route is removed as soon as the new one carries traffic — otherwise you have added a system rather than replaced one.
Let's talk about the change that is taking too long.
One workflow, one release, and what stands between deciding and shipping. That diagnoses the platform faster than any audit.
Digital products & platforms — common questions
Both, and modernisation is the more common engagement. The approach is incremental — strangling the legacy system route by route while it keeps serving traffic — rather than a parallel rewrite with a switchover date. Big-bang rewrites of systems that still earn money are the highest-risk option available, and usually the one proposed first.
AI applied to the engineering process itself — code generation and review, test authoring, migration work and documentation — where it measurably shortens the loop. It is used as a delivery tool rather than a talking point, and it does not change who is accountable for the result.
Yes, and we prefer to. CI/CD, observability, SRE practice and on-call response are part of the engagement rather than a handover document, because the run layer is where a product's real cost of ownership is set.
Embedded rather than adjacent. Our engineers work in your repositories, your ceremonies and your review process, and the intent is that your team can carry the system afterwards — which means the knowledge transfer is continuous rather than an event at the end.