Jevons Paradox and the Saas Reckoning

I built something I’d been trying to find for twenty years with Claude Code, and it took less than an hour.

When I was a kid there was this game, I think it was on the Apple 2, which was basically the old arcade game Missile Command. The key was that it was a typing game, and instead of just random bombs coming to blow up the cities, it was letters, and even full words. It started with home row letters and expanded to everything, and capitals, and numbers, and full words.

I got to be a very fast typist thanks to that game. Yet, over the years I could never find a similar one. Sure there were typing games, even missile command flavored ones, but not exactly like what I remembered, and what I wanted.

So I sat down with Claude Code, and I told it what I wanted, and less than an hour later, I was playing the game.Now that’s a really simple example, but the more I’m building actually useful small hyper custom solutions for myself, the more i’m thinking about what that actually means for the future.

Counterintuitive Coal Consumption

In 1865, economist William Stanley Jevons observed that as the steam engines of the time became more efficient, coal consumption actually increased. People thought that more efficient engines would reduce the need for coal, but the opposite was true. Jevon’s Paradox (thanks to my friend Matt for reminding me of this) says that efficiency doesn’t reduce demand, it increases it. If more people can afford it, more people will use it.

If you’ve ever sat on a crowded highway you’ve also experienced it. It’s also called “Induced Demand”. People complain about traffic and demand they widen the highways, so the highways get widened, and the traffic is still there. You created more efficiency, so you got more people to use the highways. If your goal is to reduce traffic, widening highways doesn’t work.

We’re seeing that now with Software Development.

The cost and difficulty of building software is collapsing. So the number of things that people are going to build is exploding. THAT has a very specific implication for the SaaS industry.

Since computers have really become ubiquitous, mostly over the last 30 years, SaaS was built on the premise that custom software is just too expensive for most companies to build, so you’re going to accept a product that was designed for a median user. You pay for features you don’t use, you bend your workflow to fit whatever the tool does. It’s better than not having the tool.

That’s suddenly on very shaky ground.

Why Would You Pay for Someone Else's Tool?

Think about the Saas products that your company is paying for right now. How much of each product do you actually use? If you’re honest, it’s probably something like 20% to 40% of the feature set. The rest is noise to you. It’s there for someone else's use case.

Now ask yourself this: If you had a UX designer, and an Information Architect sitting with you to document exactly what you need, your ideal workflow, your logic, your inputs and outputs, and then hand it over to an AI Coding tool to build… What’s that going to cost you compared to your annual SaaS spend?

It looks like for a growing number of tools that math is starting to shake that ground. Faster and faster.

Workflow tools, Internal reporting dashboards, single-purpose analytics platforms, ops automations… these are all super exposed right now, because their only real value prop was “we already built it so you don’t have to.” That line of thinking is getting weaker by the day.

Where SaaS Still Wins

Now that doomerism has limits. Network-effect products are probably safe for now. You can’t vibe code your way out of needing to be where everyone else already is. Slack, LinkediIn, GitHub.. The product IS the network, and no custom build is going to replace that.

Also Compliance-Heavy categories are probably safe as well. HIPAA, SOC2, GDPR… SaaS vendors carry certs so you don’t have to, and for industries that are heavily regulated that’s very valuable.

Deep Integration Platforms are maybe safe, maybe not? Salesforce isn’t really selling you a CRM, they’re selling you the twenty years of integrations they’ve put into it. If the platform is part of a broader ecosystem that you’re leveraging, it has some safety. Also if everyone has it on their resume and knows how to use it, you’re probably ok for a bit.

The New Scarce Resource

The point I’m trying to make though is that code just got cheap, but design thinking didn’t.

You’re not going to win in the new environment by building fast, you’re going to win by knowing most clearly what you need, what problems you have, and what solutions are best. People who understand their workflows, their data, and their own logic so that they can actually take all that and specify it and put it into a really good prompt.

Good UX. Rigorous information architecture. Clear understandings of the problem before you put anything into Claude Code.

The thinking part, that might be a new moat.

If you’re a mid-market company still paying for five SaaS tools that you half-use, that might be worth sitting and thinking about for a minute. Also if you're not sure what you actually need from your data infrastructure, before you build anything, that's exactly what the Base12 assessment is designed to help you figure out.