Five years on one app, then 30 apps in ten months. The portfolio pivot that reached $22,000/month

Dollar figures in this article include a rough conversion at ¥150 to $1.

‘Five years on one’ versus ‘thirty apps in ten months.’ Same developer, same skills, two different outcomes. Max Artemov, an iOS engineer with 8 years of experience, spent over five years trying to grow his first app, a calorie-counting app, without success. In February 2025 he changed course, switching from a single-project model to a portfolio model. As of an Indie Hackers interview published December 10, 2025, his 30+ apps were generating a combined $22,000 MRR.

The lesson worth digging into here isn’t the blunt takeaway of ‘ship a lot and something hits.’ It’s why reversing the very order of how apps get built is what moved the numbers.

The disclosed numbers

Note: the ‘$730 average per app’ figure is simply the total divided by the app count. The actual distribution isn’t disclosed. Given his own statement that ‘most apps fade after their initial boost,’ it’s natural to assume revenue is concentrated in a handful of top performers, but the breakdown isn’t public.

What he’s building

He’s building a portfolio of small Flutter apps. Each app packs in a single feature that solves one specific user problem, ‘one core function.’ The backend runs on Firebase, and monetization is through ads rather than subscriptions. That configuration deliberately skips the heavy work of paywall design, purchase-flow optimization, and price testing from the start.

Support isn’t all on him either. User feedback and review responses go to the publisher, and only actual bugs reach him. Running 30 apps solo requires a design that keeps operational fixed costs low from the outset.

The moment the tide turned

The turning point is clear. In February 2025 he watched a YouTube video by Adam Lyttle arguing that, rather than focusing on a single project, you should build a portfolio of multiple apps. He describes it as having ‘completely changed my understanding of mobile apps.’

The gap between before and after is extreme. Before the switch: over five years on one app, zero results. After: 30+ apps in ten months, reaching $22,000 combined MRR. The skills and the person invested didn’t change. What changed was purely how time got allocated.

There’s a second point where the numbers moved: learning ASO. He states directly that after learning it, ‘impressions, downloads, and revenue increased by 50%’, within the volume framework, this is what raised the hit rate of individual shots. The turning point was ‘shifting to a portfolio’. The amplifier was ASO. It’s a two-stage structure.

Breaking down why it worked

On the surface it looks like ‘shipped a lot and something hit.’ But the mechanism at work is more specific than that.

First, reversing the build order. The old pattern was: build the app you want to build, then think about acquisition afterward. After the pivot, it became: find keywords in the App Store with popularity above 20 and difficulty below 60 → design the app around that keyword → use it in the title, subtitle, and description. Because demand is confirmed before starting, the structural accident of pouring five years into a zero-demand area becomes much less likely. Search keywords are, quite literally, a map of where people are already looking.

Second, using the App Store’s initial boost as a free validation tool. For a few days right after launch, the App Store gives new apps a degree of exposure. Most apps then fall to 10–50 downloads a week and fade. He treats this as a pass/fail line, doesn’t need to sustain the peak, just needs to stabilize without a sharp drop-off to be considered promising. Rather than cutting mechanically at some download-count threshold, he says he watches each app’s post-boost behavior individually. What he’s measuring is whether demand exists, using exposure the platform hands out for free, before spending anything on ads.

Third, designing emotional attachment out of the process. ‘Let the users decide, through their actual behavior, whether an app sinks or swims, while I’m already building the next one,’ he says. ‘Ship it and let it live or die based on real user response.’ A developer with only one app tends to have their exit decisions warped, because abandoning that one app means the end of the business. With 30, one failure is just a single statistical data point. The five years of attachment, in this reading, were caused not by a lack of skill but by a structure with only one option.

Fourth, cutting over-engineering. He used to spend time on SOLID principles and idealized architecture. Now it’s ‘only what the core function needs.’ His advice is blunt: ‘Don’t be afraid to ship. Don’t waste time polishing or adding one more killer feature. Get one feature working without bugs, and ship it.’

What isn’t working, and the risks

As a starting premise, the failure period here is the longer one. Of 8 years in his career, more than five went into one app that never produced results. He’d picked a saturated category (calorie counting), padded it with features, and obsessed over architecture. The volume strategy is the mirror image of that lesson, not something he arrived at as the right answer from the start.

The current model has weaknesses of its own. Revenue is concentrated in ads, and acquisition depends almost entirely on the App Store algorithm. If the conditions that make ASO work change, all 30 apps get hit at once. He’s aware of this risk himself, and says he plans to build several SaaS products in 2026 to diversify income. His own read is that portfolio diversification should be measured not by ‘number of apps’ but by ‘variety of what you depend on.’

Also, the majority of apps are operated on the assumption that they won’t survive past their initial boost. The 30-app count reads less as proof of success and more as the volume needed given a baked-in expectation of low survival rates.

How far does this transfer

What’s easy to reproduce is the decision-making rules: set thresholds on keyword popularity and difficulty before starting. Decide whether to continue or abandon based on post-release behavior. Ship with a single focused feature. None of these require special assets. ASO tools are generally available too.

Still, there are conditions that don’t transfer directly. Eight years of iOS development experience means his per-app development cost is dramatically lower than most people’s. Fluency with the Flutter-plus-Firebase combination for cross-platform development is also a prerequisite. Being able to hand support and review responses off to a publisher isn’t a setup everyone can arrange immediately either. If your development speed is half of his, the same ten months yields 15 apps, and given the skewed revenue distribution toward the top few, the result likely won’t scale proportionally.

Beyond that, this method doesn’t pair well with a strategy of building ‘one app that goes deep.’ Stripping features to ship volume, monetized through ads, doesn’t translate easily to a business built on higher-priced products or long-term customer relationships. Volume here isn’t the goal. It functions as a cheap way to search for where demand actually is. That’s the reading that best fits this case.

Related reading

• Photo AI: how Pieter Levels built a solo product reaching $100K/month
• The revenue structure of an individual publisher who built 24 Kindle books