Vendor takeover
Taking a live product off another vendor in two weeks
A care-coordination platform changed hands mid-flight. Two weeks to take the credentials, audit what we had inherited, fix what was broken and stand up an environment we controlled.
- From first handover meeting to a controlled environment and a written gap analysis
- 2 weeksFrom first handover meeting to a controlled environment and a written gap analysis
- Backend, web, mobile, dependencies, security and test coverage audited separately
- 10 reportsBackend, web, mobile, dependencies, security and test coverage audited separately
- The external clinical integration deliberately kept off the first release
- Release 1 without itThe external clinical integration deliberately kept off the first release
The client
A US elderly-care coordination platform connecting residents, families and professional caregivers in senior-living communities, operating under a health-data compliance agreement, with a product already built by a previous vendor.
The engagement
A two-week handover followed by discovery running in parallel with development, phased so the first release did not depend on the hardest integration.
The problem
Inheriting a live product is where delivery organisations quietly lose two months. The credentials are scattered across a dozen third-party services, nobody can start the database, the architecture diagrams do not exist, and the incoming team's instinct is to be polite about what they find. Meanwhile the client assumes the handover is administrative and expects the roadmap to continue uninterrupted.
What I did
I treated the handover as a delivery phase with its own definition of done rather than as a meeting. Week one was inventory and access — every third-party service enumerated and transferred, with the things that did not work written down rather than worked around quietly. Week two was the audit: separate written gap reports for backend, each frontend surface, mobile code and security, dependency health and test coverage, plus a consolidated summary — because a single 'it's fine' from an incoming team is worth nothing to a client and a stack of specific findings is worth a great deal. In parallel we fixed the critical defects, stood up continuous integration and two environments on infrastructure the client controls, and logged the inherited monolithic architecture as a scaling risk rather than pretending it away. Then the phase plan was drawn so the first release excluded the external clinical integration entirely — the one dependency outside our control — and the second release carried it.
What was built
A structured takeover: credential inventory across every third-party service, a code audit across backend, web, mobile and test coverage producing ten written gap reports, critical defect fixes, continuous integration and two environments on infrastructure the client owns, and a phased plan whose first release deliberately excluded the external clinical integration.
On the table at the end
- Credential and third-party access inventory
- Ten gap reports across backend, web, mobile, dependencies and test coverage
- Continuous integration and two environments on client-owned infrastructure
- Phased release plan with the hardest integration deferred to the second release
- Architectural risk register entry on the inherited monolith
What it changed
Turned a vendor change — normally weeks of quiet drift — into a two-week transition with a written gap analysis, working pipelines, two controlled environments and a named architectural risk, so the client knew what they had actually bought before committing to a roadmap.
How it ran
- 01
Inventory the keys
Every third-party service, store account, analytics and credential vault enumerated and transferred, with the gaps recorded rather than absorbed.
- 02
Audit in writing, surface by surface
Separate gap reports for backend, web, mobile, dependencies, security and testing, plus a consolidated summary for the client.
- 03
Stand up ground you control
Continuous integration and two environments on client-owned infrastructure, so the team stops depending on the outgoing vendor's setup.
- 04
Name the architecture risk
The inherited monolith logged as a scaling constraint on the risk register in week one, not discovered as a surprise in month six.
- 05
Phase around the dependency
First release scoped without the external clinical integration; the integration carried into the second release with its own target date.
Other work
All case studies →- Payments
A red project where the client had no single voice
A payments build was slipping on every axis at once. The root cause was not the team — it was that meetings with the client were being spent discovering the client's own requirements.
- Enterprise software
Inheriting six live client engagements in one week
A departing manager, six active accounts, and clients who found out by email. I built a handover pack per engagement and a generic pack per engagement type, so the next handover would not depend on me either.
- Public sector technology
Fifty change requests, each with a decision attached
An offline-first enforcement app across two platforms, where the critical dependency was an interface the client was writing themselves. Every scope change got a costing and a recorded decision — which is why the overrun conversation was survivable.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.