Should I vibe code
Focus timer with app blocking, planning, and session analytics
The timer is four lines. The unbroken history across three devices is the product, and that's a sync engine.
?
Their verdict, the Pro (month-to-month) price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A countdown in a menu bar is an hour, and you should absolutely spend that hour — the neighbouring Serene entry says exactly that and means it. Session is a step harder because the countdown is not what people renew for. What they renew for is an unbroken record: a chart of every session they have finished, present on the Mac and the phone, still correct after a restart, a lid-close, a flight and a five-day gap. That is not a timer, it is a durable state machine plus a sync engine plus a browser extension for each of Safari, Chrome, Brave and Edge, plus a Slack token that can write your presence — and every one of those is a small, unglamorous, unfinishable-in-a-weekend piece. You will build the timer on Sunday and it will feel done. The parts that decide whether you are still using it in March are the ones you have not started: what a session does when the machine sleeps at minute nine, whether an abandoned session is recorded at all, and what happens the first time the history on your phone disagrees with the history on your laptop. There is also a quiet reason to keep the scope small. The moment you add sync you have built a server holding a minute-by-minute log of when you were and were not working, which is the most surveillance-shaped file you will ever generate about yourself, and you just gave it an API.
What actually breaks
not "if". the specific failures.
- The timer across sleep, which is the first real bug and the one that discredits the whole app. Count ticks and a closed lid either finishes the session instantly on wake or leaves it running until Thursday
- The history, if sessions are only written on completion. Every abandoned session disappears and your chart quietly becomes a record of the days you did not need the app
- Sync, in the specific way sync always breaks: two devices, one offline, both edited, and now there are two versions of Tuesday. Last-write-wins on a log is how you lose a week
- Browser blocking, which needs a separate extension per browser, each with its own review process, its own manifest version churn and its own way of failing silently on an already-open tab
- The Slack integration, which is an OAuth token that writes your workspace presence, stored on your laptop, refreshed by code you wrote once and will not look at again
- macOS permissions each September — Accessibility, Automation, Screen Recording — all of which app-level blocking depends on and any of which can be quietly revoked by an update
- The iOS half, which is not a port. Blocking on iOS means Apple's Screen Time frameworks and an entitlement, and the reporting sandbox will not hand usage data back to your app at all
- Migration day, months in. The history is the only irreplaceable thing here and it lives in one SQLite file that one bad schema change removes
Is that you?
the verdict is a default, not a law
- One machine, one user, one SQLite file, and no sync at all
- You want the timer and the log, and are honest that the streak is a motivator you will be able to edit
- Sessions are written at start and updated at end, so the record includes the ones you gave up on
- The blocking half is left out entirely, or delegated to something like SelfControl that already does it
- The plan requires the phone and the laptop to agree — that is the project, and it is much bigger than the app around it
- You are writing a browser extension per browser and expect to keep four of them working through manifest changes
- The session log leaves the machine for a dashboard, a leaderboard or a backup, because of what that log actually is
- You need iOS blocking, which is Apple's entitlement story and belongs to the Opal entry rather than this one
- A Slack or calendar token is going to sit in your app's storage without you having decided what its scope is
If you build it anyway
the checklist, then the prompt that enforces it
- Derive the timer from wall-clock deadlines, never from accumulated ticks, and write down what sleep, lid-close, restart, DST and a session crossing midnight are each supposed to do before building the UI.
- Insert the session row when the session starts and update it when it ends. An abandoned-session record is data; a missing one is a lie in a chart.
- Keep history in one plain SQLite file with a schema you version and a migration you test against a copy, because that file is the only thing here you cannot rebuild.
- Export to CSV or JSONL from day one and run it on a timer. This is a personal tool, which means nothing else is backing it up.
- Skip sync until the single-device version has survived a month. If you do add it, append-only events with device IDs and a deterministic merge — never last-write-wins over a shared row.
- If blocking is in scope, write the unblock path first and make it work with the app closed, and keep a never-block list containing your VPN, identity provider and authenticator.
- Scope any OAuth token to the single thing it needs — writing a Slack status is not reading a workspace — and store it in the system keychain rather than a config file.
- Keep it local by default. The value of not having a server is the value of the log you are then not storing anywhere.
I want a Pomodoro focus app for my own Mac: timed sessions, a history, and
optional app and website blocking. Build it in this order and push back where
noted.
1. Start with the session model and the clock. Wall-clock start and end
deadlines, never a tick counter. Before writing UI, tell me what happens on
sleep, lid close, force quit, restart, a timezone change and a session that
crosses midnight, and write a test for each.
2. Write the session row at start, update it at end, and keep a status field so
abandoned sessions stay in the data. I want the failures in my history.
3. Storage is one SQLite file in a documented location, with a versioned schema
and a migration tested against a copy of my real data. This file is the only
irreplaceable thing in the project — say so in the README.
4. Build export before analytics: CSV and JSONL, on a schedule, to a folder.
Nothing else backs this up.
5. Then the UI and the charts, which are derived and disposable.
6. Do not add sync. If I ask, explain what it means concretely: a server
holding a minute-by-minute record of when I was working, plus a merge
problem. If I still want it, model it as append-only events with device IDs
and a deterministic merge, never last-write-wins on a shared row.
7. If I ask for blocking, build unblocking first — a command that works with
the app closed and removes every system change it ever made. Keep a
never-block list with my VPN, identity provider and authenticator on it, and
fail open on any crash.
8. Refuse a system VPN profile, DNS override or local certificate authority for
browser blocking. Offer an extension, per browser, maintained forever.
9. Any OAuth token — Slack status, calendar — gets the narrowest scope that
works and lives in the system keychain, not a JSON file.
10. No telemetry, no crash reporting that ships session content, no account.
11. Out of scope, and say so: iOS, sync, Windows. Then tell me Session is $4.99
a month and that the cross-device history is most of what that buys.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
When you want it on the phone as well. Five dollars a month is buying the two halves you would not finish: an unbroken history that survives sleep, restarts and a second device, and blocking that works across four browsers because somebody maintains four extensions. It is also buying an adversary who is not you — the streak only motivates while you cannot quietly edit the database, and you can. If the phone is not part of it, build your own; a local Mac timer with an honest log is a genuinely competitive version of this, and the Serene entry next door argues that case in full.
$4.99/mo is cheaper than your weekend.
One SQLite file and a CSV export on a schedule is the entire exit, which is the compensation for everything this page says you will not finish. Keep sessions as rows with a start, an end, a status and a label, and let every chart, streak and summary be derived — then the app is disposable and the year of history is not. If you ever added sync, the thing to get out is not the settings but the event log, and the thing to get rid of is the server copy, because what it holds is a record of your working hours that nobody, including you, has a use for after the project ends.
Cross-platform Pomodoro app with configurable sessions and notifications, still receiving commits.
Local-first automatic time tracking with an extensible event model and no server in the design.
Questions
Serene is SHIP IT and this is DEMO ONLY. They look like the same app.
The difference is what each one is for. Serene was a single-machine planning-and-blocking tool and it no longer exists, so the entire question is whether to build it — and at that scope you can, comfortably. Session sells continuity: the same history on the Mac, the iPhone and the iPad, plus blocking across four browsers. Those are the parts a weekend does not reach, and they are precisely the parts that keep people subscribed.
Can I just skip sync and keep it on one machine?
Yes, and that is the shipItIf case at the top of this page. A menu-bar timer, sessions written to SQLite at start and updated at end, a chart, an export on a timer — that is a good Sunday and a tool you will genuinely use. The verdict is for the product Session actually sells. If you build the single-device version and never add the second device, you have quietly moved yourself into the band above.
What is the bug that will actually ruin it?
The clock across sleep. Counting ticks feels natural and works perfectly on your desk, then you close the lid at minute nine and open it at 4pm, and the app either declares the session complete or leaves it running for six hours. Either outcome puts a wrong row in the only dataset the app exists to produce, and once you have stopped trusting the history you have stopped opening the app.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Serene's website now redirects to the agency that built it. You can't buy this one, so you may as well build it.
Apple hands you the blocking API, then refuses to let your own app read the usage behind it.
A blocker only works if it is harder to remove than the urge to remove it. That is a description of malware.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice