Zero Feature Sprint: 30 Polish Commits Before Launch

Polish is more profitable than features. In 48 hours and 30 commits with no new features, I made my app more robust than in six months of additions. Here's why a "zero-feature" sprint before launch is the best decision a solo developer can make.

Why do a zero-feature sprint before launch?

For six months, every day of development added something. A feature, a screen, a pipeline, an integration. The commit counter went up, files piled up, and the app grew over 650+ commits.

And then a moment comes when you have to stop. Not out of fatigue, but out of clarity. The app works for 12 alpha testers who know its limits. But the general public is unforgiving. According to an Apptentive study, 77% of users read at least one review before downloading an app. And a single visible bug at the wrong time means a 1-star review.

So this week, I did the opposite of everything I had done until then: 30 commits in 48 hours. Zero features. Only polish, fixes, and preparation for when the app leaves alpha and enters the real world.

How to fix 15 bugs on a single AI personalization screen?

TAMSIV's AI allows users to introduce themselves by voice. You press a button, you tell your life story in 30 seconds, and the assistant adapts to your personality. The problem: the configuration screen had 15 subtle bugs that automatic tests didn't detect.

A button hidden by an overlay. Text truncated on small screens. An infinite loop when the user interrupted the AI in the middle of a response. The prompt resetting after each modification. Action buttons stacked on top of each other instead of being placed vertically.

None of these bugs would have been found in a quick test. You had to use the app like a real user — tap everywhere, interrupt at the wrong moment, go back, try again. This is what the Nielsen Norman Group calls exploratory usability testing: no script, just a human trying to break the interface.

15 commits to make a single screen reliable. It seems excessive. But when it's the screen that defines how the AI understands you, every micro-bug degrades the entire experience.

What's the difference between "it works in alpha" and "it's ready for production"?

The Free/Pro/Team subscription system had been in place since February. It worked in alpha. But "working in alpha" and "being ready for production" are two very different things.

In alpha, 12 testers know it's a work in progress. They accept approximate wording, a not-quite-final design, blurry limits between plans. In production, every ambiguity costs a user. According to ProfitWell, a confusing pricing page can reduce conversions by 20 to 40%.

The redesign focused on three areas:

• Wording: every text was re-read to clarify what is free versus paid. No more ambiguous phrasing.
• Alpha modal design: it no longer has a reason to exist in production. Deleted and replaced by a natural flow to RevenueCat plans.
• Free plan limits: each screen checked on 3 different screen sizes, every text responsive.

The kind of work that doesn't show up in a changelog, but makes the difference between a user who understands what they're paying for and a user who uninstalls due to confusion.

What "small details" have the most impact on retention?

Three minor adjustments transformed the daily app experience.

The TTS stop button. When the AI responds aloud and you want to stop it, before you had to mute your phone. Now a toggle is enough. It seems trivial, but it's exactly the kind of friction that pushes a user to uninstall. The voice recorder is the heart of TAMSIV — it must be impeccable.

The strict scope of the LLM. The AI tended to answer off-topic questions — weather, general knowledge, philosophy. In production, it must remain focused: tasks, memos, events. Period. A backend guardrail politely refuses everything else. As OpenAI's prompt engineering guide explains, setting clear limits for the LLM is essential for a consistent user experience.

The generated images toggle. Each conversation can generate a cover image via AI, thanks to Runware integration in the voice recorder. But it costs credits. A switch in the voice recorder header now allows disabling image generation on the fly. Transparency and control.

What does versionCode 30 represent for a solo developer?

Every Android build has a number. We're at the 30th. The previous 29 were alpha — builds for 12 testers who accepted bugs in exchange for exclusivity. Build 30 is the last before anyone can download TAMSIV from the Play Store.

It's a mundane number. But it represents the moment when "my app" becomes "an app." Where the code is no longer protected by the benevolent filter of beta testers. Where every bug is a potential 1-star review.

To put that in perspective: the previous quality sprint had already fixed dozens of issues. Build 30 is the culmination of two weeks of intensive polish, not just 48 hours. It's the final layer before going into production.

How to decide when to stop adding features?

The temptation for a solo developer is to always add more. One feature calls for another. The backlog never empties. And the bigger the app grows, the more each addition creates unforeseen interactions with the rest.

I applied a simple rule: if a bug can be encountered within the first 5 minutes of use, it takes priority over any feature in the backlog. This is what Marty Cagan calls the "reference customer test" — if your reference user cannot complete the basic journey without friction, nothing else matters.

This sprint taught me something: polish is not the enemy of progress. It's the opposite. Fixing 15 bugs on a single screen made the app more robust than any new feature. Users don't see commits. They see an app that works — or doesn't.

What is the workflow of a polish sprint in practice?

Specifically, here's how I organized these 48 hours:

1. Screen-by-screen audit: I opened each screen of the app on 3 different devices (small, medium, large) and noted every visual or functional anomaly.
2. Prioritization by impact: bugs visible in the first 5 minutes at the top, edge cases at the bottom.
3. Atomic commits: one commit = one fix. No catch-all commits. This allows for surgical rollback if a fix breaks something else.
4. Regression testing: after each fix, re-verification of adjacent screens. When you touch the architecture of a shared component, the domino effect is real.

This workflow is not spectacular. There's no new tech, no heroic refactoring. Just discipline and time spent using your own app like an average user.

Why is polish more profitable than features for a launch?

The numbers are clear. On the Play Store, apps with a rating below 4 stars lose up to 50% of their potential downloads. And the first reviews are decisive: they define the app's trajectory for the following months.

Adding a feature that impresses 10% of users but creates a bug for 5% of them is a bad trade-off. On the other hand, fixing 30 micro-bugs that potentially affect everyone is an investment with guaranteed returns.

This polish sprint touched the entire user journey: from onboarding to subscription management, including the core of the app — the voice recorder. And the difference lies in these 30 invisible commits.

Build 30 is ready. The app is cleaner, more stable, clearer than it has ever been. Next up is the general public.