Technology audit

We examine an existing product across its whole chain: architecture and structural technical choices, code quality and legibility, infrastructure and deployment, security, accumulated debt and what it actually costs, user experience, and the fit between what the product does and what it is supposed to make possible.

We also look at what a purely technical audit leaves out: how decisions get made, what slows iteration down, and dependence on one person or one supplier. Those points usually explain why a product becomes slow to evolve long before code quality does.

The output is not a list of findings sorted by severity. It is a reasoned judgement: what has to be dealt with before anything else, what can wait, what needs no fixing at all, and what each option would cost.

Four experts with over ten years of experience each, covering product strategy, design, frontend, backend, data and infrastructure. A serious audit needs that spread: an architecture problem rarely reads correctly without understanding the product it serves.

We have audited products at every stage, from pre-seed to unicorn. That gives us a scale of comparison. Knowing what is normal for a six-month-old v0 and no longer acceptable for a product carrying revenue avoids the two symmetrical mistakes of auditing: dramatising deliberate debt, or waving away a real risk.

We are practitioners, not observers. We build products every week, including our own. A recommendation we make is one we would know how to execute.

We start from the question you are asking, not from the code. An audit before a funding round, an audit before taking over a product built elsewhere, and an audit before a step change in scale do not look at the same things, even on the same product.

We then make explicit the structural technical choices we find, so they can be challenged without starting from scratch. The fourth pillar of our method says the same thing: quality determines how fast the product can still change direction.

We do not produce a hundred-page report nobody will read. A useful audit fits in a document a team can read in an hour and argue about the next day.

We do not recommend a rewrite by default. It is the easiest conclusion to write and the most expensive to follow; it is warranted in a minority of cases, and we say so when it is not.

We do not mistake our preferences for risks. A technical choice we would not have made is not a problem if it is deliberate, documented and coherent with the rest. We flag what will stop you moving in six months, not what we would have enjoyed more.