Failsafe

I'd shipped several products by this point and had no real visibility on whether any of them were working safely or doing what I intended. There was no proper error reporting, no obvious route for a user to tell me something had broken, and nothing watching for security problems.

Underneath that sits a bigger issue with building this way: when you're vibe-coding with AI, you don't know what vulnerabilities you've introduced, because you didn't write the code line by line and you're not going to read all of it. I put the idea into a WhatsApp group of people building the same way I was, and every single one of them said they'd use it, which told me the problem wasn't just mine.

Two things run continuously. The first is security scanning, looking for vulnerabilities someone could use to reach information they shouldn't, or to get round the way something is meant to be used. The second is golden paths: it reads the codebase to establish what the intended user journeys are, then interviews whoever built it to confirm what those journeys should actually be, and audits against both on an ongoing basis. Every thirty minutes it publishes a report to a dashboard.

On top of that I built a skill that any Claude Code user can add, which spins up a local dashboard showing health across all of their sites and surfaces anything that needs dealing with.

What surprised me was how straightforward it is to build systems that run quietly in the background and publish to a local view, with no requirement for that view to live on a published website at all. That opened up a way of thinking I hadn't had before, about private infrastructure that exists only for me and runs while I'm working on something else, and it's shaped a fair amount of what I've built since.

I never shared it with the WhatsApp group. I used them to validate the problem, built the thing, and kept it, which I'm comfortable with: it's infrastructure for everything else I make rather than a product I was ever going to take to market, and I have no interest in running a security monitoring product.

There's a whole category of build that isn't a product and was never meant to become one, and private infrastructure that serves you is worth making on its own terms without owing anyone a distribution strategy. Recognising that changed what I think I'm doing when I build.

The central problem is that people don't know what they don't know, and it conceals itself. Even with Failsafe running, it monitored things I hadn't previously thought about, but it couldn't show me the gaps it wasn't looking for in the first place, so the reassurance it gave me was real but bounded in a way that's easy to forget.

At enterprise scale the shape is the same, only larger. The tidy answer is infrastructure first. The more common pattern, in any organisation adopting these tools, is that people start using them before every control is in place, so the real question is how quickly and deliberately the controls catch up. There is likely a point in most adoption programmes, once a tool has been released for widespread use, where the priority shifts from a heavy focus on use cases to making sure the right controls are in place for the demand that follows.