Technical audit
Next.js Audit
A fixed-price, fixed-scope read of an existing Next.js application - rendering, bundle, caching, render path and deployment - ending in a document with the findings ordered by what they cost you.
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.
Two weeks, a fixed price 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.
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.