Case study
Handed back on the date set in week one.
A UK B2B SaaS analytics company of about 90 staff whose data team had left, leaving a dbt/Airflow platform with no owner. Three engineers took it over for 8 months, wrote down how it worked, stabilised it, trained the two in-house hires who replaced them, and left on the agreed date.
The situation
The data team had left and nothing about the platform was written down. Airflow ran the schedules, dbt built the models, and the dashboards the company sold against came out of the far end. When something broke, the analysts found out from a stale number, and nobody left in the building could say which job had failed or what depended on it.
Two in-house hires had been made and had not started. The company asked for an 8-month engagement with an exit date attached to it rather than an open-ended one, which is the only shape a takeover should have.
What we did
The first stretch was reading and writing down: which jobs exist, what each model feeds, which runs the morning dashboards depend on, and which can fail quietly until someone gets to them. That document was the deliverable everything else rested on, and it was reviewed by the client's analysts rather than filed by us.
Then stabilisation, in order of how often something woke someone up. The infrastructure went into Terraform on AWS so the platform could be rebuilt from a repository instead of from memory. Python jobs that read directly from the production PostgreSQL were pointed at a replica. When the two in-house hires started, they sat with our three engineers, and from month six they ran the on-call rota with our engineers available but not paged.
What changed
The platform had a written description, a named owner, and a rebuild path in Terraform, where before it had none of the three. The two in-house hires were running it before we left rather than after.
There is no latency or error-rate figure on this page. Nothing was being measured when we arrived, so a before number does not exist, and we are not going to construct one.
How it ended
On the date agreed in the first week. The engagement was scoped to end — that is what a takeover is — so the exit was the deliverable rather than something that happened after it. Eight months, three engineers, and a handover to two people who had been doing the work for the previous two months.
We have not worked with them since, and for this kind of engagement that is the correct outcome.
dbt and Airflow came with the platform; they are the client's, inherited rather than chosen, and we did not replace them in an engagement scoped to end in 8 months. Our side of the work is Python on AWS against PostgreSQL, with the infrastructure moved into Terraform so the incoming team could read it.
The handover, in figures
We hired two people to own the platform and needed someone to keep it alive until they could. The end date was in the first week's notes and it never moved. They left on it, and by then our two were already running the rota.
A system whose team has already left?
Three engineers, 8 months, an exit date set in week one. A takeover is quoted against two paid weeks of discovery rather than against an estimate made before anyone read the code.