The Weekend That Changed How I Think About Software

A few weeks ago, I needed a tool that didn't exist.

I had a virtual team planning session coming up and wanted software that could actually help me facilitate it. I was looking for something to collect responses, summarize feedback using AI, and keep the group focused and on track.

I searched broadly. Planning tools. Facilitation platforms. Survey tools. Workshop software. I could have stitched together three different products and gotten maybe 60% of what I needed. The remaining 40% I'd have to figure out on the fly.

There had to be a better way.

So I did what's become a new habit when I get stuck, I opened Claude and started prompting. That first prompt turned into many over the course of the weekend.

For context, I've managed developers, data scientists, and IT teams for years, but I'm not a programmer. I can write a little HTML and some basic SQL, and I've never taken a programming course.

And yet, by the end of the weekend, I deployed a fully functional web application with real-time multi-user collaboration, an AI facilitation layer, a custom backend, and a clean, modern UI.

The app has 9,881 lines of code.

I didn't write a single one of them myself.

A New Era of Product Thinking

For those who are curious about the stack: the frontend is built with Preact, Supabase handles the database and real-time collaboration, Anthropic's API powers the AI layer, and everything is deployed on Vercel. I used Claude Code as my coding partner, with Claude Sonnet running inside the app itself.

The process didn't look like what we usually mean when we say "building software". It looked far more like product management than programming.

I described what I wanted to build. Claude Code proposed an implementation. I reviewed it, tested it, and broke it. When something worked but felt wrong, I explained why and asked for a different approach. We iterated quickly until the behaviour felt right.

AI wrote every line of code.

I made every product decision.

That distinction matters more than it might seem. I never told the system how to write the code. I told it what the product needed to do, who it was for, and why certain tradeoffs mattered. The leverage didn't come from technical engineering, it came from clarity, judgment, and taste.

This wasn't "no-code", and it wasn't traditional coding either. It was something new. I was directing software rather than writing it.

The Build-vs-Buy Calculation Has Shifted

For most organizations, building customer software has always been out of reach.

It requires developers, engineers, time, and money. These are scare resources for small and mid-sized teams. So they buy off-the-shelf tools instead, paying a premium for standardized software they end up using about 60% of.

Sound familiar?

The math no longer adds up. Customization used to be a luxury.

The app I built would have cost thousands of dollars to commission from a dev shop. It would have taken weeks to build. There would have been scoping calls, tradeoffs, change orders, and compromises baked in from day one.

Instead, I spent a weekend, about $20 on API tokens, and deployed it using mostly free infrastructure. When something didn't work the way I wanted, I changed it within the hour. When I had a new idea mid-build, I added it immediately.

That speed matters. So does the ability to iterate without permission, contracts, or the fear of sunk-costs. Customization used to be a luxury.

This approach won't replace everything. Complex enterprise platforms, regulated environments, and security-critical systems still require traditional engineering rigor. That hasn't changed.

But for lightweight internal tools, nice workflows, data pipelines, and facilitation apps, the build-vs-buy calculus has fundamentally shifted. The constraint is no longer access to developers. It's clarity about the problem you're trying to solve.

The Moat is Moving

I've had paid SaaS subscriptions for years. With only a few exceptions, I've almost always felt the same low-grade frustration. Too many features I don't need, missing the few that I do.

Still, I keep paying. Not because I love the product, but because replacing it feels harder than tolerating it. And when I finally decide to cancel, I'm usually too late. The subscription has already auto-renewed, and I'm locked in for another year.

Again, does this sound familiar?

I'm going to start looking at these subscriptions differently.

If the core value of a software product is "it solves a specific workflow problem," that moat is eroding. Not entirely gone, there's still value in polished, well-maintained, supported software that can scale. But the era of charging $200 per month for a niche tool, because the only alternative is to "hire a developer," is coming to an end.

The leverage has shifted.

The software businesses that win next won't just package workflows. They'll provide access to proprietary data, benefit from strong data network effects, offer deep integrations, and cultivate real communities around their products.

In a world where software can be assembled on demand, other skills will end up becoming the moat.

When Taste Becomes the Bottleneck

The skills I leaned on to build my planning app weren't technical in the traditional sense. They were judgment, product thinking, and the ability to clearly describe what I wanted.

I didn't need to design a database schema from scratch.
I didn't need to understand the nuances of asynchronous JavaScript.

What became obvious very quickly is that some technical skills are becoming less scarce, and therefore less differentiating.

So if those skills are losing value, what's gaining value?

Taste.

The ability to evaluate options, recognize quality, and make good decisions is becoming the new bottleneck. AI can generate dozens of plausible implementations. What it can't do, at least not well, is decide which one fits the problem, the context, and the people using it.

That's a very different profile than the traditional "junior developer." The advantage shifts toward people with good judgment, strong domain understanding, and enough technical literacy to direct AI effectively.

These are builders who don't just ask "does this work?"
They ask "is this the right thing to build?"
They ask "how does this make the user feel?"

To borrow a phrase from Don Norman, author of The Design of Everyday Things, engineers are trained to think logically, but human behaviour is anything but logical.

Tomorrow's leaders may not be narrow specialists. They may be generalists who can combine multiple domains (product, operations, data, design) with AI as a force multiplier.

Having good taste, may be the next differentiator.

Practical Takeaways

After building the milestone planning app, a few things are now very clear to me.

First, the threshold for building custom software has dropped dramatically. If you're paying for tools that only partially fit your workflows, it's now reasonable to ask whether building something lightweight in-house is cheaper, faster, and more flexible.

Second, the people best suited to lead this kind of work aren't necessarily your most technical employees. They're the ones who understand the problem deeply, communicate clearly, and can make good decisions as a product takes shape.

Third, AI shouldn't be treated as a productivity add-on. It's a capability shift. Organizations that approach it as "faster work" will see incremental gains. The ones that treat it as "new things we can now do ourselves" will create structural advantages.

The software I needed didn't exist, so I made it.

That's something I didn't think was possible 12-months ago.