Technical diligence
What actually exists, what is load-bearing, what is one resignation away from being unmaintainable, and what the remediation genuinely costs. Written for an investment committee, not for engineers.
The software is usuallywhere the value is stuck.
Operating companies in regulated industries tend to run on systems that grew rather than were designed. That is not a technology problem until it becomes a margin problem, a diligence problem, or an integration that will not close.
Every operator knows
which three things are broken.
They are rarely on the technology roadmap, because the people who feel them are not the people who write it. They show up instead as headcount that cannot come out, a month-end that takes nine days, a compliance answer nobody can produce quickly, and an integration that keeps slipping. Finding those and costing them is most of the work.
WHERE WE HELP
Four engagements, one hold period.
Scoped to the timeline that matters to you rather than to an open-ended roadmap. Each can be bought on its own.
Modernization without a rewrite
Most portfolio systems do not need replacing, they need the three things everyone works around fixed. We find the smallest set of changes that removes the operational drag, and sequence it against the hold period.
Carve-out separation
Standing a business up on its own systems when it has been sharing the parent's. Identity, data, integrations and the boundary the TSA assumed somebody would build.
Post-close integration
Two companies, two systems of record, one set of numbers the board expects to reconcile. Usually the difference between a thesis on paper and a thesis realised.
Most of our work begins with software somebody else wrote under time pressure. Reading an unfamiliar codebase and telling the truth about it is the core skill, not an aside.
Audit trails, controlled approvals, tenant isolation and evidence requirements are our default assumptions rather than a specialism we bolt on for healthcare deals.
Including our own. Deliverables include the source, the architecture and the runbook, and nothing we build requires us to keep existing.
A scope and a price before billable work, which is the only way this is comparable across a portfolio rather than a series of open-ended engagements.
We will also tell you when a system is fine and the problem is a process or a person. A diligence report that finds nothing is a useful result, and we would rather deliver one than manufacture a project.
Tell us the thesis,
and where it is slipping.
Most engagements start with a short read of what exists and a written view of what it would take. That is usually enough to decide whether there is anything worth doing.
Portfolio conversation →