Delivery record · Six anonymised engagements
Six engagements, each described in the same five parts: the context, the constraint, what we decided, the trade-off it cost, and the measured outcome. The trade-off is not a disclaimer at the bottom. Every one of these decisions made something else worse, and that is the part most useful to you when you are weighing a similar decision.
Summary
Sector and geography only. Everything else — duration, team size, headline outcome — is as recorded in our own delivery data.
What is on this page
Six engagements across six markets: an Azure-to-AWS migration that cut monthly infrastructure spend by 39 percent, a legacy pricing system replacement validated by a fourteen-week parallel run, an LLM cost rescue that reduced inference spend by 72 percent, a data platform that ended a four percent reporting variance, peak-season capacity engineering that held a 38-day trading window, and a dedicated team that scaled an in-house product organisation from three engineers to fourteen.
| Client (anonymised) | Geography | Engagement type | Duration | Team size | Headline outcome |
|---|---|---|---|---|---|
| A commercial insurance broker | United Kingdom | Azure-to-AWS migration and platform rebuild | 14 months | 6 engineers | Monthly infrastructure spend down 39 percent; deployments from fortnightly to nine per week |
| An industrial equipment manufacturer | Europe | Legacy replacement with parallel run | 22 months | 9 engineers | 4,100 orders reconciled, 61 pricing discrepancies found, cutover with zero pricing incidents |
| A healthcare SaaS provider | United States | LLM cost rescue and model tiering | 5 months | 4 engineers | Inference spend from USD 71,000 to USD 19,600 per month in 11 weeks |
| A third-party logistics operator | Gulf region | Data platform and semantic layer | 12 months | 7 engineers | Reporting variance between operations and finance from 4.2 percent to under 0.3 percent |
| An online fashion retailer | Australia | Peak-season capacity engineering | 6 months | 5 engineers | 11,400 checkouts per hour at peak with zero unplanned downtime across 38 days |
| A multi-speciality clinic group | India | Dedicated team and engineering practice transfer | 19 months | Up to 8 engineers | In-house team from 3 to 14; change failure rate from 31 percent to 12 percent |
Team sizes are our people only and exclude client staff. Duration is from signed statement of work to formal engagement close, which in three of the six cases includes a support tail.
Engagements 01 and 02
Context. An eleven-year-old policy administration and quoting platform, .NET on Azure App Service with SQL Server, supporting around 140 internal staff and a broker network. No infrastructure as code, single region, deployments performed manually on alternate Friday evenings. Two in-house developers, both of whom had inherited the system rather than built it.
The constraint. An enterprise agreement renewal put the cloud bill in front of the board for the first time: roughly GBP 47,000 a month with no line-item ownership. The FCA-regulated business could not tolerate a quoting outage during working hours, and the two in-house developers could not be taken off support to help with a migration.
What we decided. A 7R assessment across 23 workloads. We replatformed the quoting engine and policy services onto ECS Fargate, moved the primary database to Aurora PostgreSQL with a schema translation phase, rebuilt everything in Terraform, and deliberately left two workloads on Azure — a document generation service with an undocumented COM dependency, and a reporting stack the finance team used daily. Migration ran in six waves, each rehearsed in a staging cutover before the production one.
The trade-off it cost. Nine months of genuine dual-cloud operation. Two clouds meant two sets of network controls, two identity models, duplicated monitoring and an overlap cost of roughly GBP 6,000 a month that bought nothing. It also delayed observability consolidation by two quarters, so for most of the programme the team was correlating incidents across two dashboards by hand. And we deferred the document generation rewrite entirely — it is still technical debt on that estate today, and we recommended deferring it knowing that.
Measured outcome. Monthly infrastructure spend fell from about GBP 47,000 to GBP 28,400 over seven months, a 39 percent reduction, measured from billing exports on both clouds. Deployment frequency went from fortnightly to nine per week. P95 quote latency fell from 2.4 seconds to 1.1 seconds. Change failure rate, which had never been measured, settled at 11 percent by month twelve. Zero unplanned quoting outages during working hours across the whole programme.
Engagement 01
Context. A fashion retailer whose Black Friday to Boxing Day window generates about 34 percent of annual revenue. A Rails monolith with a single PostgreSQL primary, hosted on AWS, scaled by increasing instance sizes. The two previous peak seasons had each produced a checkout outage measured in hours.
The constraint. Five months to peak. Re-architecting the monolith was the correct long-term answer and was completely impossible in the time available, which meant the engagement had to make an unchanged architecture survive roughly double the traffic.
What we decided. Capacity engineering rather than re-architecture. We load-tested at four times the prior peak, which surfaced three bottlenecks in a fortnight: database connection pool exhaustion, a synchronous transactional email call inside the checkout path, and an unindexed query on the search filter. We added read replicas for catalogue and search, moved email behind a queue, put aggressive edge caching on catalogue pages, pre-warmed a raised baseline for the six weeks around peak, and wrote a load-shedding plan that degraded personalisation and recommendations before it touched checkout.
The trade-off it cost. Three things, all agreed in advance and all real. The pre-warmed baseline cost about AUD 41,000 more across six weeks than reactive scaling would have — we bought certainty with money. Edge caching meant price and stock changes took up to five minutes to propagate, which merchandising disliked intensely and which caused two customer complaints about a price shown on a listing page. And the load-shedding plan actually fired: personalisation was off for roughly four hours during the highest traffic period, which cost some conversion we chose not to try to estimate. The underlying architecture was not improved at all. We bought them one season.
Measured outcome. Peak throughput of 11,400 checkouts per hour against 6,800 the previous year. Zero unplanned downtime across the 38-day trading window. P95 checkout latency from 3.1 seconds to 1.4 seconds. Revenue for the window was reported by the client as up 22 percent year on year, which is their figure rather than ours and reflects trading as well as engineering.
Engagement 02
Engagements 03 and 04
Context. A product configuration and order entry system written in the late 1990s, running on Delphi against Oracle, carrying roughly EUR 120 million of annual order flow and about thirty years of accumulated pricing and configuration rules. An attempt to replace it as part of an ERP programme had failed in 2021 and been written off.
The constraint. Nobody understood the pricing rules. The engineer who had written most of them retired in 2019 and the documentation described roughly a third of the behaviour. Any replacement that mispriced a configured order would be discovered by a customer, not by a test. The board had already funded one failure and would not fund a second.
What we decided. A strangler pattern behind a new ordering front end, extracting the rules incrementally, plus a fourteen-week parallel run in which both the legacy system and the replacement priced every single order and the differences were reconciled every day. We set the cutover gate before we started: thirty consecutive days with zero unexplained variance, no exceptions, with the client's finance director holding the decision rather than us.
The trade-off it cost. The parallel run added fourteen weeks to the programme and about 18 percent to its cost. It required two of the client's own staff on reconciliation duty at roughly half time for that period, which was work they had not budgeted for and did not enjoy. For five months the programme shipped no new capability at all, which was uncomfortable to defend at a board that had already lost money once on this system. We also chose not to migrate eleven discontinued product families, so those orders are still entered by hand in a spreadsheet and reconciled monthly.
Measured outcome. 4,100 orders priced by both systems. 61 discrepancies found, of which 52 were defects in our extraction and nine were long-standing bugs in the legacy system that had been mispricing certain configurations for years. Cutover completed with zero pricing incidents in the first ninety days. Average order entry time fell from about eleven minutes to four. The nine legacy bugs were the argument that justified the parallel run after the fact — they had been quietly costing money and nobody knew.
Engagement 03
Context. Three warehouse management systems acquired over a decade, a transport management system, a finance package, and three separate business intelligence tools. Every monthly operations review featured operations and finance presenting different shipment counts for the same month, and the meeting spent its first half hour arguing about which number was correct.
The constraint. The root cause was not technical. There were four working definitions of "delivered" in the business — driver-confirmed, scanned at destination, signed proof of delivery received, and invoiced — and each system implemented one of them. No pipeline could fix a disagreement about meaning. On top of that, month-end close was taking six weeks.
What we decided. Refuse to build anything for nine weeks. We ran definition workshops until 23 canonical metrics had a written definition and a single named business owner who could adjudicate disputes. Only then did we build: Debezium change data capture into object storage, Snowflake as the warehouse, dbt for transformation with tests on every canonical metric, and one semantic layer that every report had to consume. We also recommended deprecating two of the three BI tools.
The trade-off it cost. Nine weeks of senior stakeholder time before a single pipeline existed, during which the engagement looked to much of the business like it was producing nothing. That was politically expensive and we came close to losing the room twice. Deprecating two BI tools took away two departments' preferred tooling, retired one team's carefully built bespoke reports, and required five weeks of unplanned migration support we had not quoted. One of those teams was still unhappy at the end of the engagement, and we would not claim otherwise. The semantic layer also means a new metric now takes longer to add than it used to, because it has to be defined and owned before it can be built.
Measured outcome. Variance between operations and finance shipment counts fell from 4.2 percent to under 0.3 percent, with the residual explained and documented. Month-end close went from six weeks to nine days. Ad-hoc report requests to the data team fell about 60 percent, because the semantic layer let analysts answer their own questions. The metric definitions document is now used in the operations review itself.
Engagement 04
Engagements 05 and 06
Context. A clinical documentation assistant embedded in an existing product, used by around 900 clinicians. Every request went to a frontier-class model with a 6,800-token clinical context prefix. The feature had shipped quickly, worked well, and had never had a unit cost target.
The constraint. Inference was costing about USD 71,000 a month against roughly USD 214,000 of monthly recurring revenue attributable to the feature. The gross margin on the product's flagship capability was indefensible, and the board had given the team two quarters to fix it or withdraw it. Clinical output quality could not regress, because clinicians would simply stop using it.
What we decided. Model tiering driven by an intent classifier, with a small fast model handling the 78 percent of requests that were structurally simple and only genuinely ambiguous turns escalating to the frontier model. Prompt caching on the stable clinical context prefix. Response caching for repeated template sections. Retrieval restructured so the context window carried the relevant subset rather than the whole record. A sampled human review loop to detect quality drift before clinicians did.
The trade-off it cost. Escalated requests picked up roughly 240 milliseconds of additional median latency from the classification hop. More seriously, we introduced a measurable quality regression on three of nineteen evaluated task types, and it took a further six weeks of prompt and routing work to recover — six weeks during which some clinicians were getting a worse product than before we arrived. And we left behind routing complexity that the client's four-engineer team now has to understand and maintain. A single-model architecture is easier to reason about, and we made theirs harder.
Measured outcome. Monthly inference spend fell from about USD 71,000 to USD 19,600 within eleven weeks, a 72 percent reduction, measured from provider billing. Clinician-rated output acceptance moved from 87 percent to 85 percent during the regression, then to 89 percent after remediation. Cost per completed document is now a tracked metric with an alert threshold, which it was not before.
Engagement 05
Context. A group of nine clinics with an in-house software team of three, building a patient-facing application and internal operations tooling. The founder, who had a technical background, was acting as product owner, engineering manager and recruiter simultaneously.
The constraint. The plan required going from three engineers to roughly fourteen within a year, and the founder could not become a full-time recruiter without the product stalling. There was also almost no engineering practice: no continuous integration, no code review, effectively no automated tests, and deployments performed by hand from a laptop.
What we decided. A dedicated team of eight embedded in their organisation, working in their repositories and to their standards, with an explicit practice-transfer mandate written into the statement of work rather than left as an aspiration. Our technical lead served as their interim engineering manager for seven months, including sitting on their hiring panels, with an agreed date to hand that role to a permanent hire.
The trade-off it cost. Velocity fell for the first ten weeks, visibly and measurably, because we insisted on continuous integration, code review and a baseline test suite before feature work resumed. That was a genuinely difficult ten weeks to defend to a board expecting the opposite of a slowdown, and the founder took the criticism for a decision we had recommended. The interim engineering manager arrangement also created a dependency on us that took about four months to unwind properly, and in hindsight we should have set the handover date earlier and held to it more firmly than we did.
Measured outcome. The in-house team went from three engineers to fourteen over thirteen months — six of ours and eight of their own hires, six of whom we helped interview. Deployment frequency moved from roughly monthly to four times a week. Change failure rate fell from 31 percent to 12 percent, measured from their own pipeline data. By engagement close, two of their three workstreams ran without any of our people involved, which was the point.
Engagement 06
Honest record
Neither of these is a story about a difficult client. Both are stories about us getting something wrong, what it cost, and the specific thing we changed afterwards.
What went wrong
The first: we underestimated a data migration by more than double because we scoped it from documentation instead of profiling the real dataset. The second: we delivered a mobile application on time, to specification and to a good standard, and it was retired within a year because almost nobody used it. The project succeeded and the client's investment failed, and we had not challenged the premise.
Who. A European logistics software vendor, consolidating three regional customer databases into one platform. Fixed-price engagement.
What we said. Six weeks for the data migration workstream, quoted from the schema documentation and a 50,000-row sample extract the client provided.
What happened. Thirteen weeks. Once we had access to the full production data we found roughly 22 percent of records carried problems that were invisible in the sample: three different character encodings in the same column, dates stored as free text in two regions, orphaned foreign keys from a 2016 system merge nobody remembered, and duplicate customer records that could only be resolved by a human reading them. None of it was exotic. All of it was discoverable, and we had not looked.
What it cost. Seven weeks of overrun on a fixed price, which we absorbed. More damaging, it pushed the client's own launch communication back twice, and they had already told their customers a date. We cost them credibility that was not ours to spend.
What we changed. We no longer quote a fixed price on any data migration without a paid profiling phase against the full production dataset first, typically one to two weeks. If a client declines the profiling phase, we quote time and materials with a ceiling and we say in writing why. This has cost us at least two engagements to competitors willing to quote a number from a sample. We are keeping the rule.
Who. A US mid-market SaaS company, commissioning a React Native companion application for an established web product.
What we said. We can build this to your specification in five months. We did, on schedule, within budget, with a test suite and a clean handover.
What happened. Adoption reached about 9 percent of eligible users after four months and never moved. The client retired the application inside a year. The web product's users were desk-based and had no meaningful mobile use case; the mobile demand had come from a competitor announcement and a single loud customer, not from evidence.
What it cost. Their money and half a year of their roadmap. We were paid in full, which is precisely what makes this the more uncomfortable of the two. We had a clear commercial incentive to accept the brief, we did not challenge it, and we hid behind the fact that the client said their research was done. It was not.
What we changed. Two things. We now decline build-to-specification mobile engagements without at least a two-week validation phase looking at actual usage evidence, and we will say in the proposal when we think the demand evidence is thin even though saying so risks the sale. Every proposal we issue now carries a section headed "what would make this the wrong project", written by the architect who would lead it. Roughly one enquiry in five now leaves with a smaller recommendation than they arrived with, and this engagement is why.
What these have in common
Four definitions of "delivered". A retired engineer who took the pricing rules with him. A board that had already funded one failure. A founder who could not also be a recruiter. In each case the technology was the easy part once the real constraint was named out loud.
A fourteen-week parallel run. Six weeks of pre-warmed capacity. Nine weeks of definition workshops before a pipeline. Each of those was a deliberate purchase of certainty, and each looked like waste while it was happening. We put the price of that certainty in the proposal so the client chooses it knowingly.
Model tiering cut a bill by 72 percent and left a harder system to operate. A semantic layer ended a reporting argument and made adding a metric slower. Edge caching held a peak and delayed price propagation. The question is never whether there is a cost, only whether it lands somewhere you can carry.
In four of the six, the metric that later demonstrated success did not exist when we arrived. Change failure rate, cost per document, reporting variance, P95 checkout latency. Baselining in week one is what makes an outcome a fact rather than a claim, and it is the cheapest thing on this list.
Answers
Because our clients asked us to. Most of the work described here touches pricing logic, fraud controls, cost structures or clinical data, and several clients treat the fact that they use an offshore partner as commercially sensitive. We would rather publish specific numbers without a logo than a logo without any numbers. Reference calls can be arranged under NDA.
From our own delivery records: cloud billing exports, pipeline telemetry, load-test reports, reconciliation logs and the metrics dashboards we built during each engagement. They have not been independently audited. Where a figure is a client-reported number rather than one we measured directly, we say so in the case study.
In most cases yes, under a mutual NDA and with the client's consent obtained first. We will not name a client before that consent exists. Ask during the proposal stage and we will tell you honestly which of these clients is likely to agree and which is not.
Because every real engagement has one. A migration that halved the cloud bill also left two workloads stranded on a second cloud for nine months. A parallel run that eliminated pricing risk added fourteen weeks. If a vendor presents you with an outcome and no cost, they are describing something that did not happen.
These six cover insurance broking, third-party logistics, healthcare SaaS, outpatient clinical groups, industrial manufacturing and online retail. If your sector is not represented, ask. We will tell you plainly whether we have real depth in your domain or whether you would be our first, because being someone's first is a legitimate risk you should be able to price.
Between four and nine of our people, running from five to twenty-two months. That is the shape of work we do well: a team small enough that everyone knows the system, embedded long enough to own the consequences of their own decisions. We do not staff fifty-person programmes.
The first call is with the architect who would lead your work. Bring the engagement above that resembles your situation and ask what we would do differently. Where a client consents, we will arrange a reference call under NDA.