Micro SaaS: test the “software is dead” claim

Why it matters

A micro SaaS is a narrowly focused subscription software business, usually run by a small team. For anyone building one, the claim that software is dead creates an awkward temptation: rebuild everything immediately, or conclude that building is pointless. Neither decision follows from a screenshot of declining search traffic.

Greg Isenberg’s discussion makes a useful case for staying in the game. His central argument is that easier software creation shifts the advantage toward distribution, specialized knowledge, data, and customer relationships. I agree with the direction. I am less convinced by the implication that becoming a media business is the necessary answer for every founder.

My starting point would be diagnosis. A business can lose its acquisition channel while remaining valuable to existing customers. It can also keep attracting signups while becoming easy to replace. Those situations look similar on a revenue chart, but require different work. The practical addition here is a way to separate them before committing to a rebuild.

Key points

• 05:13 The Bannerbear example begins with reported declines in Google referrals. That is evidence about an acquisition channel, not enough information to establish that customers no longer need the underlying service.
• 10:24 Greg highlights specialized products and systems people do not want to maintain themselves. The useful implication is to examine the ongoing operational burden after an impressive demo: upkeep, integrations, support, and dependable execution.
• 12:05 His argument about code losing its exclusive advantage challenges developers to broaden their capabilities. Technical execution still matters, but access to buyers and understanding their workflow deserve explicit attention.
• 25:38 Attention and affinity provide different tests for distribution. Content can earn a large audience without creating enough confidence for someone to connect business data, change a workflow, or purchase a subscription.
• 27:19 The answer about learning to code preserves a role for technical literacy. Generating an application does not automatically equip its owner to assess architecture, security, or the cost of maintaining it.
• 35:17 The advice to emphasize outcomes offers a practical positioning test. Buyers should recognize a job getting done before they have to understand the technology responsible for doing it.
• 53:25 The discussion about going deep on one product is a useful check on portfolio enthusiasm. Demonstrating repeatable value for one identifiable customer group should precede multiplying products and support obligations.
• 1:00:40 Greg explains building around agents completing tasks rather than humans navigating every screen. That changes the unit of product design from a sequence of clicks to a completed operation, including its exceptions.
• 1:13:25 Starting with a service and having agents help fulfill it can expose the messy parts of delivery. Those exceptions are valuable product research when their frequency and handling costs are recorded.
• 1:21:35 The answer about operating at a loss puts delivery economics back into the conversation. Expected improvements in model pricing remain an external assumption, rather than a substitute for understanding current costs.

How to apply

Diagnose your micro SaaS before rebuilding it

Compare equivalent periods, such as the most recent 28 days against the previous 28. Track visits by source, signups, the first useful result, paid conversions, and cancellations. Check for pricing changes, campaign changes, and seasonal effects. Small customer counts can make percentage movements look more dramatic than the underlying evidence warrants.

| What you observe | Working hypothesis | What to inspect next | | --- | --- | --- | | Traffic falls; conversion and renewals hold | Acquisition has weakened | Entry pages and referral sources | | Signups continue; few users complete a task | Expectations or onboarding are failing | Abandoned sessions and user interviews | | Existing customers cancel and demonstrate an AI replacement | The product may be getting substituted | The same end-to-end task in both options | | Usage rises; contribution falls | Delivery costs are growing | Model consumption, support, and rework |

Treat these as directions for investigation. They are not causal conclusions. The PostHog pricing page describes a free allowance and usage-based billing, though a clean export may be sufficient for your first pass.

Benchmark the complete customer job

Pick a task customers already pay you to complete. For a marketing asset generator, comparing two attractive images would miss much of the job. Include receiving source data, applying brand rules, producing variations, correcting failures, and delivering the files where they belong.

Take twenty representative historical cases, replacing sensitive data where appropriate. Run the same cases through your product and a plausible AI alternative. Define an acceptable result beforehand, then record elapsed time, human corrections, and failures.

If the alternative consistently produces equivalent results with less effort and expense, you have evidence worth acting on. If it requires someone to move data and repair every output, investigate whether your customers value avoiding that work. Reliability and convenience can be valuable, but their value needs customer evidence.

Put a price on the founder’s time

Consider a hypothetical $49 subscription. Suppose model usage costs $5, infrastructure and payment processing cost $3, and support labor costs $10 per customer per month. That leaves $31, roughly 63%, before taxes, acquisition, and fixed expenses. It is a contribution toward running the business, not net profit.

Double model usage and support time. Does the subscription still make sense? The answer can inform usage limits, workflow improvements, volume pricing, or a narrower customer profile. Include your own support time even if no cash salary leaves the account that month.

This is where I would challenge both sides of the video’s debate. Neither a promised return to extraordinary margins nor an inevitable collapse in profitability tells you much about the economics of your particular workflow.

Choose a distribution experiment you can sustain

I would not automatically turn every software founder into a full-time creator. Start with one place where actual buyers already gather: a specialist community, an industry partner, or a focused technical publication.

Demonstrate a complete customer task, including the inputs and limitations. Attribute resulting conversations to their source, then track how many people reach a useful result and become paying customers. Reach tells you whether a message traveled. Continued use tells you whether the product earned a place in someone’s work.

A partner with a small, relevant audience may deserve a test before a commitment to publishing daily videos. Select the channel based on buyer access and measurable response.

End the investigation with one bounded change

Two weeks can be enough to organize the numbers, interview recent users, and run the task comparison. It cannot establish long-term retention or prove a universal business thesis.

Use the evidence to choose one intervention: repair acquisition, simplify initial setup, reduce delivery costs, or automate a specific operational step. If that step involves an agent, define spending limits, action logs, and approval before irreversible operations. The decision becomes concrete: which part of the customer’s job can your business keep delivering well enough to justify its subscription?