I built a SaaS in a few hours. It does its job better than tools people pay real money for. And I will never sell it.

Every instinct trained into technical people over the past decade says that’s leaving value on the table. Landing page, Stripe, launch post, recurring revenue. That script is practically a religion in indie circles.

I think that script is now obsolete. What I’m doing instead, I call Service with a Software: private tools that never get sold, built to make one service impossible to compete with. I’d bet it’s the strongest position left for independent builders. Here’s why, starting with the tool I’ll never sell.

The instrument

I’m a designer, and I got tired of AI prototyping tools. Magic Patterns, Figma Make, all of them share the same flaw: they ignore your design system unless you invest serious effort making them merely adequate. So I went around them. I replicated our design system in Tailwind classes, wrote a Claude Code skill around it, and started generating full HTML prototypes. Interactive, on-system by default, higher fidelity than anything Figma gives me.

That created a boring second problem: sharing. Mailing an HTML file is painful. Putting a page on the open web is trivial, but enterprise work needs discretion: password protection, sandboxing, a clean link. The tools offering that put it behind a paywall, when they offer it at all. So I built my own sharing platform on my VPS. Upload, sandbox, password. A few hours.

Here’s why it will never have a pricing page. As a product, it’s nothing: a file host with a password field, cloneable in a weekend. Inside my client work, it’s something no product can be: an experience matched to one company’s design system, one company’s security constraints, one workflow. The moment I generalize it to sell it, I sand off exactly the fit that makes it valuable. The software isn’t the product. It’s an instrument that makes the service around it impossible to compare.

That’s the whole model in miniature. You may know the older cousin, Software with a Service: the SEO consultant who pays for the expensive Ahrefs seat and sells you advice bundled with access to the data. Software is the product, the human is the wrapper. Service with a Software is that model flipped. The service is the product, and private, overfit software is what makes it unrepeatable.

A cute inversion, sure. But why would this be the model now, when for twenty years the smart move was the opposite: escape the service, become the product?

The squeeze

Because AI is crushing small standalone software from both ends at once, and only one end gets talked about.

The visible end is supply. Whatever niche tool you’re sketching this week, a thousand people can prompt a working version by Sunday night. Remember the to-do app every developer ships as a first project, earnest and indistinguishable from ten thousand others? That dynamic now covers the entire micro-SaaS territory.

The quieter end is stranger: the customers are dissolving. I’ve stopped subscribing to a whole layer of tools. No prototyping SaaS, no sharing SaaS. I left no-code site builders like Webflow for a bare VPS and Cloudflare, because building the thing myself became faster than configuring someone else’s abstraction of it. Technical people everywhere are running the same trade: cancel ten small subscriptions, keep the one heavy platform that makes all the building possible. Spend is consolidating into a few dense layers, and the long tail above them is going home-cooked, built for an audience of one and unashamed of it.

So the $15-a-month generalized niche tool is trapped. Nobody needs to buy it, and everybody can build it. But that raises the real question: if the software artifact itself is now nearly worthless, where did the value actually go?

Where the value went

Not far. It moved one layer over, from the artifact to the context around it.

The honest post-mortem of most micro-SaaS was always the same: the build was the easy part. The projects died on distribution, on trust, on being one of forty tabs a tired buyer never reopened. AI made the easy part free, so the game is now entirely the hard part. And the people best positioned for the hard part were never founders starting from zero. They’re the people doing service work, who already hold what founders spend years failing to acquire: a relationship, a real problem, a live loop of trust and feedback. Software deployed inside that context needs no funnel, no onboarding, no churn dashboard. It lands where value already flows.

That’s why the old ladder of ambition, do the work, standardize it, productize it, scale it, has quietly reversed. When anyone can produce the artifact, the defensible thing is the fit.

Which sounds nice until you hit the obvious objection: custom work is exactly what we all learned not to do. Handcrafting a bespoke system per client is the artisan trap. It doesn’t scale. Right?

Overfitting is a feature now

It didn’t scale, past tense. What changed is which layer you standardize.

A product must fit a thousand customers approximately, which guarantees it fits none of them exactly. Overfitting to one customer was product malpractice. But AI moved the reusable layer up a level: you standardize the meta-workflow, the skills, the prompts, the pipelines, the process that produces software, and let everything that comes out of it overfit freely. The process compounds. The output doesn’t have to generalize at all. For the energy it once took to build one generic product, you can now emit a one-of-a-kind system per client.

That’s a genuinely new position on the map. Not artisan, all fit and no leverage. Not product, all leverage and no fit. Both, on different layers. My prototype platform is the small version. The bigger version is the SEO practitioner whose crawler is tuned to one client’s platform and the exact signals their business depends on, or the niche recruiter whose sourcing engine runs on a corpus built across years of placements. In each case the expertise isn’t sitting next to the software. It’s compiled into it.

If this position is so strong, one question remains: why is almost nobody who could occupy it actually doing so?

The mispointed puzzle

Because the people most capable of it are wired to look elsewhere. Most developers find the system more interesting than the outcome. Solving the puzzle is the reward; everything around delivery feels like overhead. So enormous engineering energy keeps flowing into polished little tools nobody asked for, while the service version of the same expertise, the one people are actively starving for, goes unbuilt because it smells like consulting.

But the puzzle was never the CRUD app. The puzzle is the whole delivery system, with your own expertise as one of its components. Treat human judgment, knowledge, and taste as cogs in one larger machine for producing outcomes, and service work stops being the opposite of engineering. It becomes the most interesting systems design problem available, and the one where a background in automation and logic is an unfair advantage instead of a commodity.

What small software is still for

None of this means stop building small tools. It means stop calling them businesses.

Build them as personal infrastructure that compounds your own workflow, worth it even if nobody else ever logs in. Build them in public as proof of how you think. Build them as gifts to a community, the way the best open source has always worked, because a tool people actually use is a more credible signal than anything you could say about yourself. What no longer works, absent proprietary data or an existing audience, is the standalone venture. That’s the weekend project a thousand strangers are shipping alongside you.

The code was never the moat. It’s the vector. What can’t be cloned by a weekend of prompting is the accumulated corpus, the fit with one specific world, and the trust attached to work only you deliver that way.

Everyone can build software now. That’s exactly why the interesting question stopped being what you can build, and became where you point it.