Process

How we work

The same four steps on every engagement, in the same order, whether it is a two-week audit or a two-year retainer. The point is that you always know which step we are in and what comes out of it.

Four connected process steps Four circular nodes connected in sequence, labelled baseline, prioritise, execute and report, with the final node highlighted. baseline prioritise execute report

Audit & baseline

Before anything is changed

We measure the site as it stands before touching any of it. That means a full crawl with rendering, current index coverage, Core Web Vitals field data by template, ranking positions for the terms you actually care about, and server logs where you can export them.

This step exists for one reason: without a dated baseline, every later claim of improvement is unfalsifiable. Six months from now the question "did this work?" should have an answer that does not depend on anyone's memory.

What you get

  • A dated, frozen baseline of every metric we will later report on
  • A written findings document, not a slide deck
  • The raw crawl data, so you are never dependent on us to re-examine it

Prioritise

Agreed with you, in writing

Every finding gets two scores: the engineering effort to fix it, and the likely impact if it is fixed. Then they are sequenced. A one-line robots directive that unblocks two hundred pages goes before a six-week internal linking project, even though the second one sounds more substantial in a meeting.

You approve the order before any work starts. If you disagree with a ranking — often because you know something about the roadmap that we do not — we change it and say so.

What you get

  • A prioritised fix list, scored on effort against impact
  • A sequence mapped to your next two sprints, not an undifferentiated backlog
  • An explicit list of what we are choosing not to do, and why

Execute

Capped hours, tracked

Work happens against the agreed plan and against a capped number of hours. In practice that is either pull requests in your repository going through your normal review process, or written specifications and code review if your team would rather ship it themselves.

Hours are tracked and visible. If something takes twice as long as estimated you hear about it while it is happening, not in the invoice.

What you get

  • Implementation in your stack, or specs your engineers can work from directly
  • Post-deploy verification that each fix did what it was supposed to
  • An hours ledger you can see at any point in the month

Report

Same format, every month

Every month closes with the dashboard you can already see on this site: the metrics, the open technical issues, what shipped, and what changed since the baseline. Identical format each time, so month nine is directly comparable with month one without anyone re-reading a methodology note.

If a number went the wrong way, it appears in the report with an explanation. That is the entire point of reporting in a fixed format — you cannot quietly change which metrics you show when the news is bad.

What you get

  • The monthly dashboard, in the same format every time
  • An open issues list your engineering team can work from directly
  • A quarterly re-baseline against the original audit

See a sample dashboard

Start at step one

Every engagement begins with measurement, because everything after it depends on having a number to compare against.

Book a technical audit

15 minutes, no pitch deck.