First revenue: 22 yen. One year and three months rebuilding 5 apps to reach 10,000 yen a month

Indie developer revenue posts often start from the 100,000-yen or 1,000,000-yen level, but before that comes “the very first yen.” A note.com post titled “From no app-development experience to earning 10,000 yen a month through indie development” is a chronological record by the author (Nosuke) of the roughly one year and three months from October 2019 to reaching 10,000 yen a month. The first revenue amount: 22 yen. What changed between then and hitting 10,000 yen a month is laid out clearly.

One year and three months of progress

The author started indie development shortly after switching to work as a web engineer, self-taught, with no prior industry experience. The only fixed cost explicitly stated is 11,800 yen a year for iOS app distribution (Apple Developer Program), and his reaction at the time is quoted verbatim: “Wait, I have to pay Apple 11,800 yen every year just to release an iOS app?!”

Why the first app didn’t sell

MusicStore Reviews grew out of a real frustration: not knowing in advance how good a domestic musical-instrument store was. The author, himself experienced with instruments, had a compelling premise, “for someone just starting an instrument, choosing the right first store matters a lot for whether they stick with it.” But the result was a flop. His own summary: “there was simply no demand for the act of ‘reviewing musical instrument stores.’”

Here, two kinds of demand that often get conflated in indie development show up clearly separated. The reader-side demand, “I want to know how good this instrument store is”, can exist even when the writer-side demand, “I want to write a review of this instrument store”, doesn’t. A user-submission-based service can’t get off the ground without the latter. The problem statement was correct, but that’s not the same thing as the service having the conditions to actually run.

His next attempt, “Sabusuku,” was an app that centrally manages subscription payments like Apple Music and Amazon Prime, aimed at preventing people from forgetting to cancel during free trial periods. The author writes: “there wasn’t a domestic app that consolidated management of subscriptions like this, so I saw an opening there,” adding, “and it was also a need of my own.” Users did trickle in gradually.

The decisive factor was in-app purchases

The moment the numbers moved can be pinpointed exactly: the end of 2020, when he decided to implement in-app purchases. Lining up before and after makes the gap unmistakable.

• Before purchases: AdMob banner ads only. First revenue was 22 yen the day after implementation. Running ads across 5 apps afterward, “it never came close to reaching 10,000 yen a month”
• After purchases: implemented in “Sabusuku” over the year-end/new-year period and released. “The effect showed up immediately, and I was able to earn 10,000 yen a month”

The author’s explanation of the ceiling on ads, in numbers, is useful here: “ad revenue is a few yen to a few dozen yen per tap, so unless thousands or tens of thousands of users are using the app, you can’t even make 10,000 yen a month.” Hitting 10,000 yen a month via an ad model is essentially synonymous with growing a user base from four digits to five. That’s not a scale an individual can build in a few months.

Implementing purchases came with a psychological hurdle too: no prior implementation experience, and “user support when something breaks in the app is also a lot of work.” Even so, he decided “if you want to earn seriously, this is the only way.”

Why the switch to purchases worked

First, the required user count dropped by an order of magnitude. Ads scale as “all users × a tiny per-unit price,” so the only lever is growing the denominator. Purchases scale as “a subset of users × a meaningful per-unit price,” so it can work even with a small denominator. He was shifting direction toward raising per-user revenue on the same existing user base rather than growing it.

Second, he didn’t invent what to sell from scratch. The author writes, “I looked at apps that were actually released,” researching other indie developers’ apps and extracting the common threads among their paid features. What he arrived at were two: “removing in-app ads” and “no limit on the number of entries”, and he adopted both directly. The fact that these appear as common threads is itself evidence that payment for them is already validated in the market. Borrowing a proven pattern is faster than inventing a value proposition from zero.

Third, these two specific paid features fit naturally with how a subscription-manager app actually gets used. The entry-count limit becomes a constraint that kicks in the more you actually use the app. The more services a user registers, the sooner they hit the cap, and that’s exactly where the need to pay arises. So the pool of purchase candidates is automatically filtered down to “people who are using it heavily.” Ad removal works the same way: the more often someone opens the app, the more the ads get in the way. The design meant that the more invested a user was, the stronger their reason to pay.

As corroboration, the author later added purchases to apps besides “Sabusuku” too, writing: “since the apps had already been out for a few months, people who kept using them consistently were the ones who bought.” The three apps released between May and August 2020 looked, at the time, like failures by ad-revenue standards, but by the time purchases were introduced, they served as an inventory of existing users. The point of releasing five apps was less to find a hit than to have multiple faucets ready for when purchases were turned on.

What the article doesn’t tell us

Specific purchase prices, purchase type (one-time or subscription), download counts for each app, and the breakdown of the 10,000 yen between ads and purchases are all unstated. Whether “10,000 yen a month” is a peak achievement or a sustained level also isn’t clarified. Time invested is only described as “working on some kind of service development on both weekdays and weekends,” without a weekly hour count. So this article is best read not as a resource for measuring revenue scale, but as a record of the gap that appeared before and after switching revenue sources.

The author himself, on the 10,000-yen milestone, says “I don’t feel it was that difficult,” attributing this to “being able to enjoy the process.” The flip side is that whether the same intensity can be sustained for over a year without that enjoyment is a separate question. He also writes: “if you feel that app development is painful… quitting is also a valid option.”

How much of this can you copy?

What’s easy to copy is the sequencing of tactics: validate 0-to-1 with ads, then move to higher-margin purchases. Extract common threads from competitors’ paid features for what to sell. Turn a constraint that gets hit more the more someone uses the app (like an entry limit) into your purchase trigger. Release multiple apps so you have multiple faucets ready when you turn purchases on. None of this requires capital.

Three conditions are harder to copy. One: the author was a working web engineer, developing while writing code on the job, self-taught. Two: the timing of entering Flutter in November 2019. As he writes, “at the time Flutter wasn’t nearly as popular as it is now,” implying he needed the stamina to learn mostly from YouTube and English-language articles, with little Japanese-language material available. Three: the market gap at the time, in 2020, where there was no clear domestic competitor for a subscription-manager app, a condition that can’t be chosen again from today’s starting point.

The author also states elsewhere that he now lives entirely on indie development income, and began beta distribution of an app blocker in August 2025. The 10,000-yen milestone was a starting point on that path.

Related reading

• Photo AI — the numbers behind a solo-built product designed around paid purchases from the start
• Kitchen Car — a record of small early-stage revenue disclosed month by month