What is the "ideas that cannot fail" playbook?
It is a risk-minimizing method for building software, popularized in a November 2025 Starter Story interview with Australian founder Mike, whose portfolio of small bootstrapped SaaS apps produces roughly $200K in monthly recurring revenue (MRR). The core move: don't invent new categories. Pick proven ones with weak execution, then win on design, distribution, and discipline.
MRR — monthly recurring revenue — is the predictable subscription income a software business collects each month. Mike's thesis is that most startup risk comes from guessing whether anyone wants the thing at all. Remove that guess, and the remaining work is execution: better UX, a lean team, and cash management. It reads less like a moonshot and more like an operator's checklist.
Why does "pick an idea that's been done before" reduce risk?
Because demand is the hardest thing to fake. According to the Starter Story interview, Mike's first rule is to choose categories where customers already pay to solve a problem — his apps sit in social aggregation (Curator.io), feedback and roadmaps (Frill.co), digital signage (Juno.co), and no-code onboarding (Fluke.co). None are new inventions.
New categories carry two costs at once: building the product and proving anyone wants it. Existing categories retire the second cost. The founder's remaining job is narrower and more answerable:
- Are current products winning despite weak design?
- Is there pricing room for a leaner competitor?
- Can a small team out-execute on user experience?
For operators, the lesson generalizes. When you buy or build software, the safest bets solve a problem your firm already pays to work around manually — intake, follow-ups, invoicing, records — not a novel workflow you'd have to invent demand for internally.
How does the lifetime-deal loop fund a launch?
A lifetime deal — a one-time payment for permanent access — is Mike's early funding engine. According to Starter Story, Frill.co raised roughly $30K through a private lifetime deal, using communities like Reddit, Facebook groups, and X where target customers already gather. That cash funds development and content before subscription MRR arrives.
Two rules make the loop work:
- Don't give accounts away free. Mike argues paid users — even at a modest price — engage more and give better feedback than free ones. Free accounts produce vanity usage without commitment.
- Start content immediately. Landing pages, comparison pages, and "alternative to" pages go up early, because search and AI systems need time to index and surface them. Early content compounds.
The economics stay lean: apps are grown to roughly $10K MRR, where revenue covers costs, and founders then split profits. The goal, Mike says, is bigger salaries — not big exits.
What does a portfolio model change about how you operate?
Everything about tempo. Mike runs a holding-company model — several small apps, a four-person founding team per product (front-end, back-end, design, and a product generalist), equal equity to reduce founder fallout, and no outside capital. The target is roughly $1M MRR over five years without hiring an army.
That structure only holds if each app is boring, proven, and doesn't depend on someone else's platform or API. Platform dependency is a single point of failure a lean team can't absorb. So the filter isn't just "will people pay" — it's "can this survive without a landlord."
Operators should read this as an argument for ownership and control: pick tools and bets you govern, not ones that can be switched off above your head.
What's the governance lesson for operators buying software?
Mike's playbook is disciplined precisely because a human decides each step: which category, which MVP scope, which lifetime deal, when to shift to subscriptions. Nothing runs on autopilot. That's the same standard Vantrow builds to — propose, never commit: software stages an action, a person approves it, and every decision lands on an audit trail.
The connection is direct. A "cannot fail" bet fails the moment control leaves the room:
- Autonomous tooling that acts without approval reintroduces the guesswork Mike spent the whole method removing.
- Governed software keeps the operator as the decider — proposing follow-ups, drafts, and filings, never sending them unsupervised.
De-risking a business and governing your software are the same instinct: reduce the number of things that can go wrong without a human seeing them first.