Three Apps I Pulled From the Play Store

Three of my apps were on the Google Play Store. None of them are now. One had around a thousand downloads and was making a small amount of ad revenue when it came down.

Nobody writes this post. Portfolios are a list of things that worked, which is why every portfolio reads the same and none of them are useful. The three apps I pulled taught me more than most of the projects I still point at, so here is what they were, what was actually wrong with them, and what I do differently now.

The three

JEE Prep was my first real project. JEE is India's engineering entrance exam, taken by well over a million students a year, and the app was aimed squarely at them. Question bank organised by class, subject and chapter. A community doubt-solving section where students posted problems with photos and others answered, with upvotes and best-answer selection. Previous year papers. Video lectures. NCERT textbook access. Timed practice tests. A leaderboard with academic points, interaction points and seasonal points. Follow and unfollow, public and private accounts, follow requests, a referral system.

Native Android, Java, on close to the entire Firebase surface — Auth with four sign-in methods, Firestore, Realtime Database, Storage, Cloud Functions, Cloud Messaging, Remote Config, Dynamic Links, App Check. LaTeX rendering for equations. Lottie animations.

NEET Prep was the same app pointed at the medical entrance exam, and a simpler build of it.

Status Saver was different in every way. It read WhatsApp's cached status files from the device's hidden directory, showed them in a grid, and let you save or share them before they expired. About 900 lines of Java across ten files. AdMob banner on every screen. It was the one that got real users.

All three came down. JEE Prep and NEET Prep went first, through a Play Console problem I never fully resolved and, being honest, never fully understood at the time. Status Saver followed. I did not republish any of them.

What was actually wrong with JEE Prep

Not the code. The code was fine for a first project — questionable architecture, everything in activities and fragments, no ViewModels, a repository layer that was more of a suggestion. But it worked, it shipped, and it did a genuinely large amount.

That is the problem. Look at that feature list again.

Question bank. Doubt community. PYQs. Lectures. NCERT. Practice tests. Challenges. Leaderboard with three point systems. Social graph with follow requests. Referrals. Ban system. Four auth methods. Hindi and English.

That is not an app. That is five apps, built by one person who had never shipped anything, before a single user had confirmed they wanted any of them.

The doubt-solving community is the clearest example. Community features have a cold-start problem that no amount of engineering solves: a Q&A section with no users is an empty page, and an empty page teaches the first user that the app is dead. I built posting, images, upvoting, downvoting, best-answer selection, comments, view counts, and filtering — an entire social system — for a room with nobody in it.

The leaderboard is the same story with extra arithmetic. Three separate point systems, seasonal resets, ranking. Competitive features are motivating when there is competition and depressing when you are alone at rank one.

Any one of those features, shipped alone, would have taught me something. All of them shipped together taught me nothing, because when something is not working you cannot tell which of five products is failing.

What was actually wrong with Status Saver

The opposite problem, and a more interesting one.

Status Saver was small, focused, did one thing, and had actual users. It also had exactly one technically interesting part, and it is the part I would still write up today: getting at those files at all.

WhatsApp keeps statuses in a hidden directory. Before Android 10, you read it directly with a storage permission. From Android 10 onwards, scoped storage closed that door, and from Android 11 the path moved into an app-specific media directory as well. The app had to handle both worlds:

• Legacy path, direct file access, permission-gated
• Modern path, Storage Access Framework, createOpenDocumentTreeIntent, persistable URI permissions the user grants once
• Two entirely separate list adapters, because the objects you get back from a directory listing and from a document tree query are not the same thing

That is real Android platform work, and it is the whole app. Everything else — the grid, the preview with pinch-zoom, the save dialog — is standard.

The strategic problem is that the app's core function depended on the private storage layout of another company's application, which they can change at any time for reasons that have nothing to do with me, and which the platform vendor was actively working to make inaccessible. It was a product built on a shelf that was in the process of being removed.

The other problem, and this one is entirely mine: the AdMob application ID was hardcoded in the manifest, production values, no build variants, no test configuration. Every debug run was hitting live ad serving. That is exactly the kind of thing that causes account problems, and I did not know it was a problem until much later.

What I actually took from it

Ship one thing. The version of JEE Prep worth building was the question bank. Nothing else. Ship it, watch whether anyone opens it twice, then decide what the second feature is based on evidence instead of imagination. I now find the single feature something is for and cut everything else, and it is still the hardest discipline in the job.

Community features need a community first. They are not features you build, they are features you earn. A social graph on a product with no retention is engineering effort converted directly into nothing.

Read the policies before you write the code, not after the rejection. I treated the Play Console as a deployment step. It is a compliance surface with rules about data, permissions, ads, and content, and those rules are inputs to the design. Learning them by having an app pulled is the expensive path.

Separate production credentials from development ones on day one. Build variants, separate ad units, separate Firebase projects. It costs an hour at the start and prevents a category of problem that is very hard to unwind afterwards.

Do not build on another app's private storage. If your core function depends on an implementation detail of software you do not control, you do not have a product, you have a countdown.

Distribution is a real problem and it is not solved by building more. All three apps assumed that being on the store constituted a distribution strategy. It does not. Roughly a thousand people found Status Saver and that was because it solved a small, searchable, specific problem — not because of anything I did after publishing.

What I would keep

The Android platform work in Status Saver is genuinely good and I would write it the same way. Handling three eras of Android storage in one small app taught me more about the platform than any tutorial did.

The Firebase breadth in JEE Prep was excessive as a product decision and excellent as an education. Auth flows, Firestore modelling, Cloud Functions, messaging, remote config, dynamic links, App Check — I have used every one of those since, and I learned them by needing them.

And shipping to a real store, with a real review process and real users leaving real one-star reviews, is not the same experience as building something impressive that only ever runs on your own machine. Everything I know about the gap between "it works" and "it is released" came from these three.

The point

The projects on the front page of this site are the ones that worked. These three did not, and they are the reason the ones that came after are smaller, more focused, and shipped in a state I can defend.

A first project that fails publicly is not a bad first project. It is the fast version of a lesson everyone eventually pays for.