Sewashita: 13 Apps, 4.5 Years, 326 Android Installs

Around a pet care logging app called Sewashita, HAL has shipped 13 mobile apps over four and a half years. At the four and a half year mark, monthly revenue was 1,800 to 2,000 yen from AdMob advertising plus an average of $39 from subscriptions and one-time purchases. This site records the combined figure as 8,000 yen per month, which is one thirty-first of the 250,000 yen median across the 19 mobile apps here that disclose monthly revenue. By count alone, 13 apps puts him among the more prolific indie developers in our archive. The revenue stayed at this level anyway, and he does not describe that as a failure. Stacking up releases ought to stack up revenue, or so the reading goes. These four and a half years do not show it.

What grew over one year, two years and four and a half

HAL has published the same kind of retrospective three times: at the one year mark in October 2020, at two years in October 2021, and at four and a half years in April 2024. Laying out the disclosed figures gives this.

Download figures appear in all three posts. At one year, Sewashita had just under 1,800 on iOS and 27 on Android. At two years, all eight apps together had 7.7K. At four and a half years, all 13 together had 21.7K, of which Sewashita accounted for 10.1K on iOS and 174 on Android.

One accounting detail shifts partway through. The first post puts the total at “just over 6,000 yen,” while the second post looks back and says “last year it took a full year to reach 2,500 yen in sales.” Monthly and cumulative appear to have swapped places, so this article uses only the itemized figures each post states explicitly and sets the year one total aside.

From 8 apps to 13, revenue moved from 3,000 yen to 7,800

Over the two and a half years between the second and third posts, the portfolio went from 8 apps to 13. Monthly revenue went from about 3,000 yen to roughly 7,800. Divide the five added apps into the 4,800 yen of added revenue and you get about 1,000 yen per app per month. Speculating here, the real contribution of those five is smaller than that, because Sewashita’s own growth is folded into the same number.

Adding one app added about 1,000 yen a month and one app’s worth of maintenance that never ends. He describes that burden concretely in the second post. There are “several apps I honestly have no motivation to maintain,” and bug reports still have to be fixed. “I want to spend the time improving my main app, but another app takes it instead.” Once an app has users, he adds, you cannot simply kill it.

Lining up our other cases makes the disconnect between count and revenue clearer. The developer who shipped 13 games and earned 700 yen in total, taking four years to reach the 8,000 yen payout threshold reports 4,000 yen a month. The engineer with 10 apps in eight years at 30,000 yen a month holds 10. The developer who reached 200,000 yen a month in year eight holds three. Fewer apps, larger revenue. Reordering the list does not change that.

Thirteen Android builds, 326 installs in four and a half years

The number that stays with you here has nothing to do with revenue. Android is where it sits. Sewashita’s Android version has 174 installs after four and a half years, and the other 12 apps add up to 152. Thirteen Android builds maintained for four and a half years produced 326 installs in total. iOS over the same period sits around 21.4K, two orders of magnitude apart.

Android was already at 27 at the one year mark, where he wrote that “organic traffic clearly favors iOS.” At two years, “Android is simply flat.” At four and a half years, “traffic on the Android side is essentially nonexistent.” The same observation repeats across all three posts, and no remedy lands in between. New apps still ship on both platforms.

Bluntly, this is where a decision is missing. Keeping Android means carrying store review changes, OS update breakage and bug fixes across 13 builds. What it returns is 326 installs over four and a half years, and the ad revenue from those installs is never itemized. The problem he keeps circling, that maintaining more apps hurts, connects directly to that 326. There is a reason he has not cut Android, though, and the posts contain it. Sewashita shares data between family members, and the first post reports a common pattern where someone starts on iOS and their partner installs the Android build to join. When sharing is the selling point, dropping one platform thins the product itself. He cannot cut it without changing what he is selling.

A 2 to 3% stickiness rate, which he does not treat as a problem

Sewashita has 10.1K iOS downloads against 250 to 270 daily active users and 780 to 850 monthly. Daily actives against cumulative downloads comes to 2 to 3%.

The usual move is to flag that as the problem, but his reading goes elsewhere. “Since it never declines either, another way to say it is that once someone sticks, they keep using it.” Pet care is a daily errand, so users who latch on do not drop off. That reading fits the 65 subscriptions plus 8 trials that have accumulated without cancellation. Seven apps carry subscriptions, so fewer than 10 per app, yet it behaves differently from ad revenue, which only moves in proportion to user count.

His year one conclusion points the same way. “Subscriptions beat ad revenue.” “If even one person likes it enough to subscribe, that alone is a few hundred yen.” The second post records the flip side. “Once you are taking money, you start to feel responsible for making it right.” “Users are paying, so their standards are sharper.” Subscriptions stabilize revenue and raise the cost of quitting at the same time.

The cause he names, and the cause we see

The three lessons he lists at four and a half years are that awareness matters more than anything, that staying out of the red matters, and that motivation is hard to hold. He rewrites the common saying: “build something good and people will use it” is more accurately “build something good, get them to start using it, and they will keep using it.” Until people know about it, he concludes, it may as well not exist.

That self-diagnosis is half right. Following the numbers, though, what has stalled is not total awareness. 21.7K downloads in four and a half years is not a small figure for an indie developer, and the users who stuck have not left. What has not moved is the revenue loaded onto each download. Seven apps with subscriptions produce 65 signups, and 250 to 270 daily actives produce 1,800 to 2,000 yen a month in ads. Double the awareness and, at this unit economics, monthly revenue reaches 16,000 yen. We read the plateau in this case as a pricing and packaging problem rather than an acquisition problem.

He has not chosen to go after that unit economics. What he has chosen is to stay out of the red. “Running costs have always stayed below revenue,” he writes, explaining that “motivation that comes from clearing a deficit is inseparable from anxiety.” In year one he bought ads, saw nothing, and recorded that “I probably will not run ads again” and “unplanned advertising is a bad idea.” This is not a design for maximizing revenue. It is a design for staying in a state where you can keep going. For a side project run outside a day job, a deficit is not a financial problem but a pressure to quit. Profitability here works as the device that prevents quitting rather than as a goal.

What failed, and what was never disclosed

The only clearly labeled failure is the ad buy, and the amount is not disclosed. On ASO he admits at four and a half years that he “never worked on it at all,” and had only just started adjusting keywords, reaching a “maybe there is some effect?” stage. For most of those four and a half years, store search optimization sat untouched. The second post notes a viral moment on Twitter that brought ten times the usual downloads, but he also calls it a fluke, and no method for repeating it appears.

Plenty of numbers stay hidden. Per app revenue across the 13, subscription pricing, churn, annual profit and loss including the 10,000 yen a year Apple Developer Program fee, and hours invested. Without a record of development time, no hourly figure is possible. All three sources come from the same author, so nothing here is independently verified, and the consistency of the accounting rests on his own judgment.

How far this carries

• Adding more apps works only when the per app pricing already stands up and what you are adding is surface area rather than revenue
• Running for profitability above all else matters only in a side project you are free to abandon, where a deficit itself becomes the reason to quit
• Shipping on both platforms stays justified only for products where dropping one breaks a function such as sharing or invitations

The limits are worth stating. Behind this case sit a day job in engineering, a Firebase free tier that keeps costs at 1,000 yen a month, and pet care as an errand that recurs daily. As the first post explains, the niche came from a policy of targeting genres with fewer than 10 competitors, and the same choice will not carry in a crowded genre. Four and a half years is also a span that only exists because nothing was being lost. At 10,000 yen a month in costs, this operation does not last four and a half years.

For another case of indie development measured in years, see the developer who reached 50,000 yen a month after five years and disclosed both the tactics that worked and the ones that did not. The destination is six times HAL’s, and the portfolio is deliberately smaller.