Ankimaker: A High Schooler's Flashcard App Hit 1M Downloads in 8 Years — 300K of Them in One

Sometimes an indie development record is worth reading even though it contains no revenue figures at all. Ankimaker, a study app, reached one million cumulative downloads about eight years after its June 2016 release. According to the post developer ymdkit published in February 2024, roughly 300,000 of those downloads, three tenths of the total, were added in the single year right after he left his job and went independent. He was 24 at the time. Roughly a third of his life had been spent on this one app.

The app itself is strikingly plain. You build your own question set, answer it, and share it with other users. The design narrows to three things (writing questions, answering, and sharing) and it is used for certification study and school exam prep. The service page of QuizMarket Inc., which now operates it, lists support for iOS, Android and web, and states over one million cumulative downloads. The company’s headcount registered in gBizINFO is one.

The origin is in high school. Having picked up a book on Android development and built a notepad, a weather app and puzzle games, he wrote a flashcard app for his own exam studying. He talked his parents into paying the $25 Google Play registration fee and got it published. The first revenue took more than six months to arrive: ¥8,000 from AdMob.

Eight years, broken down

No actual revenue figure ever appears. But one of the three reasons he gives for going independent is that Ankimaker was covering his minimum living expenses, whereas his 2021 phrasing was “about as much as a part-time job” and “close to passive income.” The gap between those two descriptions hints at what changed on the revenue side during the stretch when 400,000 downloads over five and a half years became another 600,000 in just over two.

Winning search rankings with zero ad spend

Up to the 400,000 mark, what worked was ASO. The goal was to hold top positions for the search terms “test study,” “question set,” and “memorization,” achieved partly by keeping the app title plainly descriptive. He describes the result as a state where downloads can be expected from search traffic without spending anything on advertising. Study apps are also seasonal, spiking around exam weeks, and sitting in a position that catches those spikes through search means the numbers accumulate even in months with no initiatives.

The cost side is designed to match that “does not decay when left alone” structure. Core features run entirely on the client. The server is only used when a user uploads a question set to share. Pushing server usage into the one place that pairs well with metered billing means fixed costs do not rise in proportion to downloads. Even the iOS release was timed: he waited until Android ad revenue could clearly cover the App Store annual fee. For a student running this as a hobby, any other order would not have lasted.

The revenue model was reasoned as well. Sessions run a comparatively long 30 minutes to an hour, which pairs well with banner ads — hence ads as the main source and a one-time remove-ads purchase as support. That is different from indie developers who default to ads for no articulated reason. Here it is derived from how the app is used. Compared with the developer who shipped 68 apps to 2 million downloads without a single hit, this is the type that converts one app’s session length into revenue rather than converting volume.

What independence changed was the interval between decisions

Explaining 300,000 downloads in one year with “he had more time” probably misses the point. The changes he names are decision speed and the granularity of the work. He writes that he sometimes shipped an idea the same day he thought of it, and his review submission cadence rose to roughly one every two days.

The initiatives from that period are also things carried back from his job. He adopted a design guideline with “do not surprise the user” as the standard. He A/B tested multiple layouts and confirmed there that his own intuition was unreliable. He replaced the Swift/Kotlin native pair with Flutter. He machine-translated the app into 70 languages with ChatGPT. He sped up his own hands with GitHub Copilot.

And on monetization he introduced a subscription, which grew to half of revenue. Moving from an ad-centric mix to one that includes subscriptions means moving from a stage that chases downloads to one that converts continued use into revenue. Study apps tend to lose users when an exam or certification ends, and ad revenue mirrors those peaks and troughs directly. A subscription is the device that fills the trough. That shift in revenue mix may matter as much as the million-download milestone.

What did not work

Localization failed once. A half-finished multilingual push using Google Translate caught the attention of local users, who responded with a run of one-star reviews in Russian complaining that the in-app text made no sense. He rolled localization back to English only. Years later he redid it in 70 languages with ChatGPT, and even then his stated attitude was the restrained “better than nothing.”

Technical choices left regrets too. On building Android in Kotlin and iOS in Swift, he writes that as development stretched out, doubling the effort for every fix became genuinely hard for a solo developer, and that cross-platform might have been the better call. He did in fact consolidate on Flutter after going independent. Over an eight-year horizon, the early stack decision governs the later development speed.

There is also a record of requests he declined. “Attach images to questions” and “quiz only the questions I got wrong” were adopted because they sit inside the core of authoring and answering and help many users. “Keep a daily study log” was declined because existing tools cover it, and “check English pronunciation” because the benefit was too narrow. Over eight years of solo development, the refusals probably mattered more than the additions.

What transfers, and what does not

What this case offers is an operating practice: even when you cannot publish revenue, keep indicators that measure progress. Cumulative downloads, the subscription share of revenue, release frequency. Every number in this record is one the developer can count himself, without depending on outside valuation. Like the bill-splitting app Walica, which told its growth story through user counts, it is an example of keeping a business verifiable while keeping the money private.

What does not transfer is the use of time itself. Holding the same app from high school through university, employment, and independence is exactly what made independence a real option once revenue reached living costs. Run backwards, you cannot decide to go independent first and then manufacture eight years of accumulation. That he lists “risk increases the older you get” among his reasons shows the sequence happened to align with his age rather than by design. Set beside SiRO’s fourteen-year revenue curve, you start to see how long the run-up is before long-horizon indie development turns into money.

One more limit sits on the market side. Study app users churn fast. They graduate or pass and leave. One million cumulative downloads is not the number of people using it now. Making subscriptions half of revenue is an attempt to translate retention into income inside that structure, and it is where the next few years will be decided. That the operator has incorporated, still with one employee, while advertising features for cram schools and schools reads as a search for continuing revenue outside individual users.