SMF·RIZE
Can a prompt replace Rize?
Time tracking — focus metrics and session coaching
Exhibit tracking slip
Verdict
Rize turns passive capture into two numbers a person can act on: how long your uninterrupted stretches are, and what time of day you are sharpest. Both are computations over data you already have on your own machine, with no service, no key and no dataset behind them — so this is a yes, in a sitting. What the subscription buys is polish and the tuning of the session-detection thresholds, which is real but is not a dependency.
Exhibit A — The prompt
Received on31.07.2026Build a focus-quality tracker. The output is not a dashboard, it is two numbers and one suggestion.
Stack: a local recorder plus a dashboard, SQLite, no network. Build on an existing open-source capture layer if you can.
From the raw activity stream, derive sessions:
- A session starts when activity in one category persists past a minimum length.
- A switch to a different category shorter than a configurable tolerance is an **interruption** — it is counted but does not end the session, which is what makes this measure meaningful. A longer switch ends it.
- Store per session: category, start, end, and the interruption count.
The two numbers:
1. **Median uninterrupted stretch** — the median run of activity within sessions between interruptions. Median, not mean, because one four-hour Sunday ruins a mean.
2. **Peak focus window** — bucket the last four weeks of session time by hour of day, weight by uninterrupted stretch length, and name the two-hour window that scores highest.
The daily suggestion, exactly one, chosen by a small set of explicit rules you can read in the code — for example: if today's interruption rate is above the four-week median, name the application that caused the most interruptions; if the peak window contained meetings, say so and name the meeting hours; if no session reached the minimum length all day, say that plainly. Never generate more than one, and never generate a vague one.
Break tracking: detect gaps over a threshold as breaks, show breaks taken per working hour, and flag a day with a long continuous stretch and no break rather than congratulating it.
Dashboard: today's sessions as a timeline with interruptions marked, the two numbers with their four-week trend, and the suggestion at the top.
Privacy: pause control, title redaction per application, raw retention window, wipe command.
Write tests for interruption-versus-session-end at the tolerance boundary, for median computation on an even count, and for the peak-window calculation with fewer than four weeks of data (it must decline to answer rather than guess).
Do not build calendar integration, cloud sync, or a team view.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 the tuned session-detection thresholds, which you now own
- B.2 the polished native application and its menu-bar presence
- B.3 calendar integration that labels a session with the meeting it collided with
- B.4 cross-device tracking
- B.5 the break reminders driven by the vendor's own model of fatigue
Prior art
Exhibit C — Why people still pay: session detection quality
Because the value is in the thresholds being right without being fiddled with, and because a nagging tool only works if it is not one you can edit at 3pm when it annoys you.
Questions
Why median rather than average uninterrupted time?
Because the distribution is heavily skewed — a handful of long stretches and many short ones — and the mean flatters you on exactly the weeks you were most scattered. The median moves when your ordinary day changes, which is what you want to see.
Why only one suggestion a day?
Because a list of five is a dashboard, and dashboards get skimmed. One specific sentence naming one application or one hour is something you can act on before lunch.
What makes tuning the thresholds harder than it sounds?
The interruption tolerance. Too short and every glance at a chat window ends a session, so nothing ever looks focused; too long and a twenty-minute detour counts as deep work. Expect to adjust it for a week, and that adjustment is exactly what a paid tool has done for you.
Why refuse to compute the peak window with little data?
Because two days of data will confidently name an hour, you will believe it, and it will be noise. Declining to answer until there is enough history is the difference between a measurement and a horoscope.
Related tools
Receipt