Home · Insights · The Platform Risk Audit
Insights

What a board-ready platform
risk audit actually contains.

Most funds have seen a technical review that resolves to three coloured dots and a page of adjectives. Our Platform Risk Audit is the opposite of that — a written diagnosis a board can act on and an acquirer cannot dismiss. Here is precisely what is inside it.

The Platform Risk Audit is a two-week, fixed-price engagement, and it produces one thing: a written document you own unconditionally. Not a retainer, not a slide deck, not a prelude to a sales conversation. It exists to answer a single question honestly — what is this platform really, and what will it take to make it survive the day a strategic buyer's engineers open it up. Three sections carry that answer.

A full codebase and architecture assessment

We start where the risk actually lives, in the code and the systems around it, not in a management self-report. The assessment is concrete and evidence-based, and it covers the things a competent acquiring engineer will check within their first fortnight:

Every claim in this section is anchored to something we looked at. Where we say a subsystem is fragile, we say which one and why. Adjectives without evidence are worth nothing to a board and less to a buyer.

The target state, described concretely

A diagnosis is only useful against a defined destination, so the second section states what "full operational capability" means for this platform — not for platforms in general. That distinction matters. Best practice in the abstract is cheap; what is expensive is knowing which practices this business actually needs and which would be gold-plating on an asset heading for sale.

So we describe the target in specifics: this service split apart, this data path made observable, this deployment made repeatable, this dependency retired. The point is that a reader can hold the current state and the target state side by side and see the exact distance between them — measured in named changes, not in a maturity score.

The value is not in knowing the platform has problems. Every platform has problems. The value is in knowing which ones an acquirer will price, and in what order to close them.

A complete, sequenced remediation plan

The third section is the one funds tell us they never actually get: what changes, in what order, at what cost, on what timeline. Not a wish list — a sequence. Each item is prioritised by what a buyer will genuinely test, so the first pounds of effort move the diligence outcome rather than merely tidying the codebase. Where a fix is cheap and load-bearing, it goes first. Where a rewrite is being proposed for its own sake, we say so and leave it out.

Because the plan is costed and ordered, it doubles as a decision tool. Leadership can draw the line where the return stops — do the first tranche, stop, and still have materially de-risked the exit. That is only possible because the sequence is honest about diminishing returns instead of bundling everything into an eighteen-month programme.

Why it is written, and why it is independent

Two things make the deliverable defensible. First, it is a document, not a presentation — a written diagnosis reads the same in the boardroom as it does in the data room six months later, and it does not depend on the person who narrated the slides. Second, we are independent. Kern is not a build shop, and the audit is not a lead-in to a modernisation contract we are quietly angling for. You own the output unconditionally and may act on it with your own engineers, another vendor, or us. That independence is the whole point: a technical judgement a board can put in front of an incoming acquirer without discounting a word of it — the opposite of a traffic-light report that tells everyone what they hoped to hear and nothing they can use.

See what your platform
actually contains.

A two-week fixed engagement. A written, board-ready diagnosis you own outright. Then decide what to do with it.

Book a 30-Minute Scoping Call