What a platform assessment actually looks for

Most assessments of a software platform read like a code review with a bigger font. They list what is untidy. They rarely say what it is going to cost you.

Here is what we actually look at, and why each one earns its place.

Deploy frequency, and how frightening it is

Not the number on a dashboard. The honest answer to "when did you last ship on a Friday afternoon?"

Deploy frequency is the single best proxy for the health of everything else. A team that ships several times a day has, by necessity, already solved testing, environment parity, observability and rollback. A team that ships monthly has not solved any of them, and each release carries a month of unrelated risk bundled together.

Bus factor, per subsystem

Not "how many engineers do you have" but "for each part of this system, how many people could safely change it?"

The answer is often one. Sometimes it is zero, because that person left. This is the number that turns a normal engineering problem into a business risk, and it is invisible on any architecture diagram.

The cost curve of change

Take three features of roughly equal size, shipped a year apart. How long did each one take?

If the line is flat, the platform is fine and the problem is somewhere else. If it is bending upward, you have a compounding cost and a date in the future where the platform stops being able to change at all. Most people who call us are somewhere on the bend and have not yet drawn the line.

What the pipeline does to a change

We trace one commit from a laptop to production. Every gate, every wait, every manual step, every environment that does not match the one after it.

This is usually where the surprises live. The code is rarely the constraint.

What the system does when a dependency fails

Not whether it has retries. Whether anyone has watched it fail. Third-party systems go down, and the interesting question is whether yours degrades or disappears.

What we deliberately do not do

• We do not count test coverage. It measures lines, not risk.
• We do not grade the code against a style guide. That is a linter's job.
• We do not recommend a rewrite unless the narrow case for one is genuinely met.

What you get

The call is where we work out whether any of this applies to you, and it costs nothing. The assessment is the paid piece of work that answers it properly: one to two weeks, one principal, and a written view of what is wrong, what is fine, and what to do in what order, with the ordering driven by cost and risk rather than by tidiness.

It is yours to keep either way. If the honest conclusion is that you do not need us, that is what the document will say.