Solo Founders Find $20K MRR in Portfolio of Small Apps

A new playbook suggests solo founders build multiple small products, not one large one. This strategy leverages reduced build costs and a power law revenue distribution.

The traditional indie hacker playbook, focused on a single product, is being challenged. Between November 2025 and April 2026, eight solo founders achieved over $20,000 in monthly recurring revenue (MRR) by adopting a portfolio strategy, building numerous small applications. This approach contrasts with the decade-old advice, shifting from a singular focus to a diversified collection of small bets.

The Economic Shift to Portfolio Products

The shift to a portfolio strategy is driven by three measurable changes since 2014. First, the build cost per product has dramatically decreased. A working SaaS application with payments that required approximately 400 hours in 2014, and 120 hours in 2020, now takes about 25 hours in 2026. This includes authentication, payment processing, and a usable user interface. Second, the cost per useful signal, measured in product attempts, has changed. In 2014, founders typically made one attempt, running it for six to twelve months. By 2026, the strategy involves ten to thirty attempts, each evaluated within 30 to 90 days. Third, the average successful attempt rate for indie SaaS products clusters around 1 in 8 to 1 in 15, with a conservative estimate of 1 in 10. Combining these factors, a founder in 2014 effectively had one shot per year. In 2026, the same effort allows for twenty shots annually. If one in ten attempts becomes a paying product, the single-shot strategy yields a paying product roughly once a decade. The twenty-shot strategy, however, results in two paying products per year on average. This is the entire economic argument for the portfolio. It is not that portfolios are inherently better; it is that the cost of an attempt fell by an order of magnitude, making a strategy of more attempts viable and often superior (dev.to, "The portfolio math. When 30 small apps beat 1 big one.", 2026-05-19).

The Power Law Revenue Distribution

A portfolio of products does not generate uniform revenue. Instead, it follows a power law distribution, meaning a few products generate the majority of income while many contribute minimal amounts. Max, one of the eight founders mentioned, reportedly earns $22,000 MRR across thirty applications. This averages to $733 per app, but this figure is misleading. The actual distribution shows significant concentration:

• App 1: 35% to 50% of MRR ($7,700 to $11,000)
• App 2: 15% to 20% of MRR ($3,300 to $4,400)
• App 3: 10% to 15% of MRR ($2,200 to $3,300)
• Apps 4-6: 5% to 8% each ($1,100 to $1,760 each)
• Apps 7-15: 1% to 3% each ($220 to $660 each)
• Apps 16+: contribute near zero, often just rounding error.

This distribution shape is consistent across portfolios of consumer or SMB SaaS products (dev.to, "The portfolio math. When 30 small apps beat 1 big one.", 2026-05-19).

Portfolio Size by Build Cost

The optimal portfolio size depends on specific product characteristics. The strategy shifts based on build cost, market, feedback cycles, and distribution.

• Single product, all-in: Recommended for high build costs, defensible moats, large addressable markets, and slow feedback cycles. This aligns with the traditional playbook.
• Portfolio of 5 to 10: Suited for medium build costs, fragmented attention, fast feedback cycles, and founders who already possess some distribution channels.
• Portfolio of 20-plus: Best for very low build costs, niche-of-niches markets, owned distribution channels, and a willingness to aggressively "kill" underperforming products.

The underlying economic model determines the appropriate strategy, moving away from a one-size-fits-all approach (dev.to, "The portfolio math. When 30 small apps beat 1 big one.", 2026-05-19).

The Kill Rule and Working Calculator

Central to the portfolio strategy's success is an explicit "kill rule" and a "working calculator." The kill rule defines the criteria for discontinuing an underperforming product, preventing founders from investing further time into ventures with low potential. While the specific rule is not detailed in the source, its existence is presented as critical for portfolio management. The working calculator is described as a tool founders can use to determine the optimal number of products for their situation and to track the key metric for deciding if a product belongs in the portfolio. This artifact aims to provide a quantitative framework for implementing the portfolio math (dev.to, "The portfolio math. When 30 small apps beat 1 big one.", 2026-05-19).

WHAT WE'D CHANGE

The portfolio math presents a compelling economic argument, but its implementation faces practical challenges not fully addressed. The claim of a 25-hour build time for a "working SaaS with payments, including auth, payments, and a usable UI" requires scrutiny. While no-code tools and AI-assisted development have reduced development time, achieving production-ready robustness, security, and ongoing maintenance for a public-facing application within 25 hours remains an aggressive target. This figure might represent initial MVP development but not the full scope of a sustainable product.

The strategy also relies heavily on "any distribution" or "owned channel" for portfolios of 5-10 or 20+ apps. For a truly solo founder starting from scratch, acquiring initial distribution for multiple niche products simultaneously can be more resource-intensive than focusing on a single product's growth. Building an "owned channel" itself requires significant time and effort, potentially negating the time savings from rapid product development. The source mentions a "kill rule" and a "working calculator" as critical components but does not provide their specifics. Without clear criteria for when to abandon a product or how to quantitatively assess its fit, founders risk falling into analysis paralysis or emotional attachment, undermining the aggressive "kill" philosophy. Furthermore, managing 5 to 30 distinct products, even small ones, demands considerable cognitive load and fragmented attention. While the source acknowledges "fragmented attention" as a condition for a 5-10 app portfolio, it doesn't detail how a solo founder effectively manages this without burnout or sacrificing quality across the portfolio. The "niche-of-niches" approach also implies a constant need for market research and validation, a time sink that can quickly add up across many products.

LANDING

The portfolio strategy offers a data-driven alternative to the single-product focus, particularly for solo founders operating in a landscape of rapidly decreasing build costs. Its success hinges on a disciplined approach to rapid iteration, aggressive product culling, and a realistic assessment of individual product viability. While the economic case is clear, founders must also account for the practicalities of managing multiple products, securing initial distribution, and rigorously applying a "kill rule" to truly capitalize on this contrarian playbook.

Pull quote: “This is the entire economic argument for the portfolio.”