The business problem
A mobile product only pays off if it keeps working. Operating systems change, store requirements tighten, and a codebase built for one platform does not automatically serve another. Turning an idea into a product people keep buying means choosing what to build, shipping it on the right platforms, and maintaining it long after launch.
Focusing on what worked
The business started as a set of about 20 apps. Sales data made the decision easy: 19 of them were unprofitable, so they were unpublished and development concentrated on the one product customers actually paid for. Less surface area meant more attention on quality, support, and updates for the product that mattered.
Rebuilding for new platforms
The product was rebuilt twice as the platforms changed. The first rebuild reworked the Android version end to end and added iOS, so the product reached both app stores. A later migration to Flutter and Dart put both platforms on a single codebase, which cut the effort of keeping them in step.
Content lives apart from code. Companion Python tooling handles collecting, deduplicating, and ingesting content, so routine content updates do not require reworking the app itself.
Operating it like a business
Running the product includes more than writing code. Store submissions and reviews, Apple and Google developer accounts, payment processing, customer support, and ongoing compatibility updates are all part of delivery. A typical year needs only occasional compatibility and content updates, because the scope and structure were designed to be maintainable.
The result
The app has passed 50,000 lifetime sales across the App Store and Google Play. That figure counts purchases, not downloads or revenue. It continues to sell largely through organic store search, with a small, predictable maintenance workload.
The same approach applies to client work: ship something focused on a real need, choose a structure that is cheap to maintain, and keep it current as the platforms around it change.