Service with a Software: Why the Best Tools Will Never Be Sold

The rise of AI has made standalone micro-SaaS businesses vulnerable to rapid replication and declining customer demand. The author suggests shifting toward 'Service with a Software,' where builders use private, bespoke tools to enhance their professional services. This approach prioritizes deep context and client trust over generic, scalable products.

Key Points

• AI has commoditized micro-SaaS by making it easy for anyone to prompt a working version of a niche tool by a weekend.
• The 'Service with a Software' model flips the traditional approach by making the service the product and the private software the instrument that enhances it.
• Value has shifted from the software artifact itself to the context, trust, and specific fit surrounding its implementation.
• Overfitting software to a single client's needs is no longer a failure of scale but a competitive advantage when the building process is standardized.
• Small software should be treated as personal infrastructure or a reputation signal rather than a standalone business venture.

Sentiment

The community is cautiously interested but skeptical of the article's strongest claims. Commenters broadly agree that AI changes the economics of small software and increases the value of domain-specific service delivery, but they push back hard on the idea that SaaS or micro-SaaS broadly disappears. The dominant sentiment is qualified agreement: the thesis is useful if interpreted as a shift in where value accrues, not as a literal replacement of software products.

In Agreement

• AI-assisted development makes small, highly tailored tools much easier to create, which weakens the value of generic micro-SaaS products aimed at broad niches.
• Domain experts and teams with strong internal knowledge can replace vendor tools when control, integration, and exact workflow fit matter more than a polished general product.
• The defensible part of future software businesses may be the surrounding service, trust, relationship, and business-process understanding rather than the code itself.
• Some commenters expect personal users, startups, and software-capable organizations to move away from rigid SaaS subscriptions toward custom or internal tools when the costs and flexibility tradeoffs favor building.
• The article's framing fits a broader bundling and unbundling pattern, where AI accelerates tool creation but makes workflow knowledge and business strategy more important.

Opposed

• Building a tool for oneself is much easier than building and supporting software for other users, and most people do not want to spend time specifying or maintaining custom tools.
• SaaS still provides reliability, security, compliance, ongoing maintenance, support, and product expertise that prompt-built or bespoke tools may lack.
• Internal tools can create incidents, feature requests, operational burden, and distraction from a company's core business even if AI reduces initial development time.
• The service-with-software model can look like consulting with custom code attached, which is not automatically easier or more scalable than selling a product.
• Many SaaS businesses already started from service-heavy, customer-specific work, so the article may overstate the novelty of the model and the death of micro-SaaS.