Week 8: The Hidden Work Behind Publishing a Solo Android App

Build in Public — Week 8 (June 8–14)

In week 8, I was reminded that publishing an app is not the same as finishing the code. This sounds obvious, but it is easy to forget when you are deep in development. You spend weeks building features, fixing flows, improving screens, and testing reminders. Then one day you think: The app is almost ready. But “almost ready” for the developer is not the same as “ready to publish.”

For Lumi, the final stretch before release involved Google Play, app signing, testing tracks, subscription setup, crash reporting, privacy materials, help content, support channels, screenshots, demo videos, and many small details that users may never notice directly. Those details still matter. They are part of making the product real.

Google Play is a product gate, not just a store

Before building my first Android app as an independent developer, it was easy to think of Google Play mainly as a distribution channel. Upload the app. Fill in some information. Wait for review. Release. In reality, it feels more like a product readiness system. You need to prepare the app package properly. You need signing and release configuration. You need internal testing and closed testing. You need store listing content. You need privacy and permission explanations.

You need to think about what a first-time user will see before they ever install the app. This forced me to look at Lumi from outside the development environment. The app was no longer just something on my phone. It had to be understandable to a reviewer, acceptable to a store, installable by testers, and explainable to real users. That is a different standard.

Subscriptions add another layer of product behavior

Lumi also needed subscription-related testing. This was not only about whether a purchase screen could open. A subscription is a stateful product behavior. The user can be free, upgraded, expired, restored, or in transition. The app has to show the right access level and avoid confusing the user. For a reminder app, this is especially important because users are not buying decoration. They are buying trust and capability.

If a user upgrades and the app later behaves as if they did not, the issue is not just a billing bug. It becomes a trust problem. So subscription testing had to include more than one happy path: What happens after purchase? What happens after restore? What happens when the app restarts? What happens when the app returns to the foreground? What happens when the user enters the upgrade page later? The lesson was clear: entitlement state should not depend on the user manually fixing it.

If the app can reasonably synchronize the subscription state automatically, it should.

Crash reporting became mandatory

Before launch, crash reporting moved from “nice to have” to mandatory. When the app is only on my device, I can debug directly. When testers use it, I need visibility. When real users use it, I need even more visibility. Crash reporting is not glamorous. It does not make the product look better in screenshots. But it changes how safely you can release. Without it, a user may experience a crash and disappear. You may never know what happened.

With it, at least you have a chance to see patterns, prioritize fixes, and understand whether a release is healthy. For a solo developer, this matters because there is no support team watching every signal. The product needs basic diagnostic ability built in.

Help, privacy, and support are part of the app

Another thing I had to prepare was the material around the app. Privacy policy. Help content. Permission explanations. Support email. Store description. Screenshots. Demo video. These do not feel like “core product development” when you are writing code, but they become core before launch. Users need to know what the app does. Reviewers need to understand why permissions exist. Testers need a way to report problems. New users need help when they are confused.

For an AI app, this is even more important because users may not immediately know what they can ask. Good help content is not just documentation. It is onboarding.

Release preparation changed my definition of done

Before week 8, “done” often meant: The feature works on my device. After week 8, “done” meant something broader: The feature works. It is understandable. It is testable. It is observable. It fits the store requirements. It has user-facing explanation where needed. It does not create unnecessary release risk. This is a much stricter definition, but it is closer to real product work. The last mile of publishing is not just bureaucracy. It is where a personal project becomes a public product.

What I learned in week 8

The biggest lesson from week 8 was that launching a solo app requires more than coding ability. You need product judgment. You need release discipline. You need testing habits. You need support thinking. You need basic operational visibility. You need to explain the product clearly to users who have never seen your development process. For Lumi, this week was a shift from building features to preparing a product system. The app was the center, but it was not the whole product.

The store listing, privacy policy, help center, subscription flow, crash reporting, test channels, support email, and demo materials all became part of Lumi’s first public shape. That was the hidden work behind publishing. Not glamorous. Not always technical. But necessary.