Thirty tools,
one template.

01 · Scope

Why thirty, and not three.

Three would have been the sensible answer. We tried it: we have shipped individual audit tools before, each with its own codebase, its own front end, its own deployment. They work. They are also the reason the register kept growing instead of shrinking — every new idea cost a week, so every new idea waited.

The cost is not the checking logic. The logic for “are your consent settings actually holding back the trackers” is maybe two hundred lines. The cost is everything around it: a page, a form, a result view, error handling, rate limiting, a database, a way to capture a lead, a deploy pipeline. Ninety percent of a small tool is not the tool.

So the question stopped being “which three should we build” and became “what would have to be true for the thirty-first to cost an afternoon.”

02 · Architecture

The shape that scales.

One service. One database. One stylesheet. Each tool contributes exactly two files: a configuration object that describes how it presents itself, and an engine that describes what it checks. Everything else is inherited.

The configuration is deliberately boring — name, colour, the questions it answers, where its leads should go. It lives in a file, and it can also be overridden at runtime, so the presentation of any tool can change without a deploy. What is not overridable is the scoring. That was a conscious asymmetry: if the person running the tool can quietly retune what counts as a pass, the number stops meaning anything, and the number is the entire product.

The engine gets handed a single object with the network functions it is allowed to use, and returns a list of findings. It cannot open a socket by itself. That sounds like bureaucracy until you remember that thirty engines written at speed will otherwise contain thirty different timeout policies, thirty different opinions about how large a response is too large, and at least one that will happily follow a redirect somewhere it should not go. Centralising the fetch made all thirty polite and safe at once.

The pages are rendered on the server as plain HTML. No build step, no framework, nothing to hydrate. That was originally a speed decision and turned into an SEO one: every tool page is a real document that Google can index and that an AI assistant can read, rather than an empty container waiting for JavaScript.

A platform is not the thing you build first. It is the thing you notice you have already built three times.

03 · The rule

The third answer is the one that matters.

Every audit tool you have ever used has two answers: pass and fail. The good ones have a third, and it is the one that decides whether the tool is worth trusting.

Sometimes we cannot tell. A store blocks automated requests. A banner is injected by a script we do not execute. A signal simply is not exposed publicly. In every one of those cases there is a tempting, easy, wrong move available: pick the more likely answer and present it with the same confidence as the rest.

We learned the cost of that the hard way, and wrote it up when it happened to us — one of our own scanners told a large storefront it was missing markup that was, in fact, right there. So this time the honesty is structural rather than cultural. A finding can be unknown, an unknown finding must carry a written reason explaining what stopped us, and unknowns are removed from the denominator instead of being scored as failures. If we could not verify enough of a store, the report refuses to publish a grade at all and says why.

That last part cost us the nicest-looking version of the product. A score is more shareable than “insufficient data.” It is also, in that situation, a lie.

04 · Constraint

Public data only, and why that is a feature.

None of these tools ask for an access token, an app install, or a login. Not because it would be hard — we build custom Shopify apps for a living, and have written about exactly when that is the right call — but because the moment a free tool asks for admin access, it stops being a free tool and becomes a decision.

Working within that constraint is a useful discipline. It rules out roughly a dozen of the highest-scoring ideas in the register, all of which need order data or write permissions, and they now sit in a different pile marked app. What it leaves is a surprisingly large surface: your storefront HTML, your product feed, your sitemap, your robots file, your response headers, your DNS records. A great deal of what is quietly wrong with a store is visible from the outside, which is exactly why it is worth knowing — your customers and the crawlers are standing outside too.

05 · The funnel, honestly

What the email actually buys.

These tools exist because we would like some of the people who run them to hire us. Pretending otherwise would be silly. So it is worth saying plainly where the line sits.

Without giving us anything, you get the score, the grade, how much of your store we could actually verify, and the worst findings by name. That is deliberately enough to act on: if it says three tracking cookies are being set before consent, you have learned the thing, and you can go and fix it yourself with no further contact from us.

What an email address unlocks is the detail — the exact evidence we captured for each item and the specific fix. Nobody should have to hand over an address to find out that something is broken. Trading one for the repair instructions is a fair deal, and we would rather write it down than have you infer it.

06 · Generalise

What transfers to a store.

Three of these decisions are not really about audit tools.

Configuration beats duplication, and the boundary is the design. The valuable question was not “how do we share code” — it was “which parts must every tool be free to differ on, and which must they never differ on.” The same question is the whole of a theme architecture. A section that can be configured in the ways merchants actually need, and cannot be configured into an inaccessible mess, is worth ten flexible ones.

Centralise the dangerous thing once. Any store with a dozen apps has a dozen independent opinions about when to load scripts and what to do when a request fails. You cannot fix that app by app. You fix it by owning the layer they all pass through.

Design the third state in. Stores are full of interfaces that only imagine success and failure: no result for a search term, an image that has not loaded yet, a shipping rate that could not be calculated, a size chart that is missing for one product. The version that says “we could not work this out, here is what to do” is nearly always cheap to build and nearly always missing.

Quick check

Worth doing on your own store this week.

• Open your storefront with cookies cleared and check what is set before you click anything.
• Read your own robots file. Confirm you have not accidentally hidden yourself from the assistants people now shop with.
• Load a product page in every language you sell in and look for untranslated buttons.
• Check whether your viewport tag lets a customer pinch to zoom. Many themes still say no.
• Ask one question of any tool you rely on: what does it do when it cannot tell?

They are free, and they are landing weekly.

The first of them are live at googogogo.com/tools, and the rest arrive as they pass review — each one has to survive a second pass whose only job is to find invented numbers and false confidence before a stranger sees it. No signup, no install, nothing to uninstall afterwards. If one of them tells you something that turns out to be wrong, tell us, and that becomes the next entry in this journal.

Questions

Questions people ask.