I built a bedtime-coach app solo and shipped it in 6 languages, here's what I learned

Tiny Spark — Tue, 11 Aug 2026 13:27:37 +0000

I just published Dormeil, a bedtime-routine coaching app for Android, built entirely solo. Sharing a few honest lessons for anyone building a consumer app on the side.

What it does:

Calculates your ideal bedtime from your wake-up time and how much sleep you need (weekday and weekend).
An evening ritual: calming sounds played for as long as you want to help you fall asleep — you can even add your own sounds.
A configurable gentle alarm (snooze, gradually rising volume, soft natural sounds).
A "garden" you grow by respecting your bedtime and earning points — light gamification to stay motivated.
Sleep stats and a monthly journal. Free, with an optional Premium mode (no ads, multiple sounds at once, PDF/CSV journal export).

A few things I'd do again:

Localizing early. I shipped in French, English, German, Spanish, Italian and Portuguese from day one instead of bolting languages on later. More upfront work, but each locale is effectively its own low-competition mini-market on the Play Store.

Keeping the feature set tight. I stuck to a few clear pillars — bedtime calculation, ritual, gentle wake-up, motivation garden — so the app stays explainable in one sentence.

A few things I'm still figuring out:

Marketing on close to zero budget. No paid ads, no big social following — leaning entirely on ASO, SEO content on my own site, and genuine community participation.

Naming and trademark timing. "Dormeil" is a made-up French word (a play on "réveil", meaning alarm/wake-up). Invented names are strong but easy for someone else to register first if you wait too long — still weighing when it's worth the cost at this stage.

If you're curious, Dormeil is live on the Play Store: https://play.google.com/store/apps/details?id=com.tinyspark.dormeil — happy to answer questions about the build, the localization approach, or anything else. Feedback very welcome.

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

Tiny Spark — Wed, 15 Jul 2026 20:13:50 +0000

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.

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.
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.
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.
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.
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.

DEV Community: Tiny Spark

I built a bedtime-coach app solo and shipped it in 6 languages, here's what I learned

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