Write the Tests Once, Let Them Run Forever
—Keeping code consistent (as we've written about before) is one side of a healthy codebase. The other side is verification, actually knowing, with confidence, that a change hasn't quietly broken something three pages away from the one you were editing. That's a different problem, and it needs a different kind of automation.
Three levels, not one giant test suite
The instinct a lot of teams have is to either test everything exhaustively (expensive, slow, brittle) or test nothing beyond "does it look okay" (fast, but you find out about problems from your client). We use a three-tier approach instead, each tier only running if the one before it passed:
- Smoke: does every important page actually load, with no server errors? Seconds to run, catches the catastrophic stuff immediately.
- Sanity: do the core journeys still work end to end? Someone can still submit the form, complete the checkout, log in, book the thing they came to book.
- Regression: does the site still look the way it's supposed to? Visual comparisons against a known-good baseline, catching the subtle stuff a functional test would never notice such as a layout shift, a broken responsive breakpoint, a component silently losing its styling.
Each tier is cheap to run (free but I mean in terms of compute resource and time) and each one short-circuits the next, so a smoke failure means you don't waste time waiting on a full visual regression run that was never going to matter.
Generated once, run for nothing
The genuinely useful economic point here: we get an AI assistant to write the initial test suite by exploring the actual site (the real pages, forms, and user journeys) rather than working from a spec. That's a one-off cost. After that, the tests run in a headless browser on ordinary infrastructure, with no ongoing AI usage and no per-run cost. Write once, run forever, for free.
That changes the calculation on whether testing is "worth it" for a given project. The barrier isn't an ongoing budget line, it's a single afternoon of setup.
Why this earns its keep on real projects
The clearest example we can point to (without naming names) is a recent major version upgrade on a client's transactional site, the kind with real payments and real customer accounts, where "it looks fine" absolutely does not mean "it works fine." Rather than manually retracing every user journey by hand after the upgrade, we let the existing test suite do that work. It found genuine, non-obvious breakages, the kind where an underlying platform quietly moves a piece of data from one place to another, and everything looks normal until someone actually tries to use it.
Every one of those was caught before a real customer hit it, by a suite that cost nothing to run and had already been sitting there from a previous engagement.
The bit we keep to ourselves
The specifics around how we structure the tests so that they survive a site's content actually changing day to day, how we handle the trickier parts of a real checkout flow without the whole suite becoming flaky, how we decide what's safe to test against a live-ish environment. These are exactly the kind of operational detail that took real projects for us to get it right. We're happy to talk through what it would look like for your site specifically if you'd like to get in touch.
