5 mistakes I made building my first Android app (and how I fixed them)

I'm not a developer. I build Android apps on evenings and weekends using AI coding assistants (GitHub Copilot and Claude). My latest app, ScorePop, is a free score counter for board games — you tap + or − to track points. Simple concept, but getting it right taught me a lot.
Here are 5 mistakes I made and how I fixed each one.

1. The app crashed when users rotated their phone
   I had a popup (a BottomSheet) that received a direct reference to a piece of the screen. When the user rotated their phone, Android destroys and rebuilds the entire screen — but the popup still pointed to the old, destroyed version.
   The fix: instead of passing screen elements directly, I used Android's FragmentResult API to send data back safely. The popup sends a message, the main screen listens for it. No direct connection, no crash.
   Lesson: on Android, never pass screen elements between components. Use messages instead.

2. The timer leaked memory when the app was closed
   ScorePop has a stopwatch feature. My timer kept running in the background even after the user left the app. It wasn't a visible crash — it was a silent memory leak that drained battery.
   The fix: I added code to pause the timer when the app goes to the background, and resume it when the user comes back. And when the app is fully closed, everything is cleaned up.
   Lesson: anything that runs on a loop (timers, animations) needs to be tied to the app's lifecycle. If the screen is gone, the loop should stop.

3. I put an ad in the worst possible place
   My original flow: user taps Share → a full-screen ad plays → then the share screen opens.
   I thought it was smart — monetize a high-traffic action. In reality, I was punishing users for trying to show their friends my app. That's free marketing I was blocking with an ad.
   The fix: I moved the ad to after saving a game — a natural pause where the user is between games, not mid-action. Sharing is now instant, zero interruption.
   Lesson: monetize transitions (between games), not actions (sharing, saving). If the user is doing something social, get out of their way.

4. The main screen had too many buttons
   Version 1 had 6 tiny buttons (32 pixels each) crammed into the top bar. Save, share, new game, timer, load, menu — all visible at once. Functional? Yes. Usable during a heated board game? No.
   The fix: I kept 3 buttons in the top bar (menu, save, and a ⋮ overflow menu). The other 4 actions moved inside the overflow menu. I also removed a hidden "add custom points" section from each player card and replaced it with a simple tap on the score number.
   Result: each player card shrank by 40%. Four players now fit on screen without scrolling.
   Lesson: the features you remove matter more than the ones you add. A clean screen beats a powerful one.

5. The app was bigger than it needed to be
   For months, I shipped the app without enabling Android's built-in code optimizer (R8/ProGuard). That means the final app included unused code from every library, uncompressed.
   The fix: two lines in the build configuration:
   isMinifyEnabled = true
   isShrinkResources = true
   The app got smaller, faster to install, and the code was obfuscated (harder to reverse-engineer).
   Lesson: enable R8 in release builds. It's free performance.

What I'd add if I started over

Undo from day one. Users make scoring mistakes constantly. I added an undo stack later, but it should have been there from the start.
Haptic feedback. A subtle vibration on every +/− tap makes scoring feel satisfying. Tiny detail, big impact.
Celebration effects. When you save a game, confetti rains down and the winner gets a trophy animation. People screenshot it and share it. It's free marketing.

Try it
ScorePop is free on Google Play — search "ScorePop". If you're building your first app too, I'm happy to answer questions in the comments.