The Product of One

Most of the SaaS you pay for is a compromise you agreed to because building your own was too expensive. That’s the whole deal. You had a specific way you wanted to work, no time or budget to build a tool for it, so you rented someone else’s idea of how the work should go and adapted yourself to fit. We did this so many times it started to feel like the natural order of software. It wasn’t. It was a workaround, and the workaround is expiring.

SaaS won the last fifteen years by pooling everyone onto the same tool. Building software was slow and costly, so the only way to make it pay was to sell one product to thousands of customers. That math forces a generic product. It has to serve the average, which means it serves almost nobody exactly. Every feature is a vote across a million users you’ll never meet. What you actually buy is a frozen opinion about how your work should happen, and your job is to bend until you fit it.

For anyone technical, that bargain is breaking. The cost of building collapsed. A founder or engineer who feels the friction of a tool that’s 80% right can now build the version that’s 100% right for how they actually work, in an afternoon instead of a quarter. So they will. Not a generic product adopted by many, but a product of one. Or a product for a team of five, shaped to exactly how those five people operate.

This is the part the industry hasn’t fully priced in. The customers most capable of leaving are the ones SaaS depends on most. Technical teams are the early adopters, the case studies, the loud advocates, and they’re the first to realize they can just build the thing. When the people who set the trend start running on software they made for themselves, the generic tool loses its center of gravity.

SaaS doesn’t die from this. It splits. The horizontal, do-everything-for-everyone workflow tools are the most exposed, because their entire value was being good enough for the average and cheaper than building. Both halves of that just changed. What survives is the software you genuinely don’t want to own. Infrastructure you’d be insane to run yourself, anything wrapped in enough compliance and liability that owning it is a job in itself, products whose value is the network on the other side rather than the features, the real data moats you can’t recreate. Those aren’t compromises, they’re things that are genuinely hard, and hard doesn’t get commoditized by a cheaper afternoon.

I want to be honest about the edge of this. It’s the technical crowd that moves first, and plenty of companies will keep buying SaaS for years because they can’t or won’t build. The non-technical world isn’t flipping overnight. But the line of who counts as technical enough to build their own keeps moving, and it moves in one direction. Every model release, every better tool, pulls more people across it. The pool of customers content to rent the average shrinks a little every quarter, and the pool willing to build exactly what they want grows.

What’s strange is that this is software swinging back to where it started. Companies used to grow their own tools in-house because there was no other option. Then SaaS showed up and convinced everyone it was smarter to rent than to build, and for a long time it was. Now the cost that made renting smart is gone, and building your own is back on the table, except this time it’s fast and cheap instead of slow and expensive.

The next decade of software won’t be one tool that millions adapt to. It’ll be millions of tools, each shaped to one person or one team, most of them never sold to anyone. The interesting question stops being what we should build for the market. It becomes what we should build for us, and only sometimes, after the fact, whether it’s good enough that other people should have it too.

The product of one was always the thing people actually wanted. They just couldn’t afford to make it. Now they can.