Our Own Record #3 | 277 Commits and 17 Languages, and It Still Stopped — How Two Apps Went Quiet

At the end of May 2026, four days apart, we started two mobile apps. One was an app for families and couples to share day-to-day items. The other, a simulation game about running an aquarium. Both were solo-built, both shipped to the store. Both have now stopped updating.

This installment lines up the road to each stoppage from the repository records. They stopped in completely different ways, so we treat them as a pair, for contrast.

The two histories

277 commits in 51 days is 5.4 a day, 244 of them concentrated in June alone. The content site running in the same period logged 2.4 commits a day, so measured purely by hand-moving speed, the apps were more than twice as fast.

The one that stopped by over-building

In 51 days, the sharing app gained: three tabs (shared lists, house rules, expense settlement), anonymous auth, multiple group membership and switching, push notifications, read-only web share links, subscription billing, a referral program, and a script for seasonal broadcast notifications. The version number reached 1.14.0.

And it reached 17 languages. Starting from Japanese and English, we added Korean, Chinese, German, Spanish, French, Italian and Portuguese. In July we added Indonesian, Vietnamese, Thai, Russian, Turkish, Hindi and Arabic in one go. That covered every UI key, and beyond the app itself, push notification copy and store listings too, in all of them.

Let us describe soberly what that work was doing. Without ever checking how many people would use it, we multiplied the supply-side surface area by 17. At a stage when we didn’t even know how much it was used in Japanese, we were writing Arabic push-notification copy. Adding translations is technically pleasant work: progress is countable, commits accumulate. Whether demand grew is displayed nowhere in it.

The repository roadmap still holds items designed but never started: approval-based joining, role-based permissions. The designs kept growing. The step of looking at whether anyone was using it never once entered.

The commit of July 21 was a minor fix to the store listing. It wasn’t a decision to end. The hands just stopped there.

The one that stopped by rebuilding

The game stopped in an entirely different way.

Started on May 27 in Swift and SwiftUI. On May 31 there is a commit reading “moved to flutter.” Four days in, the existing implementation was discarded for Flutter, for the sound reason of wanting Android as well as iOS. Still, that means 4 of the 17 active days went to a rebuild.

In the two weeks to June 13 it got localization, gacha tuning, visitor-count balancing, and reached version 1.2.0. Forty commits to a playable state is on the fast side.

It stopped because we no longer knew what to build next. We had prepared no way of learning what players found fun, so the only yardstick for balance changes was our own taste. The final commit reads “re-tune max visitor count to 4.5x baseline”, and there was, from the beginning, no way to check whether 4.5 was right.

Some things become unfixable once you ship

One thing in this game can no longer be fixed.

The iOS Bundle ID (the string that identifies an app) contains a typo. Two letters missing. The Android identifier is spelled correctly, so the same app carries mismatched identifiers across platforms. A Bundle ID cannot be changed after App Store publication, so this cannot be repaired. The repository guide carries the note: “typo; published to the App Store, cannot change.”

The practical damage is small. But the line felt symbolic: shipping in a hurry created a decision that is now permanently fixed in place. Shipping early has benefits. It also freezes things in exact proportion.

One more: the release runbook says “primary target: Android; primary channel: Google Play.” What actually shipped was iOS only, and the Play Console preparation table remains mostly untouched. The written strategy and the executed order disagreed, noticed only after it stopped.

What the two had in common

Their stopping patterns differ. The missing step is identical. Neither ever included a step to test demand.

The over-built one kept adding features and languages. The rebuilt one swapped foundations and sprinted to launch. Both are supply-side work. Both are countable in commits. Whether anyone uses the thing appears in no commit count.

Looking across this site’s indie-developer cases, the ones that grew share a from-day-one channel through which reactions come back from outside: the pattern of posting to communities and watching reactions before building deep, or Avatar AI, shut down by its founder’s own decision after the numbers had come in. Only the side that has numbers gets to make a decision to quit. The side without numbers doesn’t get a decision, only a stop.

The engineer who ran a Python-automation side business and decided to withdraw at ¥150,000 cumulative earned little, but was able to use numbers in the withdrawal decision, which puts that record ahead of these two apps.

About the numbers we haven’t published

Download counts and billing revenue are not in this article. We do not hold them in an after-the-fact verifiable form. That we never kept them countable says a lot about the character of these two apps. If we can assemble them, we will append them here.

What we could publish was commit counts, dates and version numbers. The builder’s effort was perfectly recorded. The usage was recorded nowhere. That is the kind of repository these were.

In this series

• Part 1 — We started four, and three broke
• Part 2 — The two-person SaaS broke on the cap table
• Part 3 (this article) — 277 commits and 17 languages, and it still stopped
• Part 4 — 9,103 monthly users in 3 months: a content site’s real numbers