From Idea to Play Store in Two Weeks: My Process

People assume the hard part of shipping an app is the code. After doing this twenty-plus times, the code is rarely the bottleneck. The bottleneck is scope creep, store paperwork, and the long tail of "almost done." A repeatable two-week process exists because I've removed the decisions that used to eat days. Here's the shape of it.

Days 1–2: Decide What It Is and Isn't

Before any code, I write down the one thing the app does and an explicit list of what it will not do in version one. The non-goals list is the most valuable document in the project — it's what I point to when I'm tempted to add a feature on day nine.

App: water reminder
Does: log intake, remind on a schedule, show a daily goal
v1 will NOT: sync across devices, integrate health APIs, gamify

If I can't describe it in two sentences, it isn't scoped yet.

Days 3–8: Build the Core Loop Only

I scaffold with my standard stack — Kotlin, Compose, MVVM, Hilt, Room, StateFlow — so there are no architecture decisions to relitigate. Then I build the single core loop end to end and nothing else. One screen that does the main job, persisted locally, working.

The discipline that keeps this to days instead of weeks: no speculative abstraction. One ViewModel, not a base class. One Room query, not a generic DAO framework. The app does one thing; the code should look like it.

Days 9–10: The Edges That Make It Feel Real

Now the unglamorous part that separates shipped apps from prototypes:

• Empty states and error states for every screen.
• Edge-to-edge insets handled so content doesn't sit under the system bars.
• An app icon and a coherent theme.
• A crash-free pass through every flow on a real device, not just the emulator.

This is usually where I find the bug that would have generated my first one-star review.

Days 11–12: Store Paperwork, the Real Time Sink

The work nobody warns you about. Each of these is small; together they're a day:

• A privacy policy, hosted at a real URL.
• The Play Store data safety section, filled to match what the app actually collects.
• Title, short description, full description, and screenshots.
• Content rating questionnaire and target audience.

I keep templates for all of it so this is filling blanks, not writing from scratch. The first time you do it, budget double.

Days 13–14: Internal Testing, Then Release

I push an AAB — never an APK — to an internal testing track, install it from the Play Store itself, and run the full app one more time as a user would. That last pass catches signing and configuration issues the debug build hides. Then I promote to production and tag the release in git so I can reproduce exactly what shipped.

What I Deliberately Skip in V1

Analytics dashboards, A/B infrastructure, onboarding carousels, settings nobody asked for. They can come after real users exist. Shipping the focused version and learning from it beats polishing features in the dark.

Why Two Weeks, Not Two Months

The timeline isn't about working fast; it's about working bounded. A two-week box forces decisions that an open-ended schedule lets you avoid. When you know the deadline is close, you cut the feature you were going to add "just in case," because there's no room for it. That pressure is a feature, not a bug — most of what I would have built in a two-month version turns out to be stuff no user ever asked for. The constraint does the prioritization that I'm too optimistic to do on my own.

The deeper reason is that the first version exists to answer a question: does anyone want this? You cannot answer that from inside your own head, and you cannot answer it from a half-built prototype on your machine. You answer it by shipping something real and watching what happens. Every week spent polishing before launch is a week spent improving a guess. Shipping the focused version in two weeks means I start learning from reality two weeks in instead of two months in, and reality is a far better product manager than my imagination.

There's a compounding effect across many apps, too. When shipping is a two-week process instead of an open-ended slog, the cost of trying an idea drops low enough that I can afford to be wrong. Most apps won't take off, and that's fine — a cheap, repeatable shipping process means a miss costs two weeks, not two months, and the occasional hit more than pays for the rest. The process is what makes a portfolio of focused apps viable for one person at all.

Key Takeaways

• Spend the first days defining the one core job and an explicit non-goals list to fight scope creep.
• Use a fixed, familiar stack so you build features, not architecture debates.
• Build only the core loop end to end first; resist speculative abstraction.
• Treat empty/error states, insets, icon, and a real-device pass as required, not optional polish.
• Budget real time for store paperwork — privacy policy, data safety, listing — and keep templates to speed it up.
• Test from an internal track with an AAB before production, and tag every release.