I recently shipped TinyHab, an ADHD-friendly habit tracker for iPhone.
The idea was simple: most habit apps look clean on day one, but they become stressful the moment you miss a day. I wanted to build something calmer. Something focused on today, small wins, reminders that actually work, and a recovery path when routines fall apart.
So I built the full product myself: the iOS app, backend, landing page, admin panel, push notifications, subscriptions, App Store setup, and the release process.
App Store link: https://apps.apple.com/app/tinyhab-adhd-habit-tracker/id6770136917
The Stack
TinyHab is built with:
- Flutter for the iOS app
- Django for the backend API and admin panel
- PostgreSQL for the database
- Firebase Auth / Cloud Messaging for auth support and push notifications
- Apple Sign In and Google Sign In
- RevenueCat for App Store subscriptions
- Dokploy + Docker for deployment
- Django Admin for managing users, campaigns, tokens, and notification logs
I like this stack because it lets me move fast without giving up structure. Flutter gave me a clean app surface, Django gave me a reliable backend and admin panel, and Firebase/RevenueCat handled the parts that are painful to rebuild from scratch.
What I Wanted the App to Feel Like
TinyHab is not trying to be a loud productivity app.
I wanted the app to feel quiet and practical. The core flow is:
- Open the app
- See what matters today
- Mark a habit done
- Move on
No guilt-heavy streak system. No overwhelming dashboard. No complicated setup before the user gets value.
The app includes habit scheduling, daily progress, reminders, insights, profile settings, App Store subscriptions, home screen widgets, and a small admin system behind the scenes.
The Hardest Part Was Not the UI
The hardest parts were the production details.
Apple Sign In had to work from both login and registration. Push notification tokens had to be saved correctly after permission was granted. Firebase Cloud Messaging had to be connected to APNs correctly. App Store subscriptions had to sync with the backend. The backend needed enough logging so I could see what actually happened when something failed.
One example: push notifications were not just "install Firebase and done." I had to handle APNs token timing on iOS, register the FCM token with the backend, store device tokens per user, connect Firebase to the correct APNs key, and test direct backend sends from production.
When it finally worked, I could send a notification from the admin panel and see it arrive instantly on the device. That was a good moment.
App Store Review Was a Real Test
The first submission did not go through.
Apple rejected the app because the Continue with Apple button was unresponsive in one flow. The login screen was fine, but the registration screen had a button that looked ready and was not wired to the Apple auth flow yet.
That was a useful reminder: App Review will test the product like a real user, and any visible control needs to work.
I fixed the Apple Sign In flow, checked the release build again, fixed a few production issues around push token registration and profile plan display, rebuilt the IPA, uploaded a new build, and resubmitted.
The next review passed.
What the Backend Handles
The Django backend is not just a simple auth API.
It handles:
- User accounts and auth sessions
- Habit CRUD
- Habit completions
- Reminder settings
- Device notification tokens
- Push notification campaigns
- Push notification logs
- Daily summaries
- Subscription state
- Legal documents
- Landing page content
- Admin workflows
I also added admin tooling so I can inspect device tokens, see failed push messages, send campaigns, and debug real user issues without guessing.
That saved a lot of time during launch.
What I Learned
Shipping a real mobile app is mostly about the small details that do not show up in screenshots.
The UI matters, but production readiness matters more:
- Does Apple Sign In work in every auth flow?
- Does the app still work after a fresh install?
- Are push tokens saved after permission changes?
- Can the backend send to the latest device token?
- Can I see why a push failed?
- Does the App Store build match the version I think I uploaded?
- Does the landing page point to the live App Store URL?
None of these are exciting individually, but together they decide whether the app feels real.
Why I Built TinyHab
I built TinyHab because I wanted a habit tracker that is easier to come back to after a bad day.
Most habit apps are optimized for perfect consistency. TinyHab is designed for imperfect consistency: missed days, low energy, friction, and restarting without shame.
That product direction shaped both the design and the engineering. The app needed to be simple on the surface, but reliable underneath.
Final Thoughts
This was a full-stack mobile build from zero to App Store approval.
I worked across Flutter, Django, Firebase, APNs, RevenueCat, Docker deployment, admin tooling, and App Store Connect. The result is now live on the App Store, and I am continuing to improve it based on real usage.
If you are building a mobile app, my biggest advice is simple: test the boring production flows early. Login, registration, push notifications, subscriptions, release builds, and admin visibility are where most launch problems hide.
TinyHab is live here:
https://apps.apple.com/app/tinyhab-adhd-habit-tracker/id6770136917
