Each claim on the site is wired to a test that fails when it stops being true.
Every sentence on this site that states a fact has an automated check standing behind it. Here is how those checks get written, and the three that are still run by hand.
- Client
- A site that checks its own claims
- Practice
- AI Consulting
- Published
- 26 August 2026
The number was wrong on three pages and right on none of them.
A figure about a client’s results had been sitting on this site for months. An audit found it did not survive contact with the client’s own database, so it was taken down. That happened on a Sunday and took about four minutes.
Nine days later the figure was still live. Not in the place it had been removed from, which was genuinely clean, but on two other pages that quoted the same number in their own words. One of them was the page a buyer lands on when they decide to get in touch. Nobody had been careless. The fix lived in one file and the claim lived in three, and nothing in the world connected them.
That is the shape of almost every embarrassing thing a small studio ships. Not a catastrophic bug, but a true sentence that quietly stopped being true while everyone was busy elsewhere, with no mechanism anywhere whose job was to notice.
- 01A fact repeated in three places is three separate things that can rot
- 02The compiler cannot read English, so a stale sentence compiles perfectly
- 03Deciding to be careful next time is not a mechanism, and it never holds
Every fix owes a check, at the cheapest level that can see it.
The rule the studio settled on is short. A defect is not closed by the repair. It is closed by whatever would have caught it, installed in the same change as the repair, and proved by putting the bug back and watching the check go red before restoring the fix.
The second half of that sentence is the half people skip, and skipping it is how a codebase fills up with reassuring green checks that have never once failed. A check that has never been red has never been tested. It reads as coverage to the next person and it is decoration.
Where the check goes matters as much as whether it exists. The cheapest level that can actually see the defect, and no higher, because every level up is slower and easier to skip.
Cheapest means earliest and most automatic. Best of all is making the mistake impossible to express, so it becomes a compile error rather than a bug. Failing that, a rule the type checker or the linter enforces. Failing that, a test on the property that broke rather than on the line that was edited. Then a step in the pre-commit gate, for things a test cannot say. A person promising to remember is the bottom of that ladder, taken only when nothing above it can see the defect, and it is named out loud as the weak option when it is used.
Written that way, the checks stop being generic. They are a list of the specific things that have already gone wrong here, each one converted into something that cannot go wrong again in silence. One keeps a single sentence identical in the four places it is written. One pins the exact size of an old debt so it cannot grow. One walks a folder that no compiler ever opens. None of them were designed in advance; every one was paid for by a defect first.
The count, and the three of them that wait on somebody.
Eleven files hold 201 of these, and they run before anything lands. They cover the two contact endpoints, the legal pages, the privacy position, the outcome figures, the anonymity of the client pages, the site map, and the contrast of the text on the dark bands. Along with them sit five measurement scripts that check things a test cannot see, such as whether a heading is actually readable against the picture behind it.
Three of those five will not run on their own. They need a live server and a real browser, so they are run by hand, which means they get run when somebody remembers. And the pipeline that ought to make that unnecessary does not exist: this repository has exactly one automated workflow and its only job is to keep two branches in step. Nothing in it runs the type checker, the linter, the suite or a build.
So the honest position is 201 automatic checks, five manual scripts of which three genuinely need a human, and nothing whatsoever standing between a bad change and the branch except the person making it.
That last paragraph is the reason this page exists. Any studio can tell you it tests its work. The useful question is a different one: what would go wrong here without anyone noticing, and can you name it? A team that answers that with a number has a real picture of its own system. A team that answers it with the word thorough has not looked.
For a client the practical consequence is simple enough. When a system is handed over, the checks are handed over with it, and they are not a folder of aspirational tests. They are the written record of every specific way that system has already tried to break, each one proved by having been red at least once.
- Next.js
- TypeScript
- Node.js