Technology audit
An audit is not there to hand out grades. It is there to answer a question someone is already asking: can the next stage be built on these foundations, at what price, and what has to change first?
When to call us
- _You are taking over a product built by a team or supplier who has moved on.
- _You are preparing a funding round and technical due diligence is expected.
- _Your iterations are slowing down and you cannot pin down why.
- _You are weighing evolving what exists against starting again on new foundations.
What we examine
We examine the technical foundations of an existing product across their whole chain: architecture and structural choices, code quality and legibility, infrastructure and deployment, security, and accumulated debt with what it actually costs.
We also look at what a code review alone leaves out: what actually 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.
What we bring
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.
How we work
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.
What we don’t do
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.
What you get
- _A reasoned assessment: architecture, code, infrastructure, security, debt
- _Risks identified and ranked by real consequence rather than theoretical severity
- _Arbitrated recommendations, each with the effort and the gain to expect
- _A proposed trajectory: what comes first, what can wait, what not to do
- _A live debrief with the team, so trade-offs get discussed rather than delivered
Frequently asked questions
Does an audit always lead to work with you?
No. You leave with the assessment, the trade-offs and the trajectory, and you are free to act on them with whichever team you choose. If you want us to carry them out, that is the move to production or the technical partnership.
Do we need an audit, or a move to production?
If the question is “where does my product stand and what should I do”, it is an audit. If it is “make it fit for production”, that is the move to production: the work starts with an assessment anyway, but it does not stop there.
Who carries out the audit?
The four partners, each on their own ground: product and design, frontend and mobile, backend and infrastructure, data and AI. No junior placed on the engagement, no subcontracting.
How we frame, arbitrate and commit is set out in detail in the Vezero Method.