Case study
Our own website-audit tool
A free, no-sign-up website audit that scores findability, accessibility, and front-end delivery — and earns trust by being honest about what a fast pass can and cannot see. We built it, we run it, and you can use it right now.
- Industry
- Internal build · developer tooling
- Services
- Web DevelopmentCustom Software
- 3scoring pillars
- 20+checks, each computed
The client & context
The client was us — and that is the point.
This is an internal build, not paid client work, and we are presenting it as a case study deliberately. An early studio cannot honestly show a wall of client logos it has not earned yet. What it can do is open up something real it has built and runs in production — and let you inspect it directly.
The free website audit on this site is that thing. It is live, it is in front of you, and you can run it on your own site in the next minute. So rather than describe work you would have to take on faith, this study walks through how a tool you can already use was engineered — and the standards behind it are the same ones a client project gets.
We held it to the rule the whole studio runs on: say only what is true, and make the thing legible enough that anyone can check.
The challenge
An honest free audit is harder to build than a dishonest one.
Most free "website grader" tools exist to capture an email, and it shows: padded scores, vague findings, and a number engineered to look alarming enough to book a call. That approach was off the table — it is the exact opposite of what we sell, and a buyer who later discovers the gauge was rigged never comes back.
So the brief was awkward on purpose. The tool had to be genuinely useful and genuinely honest: every score computed from the real page, every finding specific enough to act on, and — the hard part — the things a fast pass cannot actually determine declared openly rather than guessed.
For a young studio, the tool is the audition. If it is sloppy or dishonest, it argues against us more convincingly than any pitch could argue for us.
The approach
Compute everything, declare the limits, defend the endpoint.
We built a self-contained scoring engine rather than reselling a third-party audit API. Every check reads the HTML we actually fetched and the way the server delivered it, then reports three things in plain language: what we saw, why it matters, and roughly how much effort the fix is.
The scoring is deliberately unweighted and legible — a passing check counts, a warning counts half, a failure counts zero, and neutral observations are excluded rather than padded in. Nothing is on a curve to make a number look worse than it is.
Three plain-language pillars
Findability (SEO), Access (accessibility), and Delivery (front-end performance) — named for what they mean to an owner, not for the jargon underneath.
Computed, never invented
Every finding is derived from the fetched bytes and the response timing. Where the data is not there, the tool says so instead of estimating.
Honest about its blind spots
A single static request cannot judge rendered colour contrast, real keyboard order, or field Core Web Vitals. The report states those limits plainly and points to the deeper render-based pass.
Hardened against abuse
It fetches a stranger-supplied URL on the server, so it is guarded against server-side request forgery and rate-limited per visitor — and it stores nothing.
How the endpoint stays safe and honestFor engineers
Fetching a visitor-supplied URL on the server is a classic SSRF vector, so the guard runs in two layers. A cheap string pass rejects anything that is not http(s), strips credentials, and refuses internal names and private, loopback, link-local, unique-local, CGNAT, and cloud-metadata addresses. Then, as defence in depth, the fetch resolves the hostname and re-checks every resolved address — so a public domain that points at a private IP is blocked too.
Abuse protection is an in-memory, per-IP fixed window — a handful of runs a minute per client. It is honestly scoped: it protects a single instance and is not a distributed limiter. A cross-instance limiter is infrastructure work we have flagged rather than pretended to already have.
The endpoint runs on the Node runtime, is never cached, and persists nothing — no URL, no result, no IP beyond the in-memory rate-limit window. The optional deeper report, which renders the page in a real browser and can fold in field Core Web Vitals from PageSpeed Insights when a key is configured, is a separate, explicit, opt-in action through our existing lead form, not a hidden capture.
What we built
A real instrument, not a lead-capture gauge.
The result is a free audit that returns a scored report in seconds: an overall grade, a grade and tally per pillar, and a sorted list of findings with the failures and warnings surfaced first. Each finding carries a plain-English explanation of why it matters and an honest sense of whether it is a quick fix or real engineering.
The engine, the SSRF guard, the rate limiter, and the report rendering are all ours, and they ship as part of this site — a server endpoint and a small client island that renders the JSON it returns.
- Three pillars — Findability, Access, and Delivery — scored by one engine we wrote and maintain.
- More than twenty individual checks, each computed from the page we fetched, never estimated.
- Honest limits: rendered contrast, real keyboard order, and field Core Web Vitals are declared, not guessed.
- An SSRF-guarded, rate-limited endpoint that stores no URL, result, or visitor data.
- A free, no-sign-up first pass; the deeper render-based report is an explicit, opt-in email.
The outcome
Proof you can run yourself.
Because this is our own tool, we are not asking you to trust a metric we cannot show you — we are inviting you to check it. Run it on your own site, then read what it says it cannot see. That honesty is the outcome that matters: the tool demonstrates how we build by being something you can verify rather than something we assert.
The figures below are facts about the tool itself, not borrowed business results — exactly the kind of claim an early studio can stand behind.
- 3pillars, one engineFindability, Access, and Delivery — scored by code we wrote and maintain, not a resold API.
- 0records storedNo saved URL, result, or IP beyond an in-memory rate-limit window. Privacy by construction.
- Freeno sign-up to runA full report in seconds; the deeper render-based pass is an explicit, opt-in email.
Ownership & handover
The same standard your project would get.
We run this tool ourselves, so its discipline is on display rather than described. It is documented, its scoring is legible, its limits are written down, and its endpoint is defended — the same engineering posture, and the same "you own it, you can reason about it" principle, that a client build ships with.
When we build for you, that posture comes with full source, infrastructure, and a documented handover, so your team — or any team — can run and extend it. Here, the proof is simply that you can see and use the result for yourself.
- A self-contained engine — no dependency on a third-party audit service to keep it running.
- Findings you can act on, with the effort each one takes stated honestly.
- A written account of what the fast pass does not cover, so the result is never mistaken for a full review.
Related
See the capabilities behind it — or try it yourself.
Want a tool — or a system — built to this standard?
Bring us a real problem. A senior engineer — not a salesperson — replies within one business day, with a fixed scope before we start, and you own everything we build.