Next.js Audit

Most engagements here start with one. A team knows something is wrong - the application is slow, or it does not rank, or nobody is confident deploying it - and wants a specific answer before committing to a project.

A fixed scope and a fixed price, both agreed before we start, and a document at the end that is yours whether or not you continue with us.

What we read

The rendering model. Which routes are static, which went dynamic and why. An accidental ƒ in the build output is the single most common finding, and it is usually one cookies() call in a shared component costing you the CDN on every page below it.

The client boundary. Where use client sits, what it drags into the bundle, and what the First Load JS would be if it sat one level lower.

Caching. Which of the four layers each piece of data is in, whether the tags mean anything, and what happens on a redeploy.

The render path for search. What a crawler receives versus what appears after hydration, canonicals, the hreflang cluster if there is one, and whether the sitemap agrees with the router.

Field data. Core Web Vitals from real visitors rather than a lab score, per route, with the LCP element named.

The deployment path. What builds it, what tests run, what happens when it fails, and whether anyone still working there knows.

How it runs

Send the repository, a way to run it, and half an hour with whoever knows the history. Production access helps and is not required.

The price is agreed in writing before we start, in a short scope saying what we will read and what we will leave alone. It does not rise if the application turns out worse than expected, because an audit that costs more the worse the news gets is not one you can act on.

Between five and ten working days later the document arrives, with one walkthrough. What happens next is yours to decide.

What you get

A document, not a slide deck. Every finding has three parts: what is wrong, what it costs in numbers we measured, and what fixing it involves. Ordered by cost, not by severity label - a 400ms LCP regression on your highest-traffic route outranks a theoretical issue on a page nobody visits.

Findings we can fix in under an hour, we fix during the audit and tell you. We are not going to bill a project for something that was a one-line change.

What it is not

It is not a Lighthouse report with commentary. You can run Lighthouse yourself; what you cannot easily do is decide which of its complaints matter for your architecture, and that judgement is the deliverable.

It is also not a sales document. Some audits end with "this is in good shape, the problem is elsewhere." We would rather write that than manufacture a project.

After it

If the findings point at one of the other services, the audit price comes off that engagement. If they point at work we do not do, we say so and, where we can, name who does.

The audit is also the first month of maintenance and support, if that is where you land - the orientation is the same work.