Note Timer

Purpose

Wanted an app where interval timers lived inside a note-taking experience — hear a bell while putting in reps for whatever exercise or focus session you are doing, and capture notes along the way. The vision was essentially a Pomodoro timer fused with a journal: set goals, work in intervals, take notes during each interval and each break, then review everything grouped by date.

Stack

What I Learned

• This project had a detailed feature spec before it had a working MVP — and that is exactly why it stalled. The spec included: default 25-minute timers, interval session creation (2, 4, 6, or 8 intervals), overarching goals plus sub-goals per interval, break sections with their own note areas, a hamburger menu with archives grouped by date, advanced options for customizing interval time, break time, sounds, self-grading, and post-session editing. That is not a feature list — that is a product roadmap for a funded startup. For a side project, it was a death sentence.
• The contribution guidelines were sharp though: pull requests denied if files do not follow naming conventions. Changes to someone else's files require precise explanations of why. New features and classes always go in new files. BLoC states and events are exempt but limited to one abstract class per file. These rules show an early understanding that code organization is a team communication problem, not just a personal preference.
• BLoC (Business Logic Component) pattern in Flutter separates UI from business logic through streams of events and states. Events go in, states come out, the UI rebuilds reactively. It is verbose but enforces a clean separation that scales well in larger apps. The one-abstract-class-per-file rule was an attempt to prevent BLoC state files from becoming god files — a real problem in BLoC codebases.
• The known bugs list is revealing: "Notes are not being created" (critical, checked off — fixed), "Notes are listed as though they are all the same note" (data modeling bug — likely a missing unique ID or a shared reference). These are classic state management bugs: objects that should be distinct sharing an identity, or creation events that fire but do not persist. Every developer has debugged this exact class of issue.
• The Pomodoro technique (work 25 minutes, break 5 minutes, repeat, long break every 4 cycles) is fundamentally a state machine: Working → Short Break → Working → Short Break → Working → Short Break → Working → Long Break → repeat. Recognizing this connects directly to the Tasks page on this site — every structured workflow is a state machine, and the timer is just the clock that drives the transitions.

Key Insights

• Scope creep is not adding one more feature — it is confusing the spec for the final product with the spec for the first version. This project had the right final vision (interval timers + notes + goals + archives + customization). It had the wrong v1 scope. The v1 should have been: one timer, one note, save when done. Ship that, use it, learn what is actually needed, then layer on complexity. Instead, the spec grew until the project collapsed under its own ambition.
• The Pomodoro method works because it externalizes willpower. Instead of relying on internal discipline to stay focused ("I should keep working"), you externalize the decision to a timer ("the bell has not rung yet"). This is the same principle as automated tests (externalize quality checks), linters (externalize style decisions), and CI/CD (externalize deployment discipline). Humans are bad at sustained willpower. Systems are not.
• This was attempt number three at the timer concept (after Intervolition Flutter and the Timer app). A later version eventually shipped as Intervalition on the App Store in native Swift. The pattern is now undeniable: some ideas require multiple failed implementations before the right version emerges. The failures are not wasted — they are the R&D phase that most people do not see behind a shipped product.
• The merge of note-taking and timers is still a compelling product idea. The insight that your best thinking happens under time pressure with a structured container (goals → intervals → notes → review) is supported by research on flow states and deliberate practice. Someone will build this well. The spec in this repo is still a valid starting point.