With a $70 ad budget he got 130 installs and 2 paying users. Then he left Android for a Chrome extension and sold 7 copies in a week

What determines the outcome of an indie developer’s revenue isn’t only how good the product is. Sometimes the single variable that changes everything is simply where you place it. A note.com post titled “The story of how, after burning out on Android app development, I released a Chrome extension and my revenue flipped within a week” (by Takana Konbu, published January 28, 2026) records that gap in small but concrete numbers. Every figure involved is in the thousands of yen at most. Nothing flashy. What makes it worth reading as a comparison is that the developer, the time period, and the promotion methods were held nearly constant. Only the platform changed.

What happened in two places

All the figures come from the author’s own post, but the conversion rates and revenue totals here are calculated from the published numbers. 1,480 × 4 = 5,920 yen, 980 × 3 = 2,940 yen, for a total of 8,860 yen. Meanwhile, since Android ad revenue was under 100 yen a day, even stretched out to 30 days it wouldn’t reach 3,000 yen a month. The per-subscriber price for the Android app’s 2 subscribers isn’t stated, so the total Android revenue can’t be pinned down exactly. But combining the author’s own statement, “I was able to significantly exceed my Android app’s revenue”, with the fact that the 10,000-yen ad spend hadn’t even been recouped, it’s clear which side came out ahead.

What he was actually doing

On the Android side, he was pursuing revenue through both in-app purchases and ads. For acquisition, he chose Play Store advertising: 10,000 yen bought over 130 installs, or roughly 77 yen per install. As a paid acquisition cost, that’s not bad. But only 2 of those installs converted to a subscription. He could buy acquisition, but not conversion.

As a point of comparison, the author cites his own past blog ad revenue: “on average around 400 yen a day, sometimes over 1,000 yen.” Even with the same ad model, the blog was an order of magnitude higher. An app earning under 100 yen a day was, in his own assessment, clearly underperforming.

He released two Chrome extensions. The first, “YouTube Study Notes,” lets users leave timestamped notes on YouTube videos, with a 1,480-yen Pro version. The second, “QuestTab,” shows a to-do list and bookmarks on the new-tab page, with a character that levels up RPG-style as tasks get completed. Its Pro version is 980 yen. Both were built with a framework called WXT. Both started from features the author himself wanted as a heavy browser user.

The turning point wasn’t a rebuild — it was a change of venue

The turning point in this case is clear: the single decision to stop pursuing Android and try a Chrome extension instead. And what pushed that decision wasn’t the low revenue itself so much as the operational cost. Google Play requires new individual developer accounts to run a closed test with 12 testers over 14 days. The author called this “extremely tedious,” citing the burden of recruiting and managing testers plus the risk of rejection. A Chrome extension, by contrast, requires only a $5 registration fee and no closed test, just a review. On top of that, the required languages were just HTML, CSS, and JavaScript.

Lining up the before-and-after numbers: on Android, he spent 10,000 yen in ads to buy 130 installs, with 2 paying. On Chrome, zero ad spend, promotion limited to X and note, 41 installs, 7 of which converted to paid, reaching a level that “significantly exceeded Android app revenue” within a week of release. The sample is far too small for statistical claims, but per-user revenue tells the story: Android is essentially zero, while the extensions earned roughly 8,860 ÷ 41 ≈ 216 yen per user. That’s an order of magnitude different.

Why did 7 of the 41 open their wallets?

Rather than naming specific tactics, it’s worth breaking down the structural reasons the conversion rate jumped from 1.5% to 17%.

Part of it is that the acquisition channel was different. The author promoted the release on X and note, but writes that “the response was next to nothing.” Actual traffic came “simply from store search and web search.” The extension’s users, then, were people who had articulated their own workflow frustration and searched for a solution, not people who stumbled across an ad. Someone who arrives already aware of their problem is inherently more likely to convert than someone pushed in by an ad. The Android app’s 130 installs were the latter, not the former.

Another part: the browser extension category itself tends to attract users who are right on the verge of a purchase decision. The author writes: “People who use Chrome extensions are looking for efficiency in their work, even more so than mobile app users, I feel.” He himself says he’ll pay a one-time fee if it genuinely changes his efficiency. A browser extension is something you use while working, and time saved translates readily into a dollar amount. The 1,480-yen price point, while higher than typical mobile app pricing, lands as cheap when framed as a “work tool.”

The rest comes down to the store listing: because he knew traffic would come from search, the listing copy itself became the primary battleground for acquisition. The author had AI write the entire description. By giving instructions like “explain the target audience, features, and usage in detail,” he made sure the copy covered the vocabulary people would actually search for. Once you accept that social sharing won’t drive traffic, the store listing text is essentially the only acquisition asset you can iterate on at near-zero cost.

In short, what worked wasn’t “cheap entry” or “new technology.” It was placing the product, in a form discoverable by search, in front of an audience that already has a habit of searching for its own problems and a demonstrated willingness to pay. That’s what a 17% conversion rate is made of.

What can’t be overstated

The numbers in this case are small. A total of 41 installs, 7 purchases. A single swing either way would move the conversion rate by several points, and immediately after release, purchases sometimes come from the developer’s own circle. The headline “flipped within a week” also needs to be read against the fact that the Android revenue it flipped past was already sitting below 100 yen a day. A low bar isn’t the same as a big win.

There are caveats on the Android side too. The author never discloses the subscription price or the app’s name. So the article doesn’t support any generalization like “you can’t make money on Android.” What it shows is only that this particular acquisition approach, for this particular app, by this particular developer, didn’t work out.

And the Chrome extension side has its own structural weakness. The pool of store searches is far smaller than mobile app stores. The 41-install figure demonstrates that. Even with a high conversion rate, if the denominator doesn’t grow, revenue caps out at a few thousand yen. The author himself is still weighing his next move, writing that he’ll “watch a bit longer and consider running SNS ads if needed.”

How much of this can you copy?

What’s easy to reproduce is the mindset of weighing entry requirements as a decision input. Twelve testers over 14 days versus $5 plus a review. Both are paths you can walk once, but if your strategy is to increase your release count and hunt for a hit, that gap directly becomes a gap in how many attempts you get. Keeping “change only the venue, not the product” as a standing option is something anyone can do.

What’s harder to reproduce is the author’s starting conditions. This person sells programming-learning materials and runs a membership starting at 980 yen a month. He has experience selling paid information and is comfortable designing pricing and copy. Being able to set a price of 1,480 yen from the outset is an extension of that background. He also chose a tool category he’s a heavy user of himself, so he could judge which features were necessary. This isn’t a story of “make it a Chrome extension and it’ll sell”. It’s a story of “sell the fix for your own daily tool’s annoyance, inside that same tool.”

One more thing that’s hard to copy is timing. Having AI write the description to capture search traffic will lose effectiveness as more developers do the same thing today. It’s probably most accurate to read this article’s numbers as a record from a period when store search was still relatively uncontested.

Related reading

• Photo AI — how a solo developer designed pricing and value delivery
• Carrd — an example of a small tool sold long-term at a low, one-time price