Micro-SaaS Is Dead. Service with a Software Replaces It.

Adrien Gonin is a designer, and he opens with a tool he built in a few hours that does its job better than things people pay for, and that he will never sell. The name he gives the pattern is Service with a Software: private tools that never get sold, built to make one service impossible to compete with.

The instrument

The chain of events is worth keeping because the argument rests on it. AI prototyping tools like Magic Patterns and Figma Make all ignore your design system unless you put serious effort into making them merely adequate, so he went around them. He reimplemented his 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 what Figma gives him.

That created a second, duller problem. Mailing an HTML file is painful and putting a page on the open web is trivial, but enterprise work needs discretion: password protection, sandboxing, a clean link. The tools that offer that put it behind a paywall. So he built his own sharing platform on a VPS. Upload, sandbox, password. A few hours.

As a product it is nothing: a file host with a password field, cloneable in a weekend. Inside his client work it is matched to one company's design system, one company's security constraints, one workflow. Generalizing it in order to sell it would 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."

He names the older, inverted version too. Software with a Service is the SEO consultant who pays for the expensive Ahrefs seat and sells advice bundled with access to the data: software is the product and the human is the wrapper. His flip makes the service the product and private, overfit software the thing that makes it unrepeatable.

Why the standalone tool is trapped

Gonin's claim is that AI squeezes small standalone software from both ends, and that only one end gets discussed.

Supply is the obvious one: whatever niche tool you're sketching this week, a thousand people can prompt a working version by Sunday night. The to-do app that every developer ships as a first project, earnest and indistinguishable from ten thousand others, is now the shape of the entire micro-SaaS territory.

The demand side is the more interesting observation. His own subscriptions are dissolving — no prototyping SaaS, no sharing SaaS, and he left Webflow for a bare VPS and Cloudflare because building the thing became faster than configuring somebody else's abstraction of it. He reports technical people generally making the same trade: cancel ten small subscriptions, keep the one heavy platform that makes the building possible. Spend consolidates into a few dense layers and the long tail above them goes home-cooked, built for an audience of one.

So the $15-a-month generalized niche tool has nobody who needs to buy it and everybody able to build it.

Where the value moved

One layer over, to the context around the artifact. Gonin's post-mortem of micro-SaaS is that the build was always the easy part and 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 what's left is entirely the hard part — and the people best positioned for the hard part were never founders starting from zero. Service workers already hold the relationship, the real problem, and a live loop of trust and feedback. Software deployed inside that context needs no funnel, no onboarding, no churn dashboard.

That reverses the standard ladder of ambition, where you do the work, standardize it, productize it, and scale it. When anyone can produce the artifact, the defensible thing is the fit.

Overfitting as a feature

The objection is obvious: handcrafting a bespoke system per client is the artisan trap, and it doesn't scale. Gonin's answer is that what changed is which layer you standardize. A product has to fit a thousand customers approximately, which guarantees it fits none of them exactly, and overfitting to one customer used to be malpractice. Now you standardize the meta-workflow — the skills, prompts, pipelines, the process that produces software — and let the output overfit freely. The process compounds; the output never has to generalize.

His illustrations scale up from the prototype host. The SEO practitioner whose crawler is tuned to one client's platform and to the exact signals that client's business depends on. The niche recruiter whose sourcing engine runs on a corpus built across years of placements. In both, "the expertise isn't sitting next to the software. It's compiled into it."

His explanation for why almost nobody occupies this position is that the people capable of it are pointed elsewhere. Most developers find the system more interesting than the outcome, so engineering energy flows into polished little tools nobody asked for while the service version of the same expertise goes unbuilt because it smells like consulting. His reframe is that the puzzle was never the CRUD app — it's the whole delivery system with your own judgment, knowledge, and taste as components of it.

He is not telling anyone to stop building small tools, only to stop calling them businesses. Build them as personal infrastructure that compounds your workflow, as public proof of how you think, or as gifts to a community, since a tool people actually use is a more credible signal than anything you could say about yourself. "The code was never the moat. It's the vector."

What the argument doesn't cover

The piece is a positioning essay from one designer's practice with no revenue figures behind it, and it inherits a bootstrapping problem it doesn't acknowledge. Every advantage it describes — the relationship, the corpus built across years, the live feedback loop — presupposes an existing client base. For someone without one, "get clients first" is not an easier starting condition than the distribution problem it replaces; it's the same problem relocated and made less legible.

There is also a limit to how far the escape from the artisan trap goes. Overfit output plus a standardized process gets you repeatability at the artifact layer, but the practitioner stays the bottleneck: the work is unsellable and non-transferable by design, so the business does not survive its owner and cannot be staffed without rebuilding the judgment in someone else's head. Gonin would probably accept that as the price.

Nearby in the vault: disposable-code on how cheap code lowers the threshold for building rather than buying, which is the demand-side mechanism he's describing from the buyer's seat. ai-native-tiers and elena-verna-job-2027 cover the solo-operator career framing this belongs to. best-polished-version-strategy is the competing answer for when a product still makes sense — building the last version of a known category, which only works if the incumbent is bad enough to overcome switching cost. purpose-driven-vs-system-driven-design names the same misallocation Gonin diagnoses, where builders find the system more interesting than the outcome while users buy the outcome. And oss-sustainability is the adjacent question for people giving the tools away instead.