Case 03 · Vertical B2B softwareResults delivered
Modelled · estimates, not banked savings
| Client | A PE-backed vertical B2B software group, scaling from 35 to 300 people through acquisitions and a merger. Anonymised for confidentiality. |
| Engagement | Successive executive mandates across engineering, people and product, engaged on a contract basis. Four years. Completed June 2026. |
| Team | Led by Colin Whitfield, with the client’s own engineers. Every senior hire went onto the client’s books. |
The problem
The group had grown by acquisition faster than its operating model. Hosting ran on legacy servers at around $50,000 a month. Roughly two hours a day went to meetings, across 28 people. Client pressure reached the roadmap directly, and scope moved with it.
The flagship had been rebuilt three times. Each attempt stalled. Around €264,000 had been sunk, and a key account was heading for a $500,000 contractual penalty.
The engineers were not the problem. Nobody held the decisions a rebuild needs.
The approach
Mandate first, then people, then process, then systems. The order took four years, across three mandates.
What changed
Engineering centre repositioned. The offshore office moved from low-cost capacity to the group’s engineering reference centre. Its lead engineers went on to review other teams’ architecture.
Standards owned by engineers. A development framework, coding standards and a component library, each sponsored through governance and owned by an engineer he developed. All three were adopted group-wide.
Meetings replaced by written governance. Two structured meetings a week in place of two hours a day.
Scope held at the boundary. One prioritised roadmap, taken through executive approval. Client requests were weighed against it, not added to it.
Hosting moved to event-driven cloud. The new product was built on it from the start.
AI governed before it was scaled. Full traceability and dual sign-off on every AI-assisted change.
Two builds, one organisation
In the same period, another team in the group rebuilt a different product’s interface over its existing backend. The two teams were of comparable size and used the same AI tooling, and both builds shipped on time. An architectural review of both codebases afterwards is the closest thing to a controlled comparison this work produces.
| Dimension | Build A: new interface over the legacy backend | Build B: greenfield, backend built alongside |
|---|---|---|
| API contract | Hand-written validation, no formal schema. Every endpoint modelled by hand | Clients generated from a formal OpenAPI schema. Near-zero cost per endpoint |
| Type discipline | Permissive rules | Strict typing, generated types throughout |
| Data | Fetched from the browser through a proxy, two hops per request | Prefetched on the server, hydrated to the client |
| Authentication | Custom middleware | Established third-party provider |
| Automated tests | 3 test files | 15 unit test files, plus 24 end-to-end specs across records, contributors, security and admin |
| Shared code | Standalone repository | Monorepo, with generated clients shared across 10+ services |
| Backend | Unchanged legacy | Co-evolved, event-driven, multi-tenant |
The discipline is the product; the tooling is downstream of it.
The outcome
The modernised platform released at month 18. Client migrations ran through month 24. The senior team stayed throughout. The account heading for a penalty stayed. A major customer’s long-running loss of confidence turned into a confirmed migration decision. That customer was later acquired and the programme stalled, so the claim is the recovery, not the revenue after it.
The engagement ended in June 2026. The framework, the component library and the engineering centre stayed with the people who owned them.
In retrospect
One change did not survive the move to the product mandate. Standardised user stories, introduced across four teams, were dropped when the previous team was reinstated. The changes that lasted were the ones handed to a named owner. The ones held centrally did not. Every change we install now has an owner other than us from day one.
About the figures. Realised: a cash or contractual outcome, verifiable against records. Operational: a measured system metric on a comparable workload, not traced to P&L; the release cadence and hosting figures are operational, and the 6× is measured against the sector norm. Modelled: calculated from headcount, hours and rates against a stated baseline. It is an estimate, not a banked saving. Classes are never summed. The architectural comparison is drawn from an internal review of both codebases. Client names sit under NDA; references are available on request.
These results come from specific past engagements, verified against records, and depended on each company’s circumstances. They are not a prediction or guarantee of results for any other company. Full terms.