the prototype is the business case

I’ve spent most of my career spotting things that are broken.

Not catastrophically broken. The quiet kind. Processes that work but waste hours. Systems that don’t talk to each other. Data that exists but nobody can find. Workflows that everyone knows are painful but nobody has budget to fix.

The frustrating part was never seeing the problem. It was proving the solution is worth building. You’d need to write a business case, find budget, get development resources, wait months, all before anyone could see whether the idea actually worked.

So to ease my frustration, I have been building things by myself, on my own time, using AI-augmented development - not for work, but to prove to myself the ideas are real and they’re worth doing.

Not theoretical prototypes. Real applications. Production PWAs. Automation systems. Tools that actual people use. I design the system, set the quality bar, and use multi-agent AI workflows to handle implementation, prototyping ideas in days that would have taken months to even get approved.

The hardest part of fixing broken processes is never building the solution. It’s getting permission to try and that people don’t always know what they need until they can see it.

The number of times someone has told me what they want. We build it. Then they look at it and realise that the new approach has rendered old processes moot, or highlighted requirements they could never have articulated until something real was in front of them.

That used to be terrifying. Scope creep. Budget overrun. “We built the wrong thing.”

I’d argue that now it’s the whole point.

When you can prototype a working solution in days instead of months, that moment of “oh wait, actually what I really need is…” isn’t a disaster at all, it’s just another step in the discovery. You iterate, you reshape, you learn what the real problem is, all before a single line of production code gets written. It’s basically white-boarding solutions in real time.

The prototype becomes the business case AND the requirements gathering. The risk disappears. Suddenly conversations with stakeholders go from “trust me, this would work” to “look, try it, and tell me if anything is missing.”

If you’re someone who sees inefficiency everywhere but has been told “we don’t have the resources”, guess what? The resources exist now. The barrier isn’t technical anymore. It’s knowing how to use the tools.

The most valuable thing I’ve learned in the last year hasn’t been from a class or courses, it’s been from playing around with new technology on my own time.