Delivery

I take systems the last mile: technical due diligence for investors and acquirers, rescue of stalled builds, and legacy migrations executed with parallel runs and zero-downtime cutovers. Fixed scope, written findings, no drama.

When does this service get called?

Three situations, and they arrive in remarkably similar emails.

One: you’re about to write a cheque. An acquisition, an investment, a major vendor contract — and the technology under it is a claim in a deck. The demo worked; demos always work. What you need to know is whether the system behind the demo can carry the plan the price assumes — and the seller’s own engineers, honest as they may be, are not the people who can tell you.

Two: the build has stalled. Nine months into a six-month timeline, the agency has stopped answering on Fridays, and every status call re-litigates the original scope. Everyone still believes it’s nearly done, mostly because admitting otherwise has no obvious next step. The next step is this page.

Three: the legacy system has become the excuse. Every initiative now begins with “well, first we’d have to deal with the old system” — and ends there. It’s load-bearing, undocumented, and the person who built it left in 2021. It has become simultaneously the business’s biggest risk and its most reliable reason to do nothing.

All three share one root cause: nobody independent has looked under the bonnet, so decisions run on hope. Hope is not a delivery methodology. An independent read replaces it with an inventory, a verdict and a sequence — and the relief in the room when that happens is itself diagnostic of how long everyone has known.

What does delivery work include?

• Technical due diligence. Codebase, architecture, data integrity, team dependencies, security posture — read directly, not interviewed about. The deliverable is a report an investment committee can act on: findings ranked by severity, cost-to-fix estimates, and the three that actually change the price flagged at the top. A forty-page appendix nobody reads is a failure mode, not a deliverable.
• Build rescue. Audit what exists, salvage what’s salvageable, re-plan delivery around weekly shippable slices. The first deliverable is always something real in production within two weeks — because a demoralised team and a sceptical board both need evidence before they need a plan.
• Legacy migration. Inventory, strangler-pattern replacement, dual-write bridges, parallel runs until the diff holds at zero, then a Sunday-morning cutover that’s deliberately boring. The full method is written up in the zero-downtime migration article, and the receipts are in the migration case study and the ERP migration.
• Delivery discipline installation. For teams keeping the work in-house afterwards: the cadence, the definition of done, the deploy pipeline health — installed and documented, so the rescue doesn’t need repeating next year.

How do you run due diligence in a week?

By reading the artefacts instead of scheduling meetings about them. The schema first — schemas don’t lie; slide decks do. Ten minutes with the database tells you whether “event-driven ledger architecture” means what the deck says or means forty nullable columns on a table named transactions_new_2. The money path second — trace one rupee end to end: where it enters, what records it, what could double-count it, how it reconciles. If the money path is sound, most other sins are affordable; if it isn’t, nothing else matters. It’s the same discipline as my fintech engineering practice, pointed at judgment instead of construction. The claimed controls third — run the reconciliation they say they run. Ask for last month’s exceptions. A company that says “we reconcile daily” and cannot show yesterday’s exception queue has told you something the data room didn’t. The people map last — not interviews about architecture, but the question that actually prices risk: how many people can deploy, debug and explain each critical system? The answer is usually one, and that one has usually mentioned leaving.

The published teardowns are the public version of this exact skill — fourteen companies’ architectures, read accurately from their artefacts. Due diligence is the same reading, under NDA, with a price attached to the verdict.

How does a rescue actually recover?

Gone pear-shaped is a state, not a verdict. The recovery sequence is always the same. Inventory honestly — what exists, what works, what was invoiced versus what was built; this alone dissolves most of the fog, because stalled projects run on ambiguity the way engines run on fuel. Ship something small immediately — a real feature, in production, within two weeks; it’s rarely the most important feature, but it’s the proof that shipping is possible, and teams remember how quickly. Re-plan in slices — weekly, shippable, demonstrable; no milestone further than a month out, because milestones past a month are fiction with a date. Fix the pipeline while you’re in there — a build that takes an afternoon and a deploy that needs courage are usually half the reason the project stalled.

And the part nobody expects: most rescues exonerate the team. The engineers were usually fine; the scope was liquid, the priorities rotated weekly, and nobody had the standing to say no. The rescue plan’s real innovation is that saying no becomes someone’s job. For engagements where that someone should stay long-term, /services/fractional-cto is the standing version.

What are the red flags that predict a stall?

After enough rescues, the predictors become boringly consistent — score your own project against them. No shippable slice in the last month — not a demo, a deploy. The estimate never changes — healthy projects re-estimate as they learn; a six-month figure that survives six months of surprises is a hostage note. One person holds the deploy — bus factor of one on release day means every delay has the same first name. Scope arrives verbally — if change requests don’t exist in writing, neither does the baseline they’re changing. The vendor’s best engineer rotated off — the polite email announcing “an exciting new team member” is, statistically, the beginning of the middle of the end. Three or more of these and the stall is already underway, whatever the status report says — the difference between a cheap correction and an expensive rescue is how early someone says it aloud.

What’s the proof?

• The zero-downtime migration — years of live financial history moved with parallel runs; customers noticed nothing.
• The ERP migration — a factory moved off a decade of Tally-Excel-registers without stopping the floor.
• The ledger rebuild — a rescue and a migration wearing one engagement.
• The teardown series — fourteen public architecture reads; the diligence skill, auditable before you buy it.

Related reading

Zero-downtime migration · Event-driven pitfalls · Postgres in production · Why your ledger drifts

The first call is the cheap version

Buying, stuck, or scared of your own legacy system — thirty minutes, seedhi baat: /contact. Bring the ugly truth; I’ve heard worse, and the before-call is always cheaper than the after-call.