What you walk away with

  1. A prioritized findings report, with every finding ranked by impact and cost.
  2. A working call to walk through the findings and answer your questions.
  3. A written verdict: rebuild, targeted refactor, or leave it alone.
  4. A clear view of the debt, security exposure and scaling limits that will decide what your next year costs.
  5. Findings you can use with us, with another team, or on your own.

What it covers

Core Web Vitals and INP
Field and lab measurement of LCP, CLS and INP, including the interaction delays that frustrate real users without showing up in a quick test. We find what is slow, why, and what it is likely costing you.
Architecture and system design
How the system is actually built: its boundaries, data model, coupling, and the decisions that will either absorb growth or break under it. The expensive problems are architectural, so this is where we look hardest.
Technical debt
An honest inventory of the debt slowing every change and inflating every estimate, with each item ranked by cost and risk rather than listed for effect.
Security surface
The exposure a determined attacker would probe first: dependency risk, access control, configuration and the gaps that turn into incidents. This is not a penetration test, but it maps the surface a rebuild must close.
Scalability risk
Where the system stops being fast or cheap as traffic, data or team size grows. We map those limits before they cost you.
Rebuild-versus-refactor read
A clear verdict on whether you need a rebuild, a targeted refactor, or neither, with the reasoning written down.

Why the audit is paid

A free audit is usually a sales tool, so its findings tend to point at whatever the vendor sells. Ours is a defined piece of work in its own right, so our job is to be right, not to upsell. Sometimes being right means telling you the system is healthier than you feared and the rebuild can wait.

The filter works in the other direction too. A business willing to invest in understanding its own system before committing to a rebuild is the kind of client we work best with. The audit is how both sides find out, quickly and with a defined scope, whether a larger engagement is the right call.

It draws on the same discipline as our technical consulting and performance engineering work, and it is the sensible first step before a larger software build. The decision rule is simple: if you are about to commit to a rebuild, get the audit first.

How the work runs

Every engagement moves through the same five stages, with one team throughout.

  1. Understand

    A first conversation and a look at what already exists: your position, your customers’ path, your traffic and your technology.

  2. Define

    Positioning, scope and architecture decided deliberately and written down, so everyone knows what is being built and why.

  3. Design

    Brand, content and interface designed together, against those decisions rather than the fashion of the month.

  4. Build

    Built with speed, accessibility and security as requirements, and reviewed on a staging site before anything goes live.

  5. Improve

    Launch is the start. We measure what matters, fix what drifts and report in plain language.

How an engagement runs

Further reading

Performance & architecture audit: common questions

What exactly do I receive?

A prioritized findings report covering Core Web Vitals and INP, architecture, technical debt, security surface and scalability risk, with each finding ranked by impact and cost, plus a working call where we walk through it and answer questions. You leave with a clear read on your system and a defensible verdict on whether to rebuild, refactor or leave it alone.

How long does it take?

Most audits are delivered within one to two weeks of kickoff, depending on system size and how quickly we can get access. It is deliberately short: the point is a fast read, not a months-long study.

How does the audit relate to a larger project?

Its findings scope the build. If you continue with us, the audit is that engagement's first phase. If you take the report elsewhere or do nothing, you still leave with real, usable findings.

How is this different from performance engineering or technical consulting?

The audit is a diagnosis with a fixed scope and a written verdict. Performance engineering is the hands-on work of fixing speed problems and keeping them fixed. Technical consulting is broader, ongoing advice on decisions such as build versus buy or whether to keep a vendor. The audit is often the sensible way into either.

What if the audit says we don't need a rebuild?

Then that is what it says, and it is a valuable outcome. A paid audit means our incentive is to be right, not to sell you a rebuild. Sometimes a system is healthier than its owners fear, and the work can wait. To start, tell us what you're building and what worries you about it.

YOUR NEXT CHAPTER

Tell us what you're building.

A few lines about the idea, the business and what is getting in the way.

DISCUSS YOUR PROJECT
Good work starts with a conversation. No brief needed. A few lines are enough.