Case study
Our own website-audit tool
The free website audit on this site is our own build. How we engineered it: computed findings, declared limits, and an SSRF-guarded endpoint that stores nothing.
- Industry
- Services
- Web DevelopmentCustom Software
The client & context
Who they are, and what was at stake.
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
The problem we were brought in to solve.
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
How we engineered it.
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.
Technical depthFor 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
The solution, concretely.
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.
- 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
What measurably changed.
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.
- مجانيno sign-up to runA full report in seconds; the deeper render-based pass is an explicit, opt-in email.
Ownership & handover
What the client owns now.
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.
Related
Where to go next.
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.