Pomodoro RPG

The idea started with a problem I kept having: I'd set a Pomodoro timer, do one session, then immediately tab over to Twitter while telling myself "I'll check real quick." Three hours later, no second session.

Every Pomodoro app I tried was ruthlessly functional. Clean UI, timer ring, done. Nothing to come back to. So I asked a dumb question: what if completing sessions made you feel like you were playing an RPG?

That was six months ago. The result is Pomodoro RPG — a Flutter app where every focus session earns EXP, levels up your character, and progresses you through a 40-class skill tree loosely inspired by classic JRPGs.

The technical bet that paid off: local-first

The biggest architectural decision was refusing to build a backend for v1.0. No accounts, no sync, no server costs, no cold-start latency. All state lives in SharedPreferences and a handful of JSON files on-device. This sounds limiting until you realize 95% of what makes a progression game feel good — leveling up, unlocking classes, seeing your stats grow — is purely local. The constraint forced clarity: every feature had to justify itself without a server.

State management is Riverpod, which I initially resisted (too much boilerplate) but now wouldn't trade. The data flow is clean: PomodoroService emits a session-complete event → CharacterService computes EXP and stat grants → QuestManager checks quest progress → SaveService persists everything → Riverpod watchers rebuild the UI. One direction, no surprises.

The part that took three times longer than expected: the class system

I initially sketched "four character classes." Then I added branching paths at tier 3. Then prestige resets. Then cosmetic IAP skins. The final count is 40 playable classes across four paths (Scholar, Warrior, Monk, Rogue), each with stat profiles that actually reward the session habits that match the class — Warriors gain more EXP from long streaks, Scholars from output consistency, Rogues from skipping breaks efficiently.

There's also a weekly boss system. Seven bosses named after the seven deadly sins (Acedia for sloth seemed too on-the-nose for a productivity app, but I kept it), each requiring a number of sessions to defeat before Monday midnight. Beating them drops EXP, gold, and optional cosmetic skins. I did not plan this feature. It emerged when I realized the app had no reason to open it specifically today.

What I'd do differently

Start with the retention loops. I built the core timer in week one and it worked fine in week one. The features that make people come back — the boss battles, the near-miss EXP callouts, the streak shields — came in phases six through eight and required retrofitting the data model. If I'd designed for them up front, the code would be half as tangled.

Also: localization from day one. Adding Vietnamese halfway through meant auditing every screen for hardcoded strings. I found three in the last week before submission.

Where it's at now

App is in final QA, submission imminent. If you focus for 25 minutes at a time, this might be the most elaborate accountability partner you've ever used.