¥50,000 a Month, Five Years After the First Release. An Indie App's "Quietly Effective Tactics" — and the Ones That Didn't Work

Why this record is worth reading

Indie-development revenue reports carry a structural bias. Stories of reaching ¥1 million a month get shared widely, but the speed most developers actually experience, a few tens of thousands of yen a month after several years, goes unwritten and buried. The note by Dokozono (a former teacher who moved into iOS engineering) is a record that discloses that “unwritten side,” including which tactics worked and which didn’t.

Moreover, the author deliberately withholds the app’s name, genre, and download count. With the motive of self-promotion removed, the “tactics that didn’t work” are written with the same energy as the ones that did, which arguably makes the record more trustworthy as an operations log. His own summary (“I don’t think you need any super-technique to earn ¥50,000 a month”) captures the character of the piece.

Numbers and timeline

In his own words: “It’s been 5 years since I first released an app. It took about 2 years from when I decided to get serious about monetization.” That is, for roughly the first three years he barely attempted to monetize at all. On how to value ¥50,000 a month, he offers a comparison with stock investing, earning ¥50,000 a month in dividends would require roughly ¥12 million in principal. Whether five years of development is a fair substitute for that is up to the reader, but at minimum this is the conversion by which the author makes peace with his own five years.

How the ¥10,000-a-month wall was crossed

The description of the turning point is concrete. Multiple feature requests had come in from users, but he left them unaddressed for a long time. When he finally got around to acting on them, revenue of ¥10,000 a month materialized in the third month. From this the author derives a decision rule: an app receiving the same feature request from multiple people has a good chance of clearing ¥10,000 a month. The reframe: a request is, before being an improvement task, a measured data point of demand.

Tactics that worked

Placing the paywall “right after the user experiences the value.” He positioned the paywall immediately after use of the main feature and at first launch. Then inquiries began arriving saying “I’ll gladly pay, just remove the ads.” The structure, users willing to pay existed all along. Only the pathway was missing, was confirmed directly in the wording of those inquiries.

Keeping an official LINE account open as a standing contact channel. He created a state where requests “trickle in” and used them as seeds for improvement. The ¥10,000-a-month turning point above also grew out of requests this channel caught. A standing support desk, rare in indie development, paid off in both feature prioritization and reviews.

Joining the Apple Small Business Program. The program cuts the commission from 30% to 15% for developers with annual sales of $1 million or less. Simply applying multiplies take-home revenue by roughly 1.2x, for an indie developer early in monetization, the single highest ROI procedure available.

Making subscriptions the revenue backbone. His felt experience: “it stacks up more than you’d expect” and “far more stable than one-time purchases.” The property of accumulating steadily, even with ups and downs, supports not only revenue but the maintenance of motivation.

Not lowering prices to match competitors. Pricing above competitors still sold. As evidence he cites his own experience paying for a household-budget app. He subscribed without checking other apps’ prices. “Users know far less about apps than you think”, timid pricing premised on comparison shopping did not match how users actually behave.

Tactics that didn’t work (this is the valuable part)

Defaulting the purchase screen to the annual plan → no effect. The reason is clear: this app is in a low-frequency genre, “using it a few times a month is on the high side.” The appeal of an annual plan only functions for high-frequency apps. A real example of a growth-hacking staple whiffing when it doesn’t mesh with the app’s usage context.

A/B testing → no significant differences. In his words: “at this scale, I just couldn’t get statistically meaningful differences.” With the user numbers behind ¥50,000 a month, statistically valid experiments are all but impossible to run. Improvement at small scale has to run on user feedback and qualitative judgment, not data.

How persistence was engineered

He does not explain the five years of continuity with willpower. “You can’t keep going on grit alone. Human willpower is not to be trusted.” What kept it going was that external rewards began to cycle: revenue (“the experience of an idea of your own taking shape, being used, and turning into money is genuinely fun”) and user reviews. Put inversely, how fast you get the first yen and the first positive review is the lifeline of persistence.

His development policy follows the same philosophy. He abandoned over-engineering and feature-stuffing: “don’t overthink, just aim to finish the app and ship updates,” “release small, release often.” Shortening the distance to completion was itself a design for not relying on willpower.

The regrets he names

Failures are on the record too. Hesitating to introduce paid features at the start (“I should have just added payments without worrying”). Leaving received feature requests unaddressed for a long time. Suppressing prices unnecessarily out of competitor-consciousness. Common to all three is underestimating the fact that users are willing to pay. The three-pillar model of ads + subscriptions + one-time purchases is an extension of that reflection: monetize everyone thinly (ads), heavy users deeply (subscriptions), and don’t lose the subscription-averse (one-time purchase). The smaller your user base, the more it matters to have multiple monetization paths per user.

Remaining problems

Acquisition depends on in-store traffic. Social media amounts to a few TikTok videos posted and then abandoned. He concedes “I have to stop running from it,” naming as his next challenge “not just building, but figuring out how to grow awareness of this app and increase inflow.” The bottleneck past ¥50,000 a month has shifted from engineering ability to attention.

Notably, reading this alongside the education app that grew to ¥4.61 million a year reveals that indie apps which take off are decided less by tactical skill than by “choosing a high-frequency domain.” The fork in the road between that case and this one, where the annual-plan default whiffed, is exactly there.

Conditions for reproducing this — and the limits

• Easy to reproduce: joining the Small Business Program, paywalls placed right after value delivery, a standing contact channel, prioritizing received requests — all applicable today regardless of genre
• How to use the “didn’t work” record: annual-plan defaults and A/B testing are staple recommendations in growth articles, but under the condition “low-frequency app × small scale” they are nullified. For developers under the same conditions, this report saves time more directly than any success story
• Limits: with the app’s genre and download count undisclosed, “in what kind of market was this the speed?” cannot be verified. And ¥50,000 a month is not a life-changing sum — whether you treat it as a goal or a waypoint changes the strategy

Related reading

• The education app at ¥4.61 million a year, independent in 3 years — the upside tail of the same indie app development
• Bannerbear’s 12 products in 12 months of trial and error — the overseas version of advancing by killing what doesn’t work
• TypingMind’s pricing philosophy — criteria for choosing between one-time purchases and subscriptions