Engineering
Why Time Tracker Reminders Should Nudge You, Not Start the Clock
Time tracking reminders fail in two directions. They stay silent, so you reconstruct the afternoon from chat logs. Or they behave like a manager: a popup that implies the software already knows you were idle, already knows you switched apps, and is about to write your timesheet for you.
MinuteShark is a time tracker for consultants, not a compliance device for departments. When we designed reminders, the product question was not “how do we catch people?” It was “how do we tap someone on the shoulder without inventing billable hours?”
The contract we shipped: a reminder asks you to look at the clock. It does not start a timer, stop a timer, or create a time entry. If you log forgotten time later — including with MinuteShark AI — that still waits for a confirmation card.
Why we refused idle detection as a “helpful” default
The enterprise pattern is familiar. Watch the mouse. Watch the foreground app. If the human looks away, pause the clock. If they come back, maybe resume it. Put a screenshot in the file so a manager can argue later.
That architecture is honest about its buyer. The buyer is not the person doing the work. The buyer wants proof of presence. Freelancers and tiny consulting teams are buying the opposite: a client → project → task hierarchy, a day they can still steer, and an invoice they can defend. Presence theater is not that product.
Idle detection also lies in the other direction. Reading a brief, thinking through an architecture decision, or sitting on a client call with the laptop lid half-closed can look like “idle.” Auto-stopping then auto-starting would write a timesheet that is confident and wrong. We would rather miss a nudge than mint a false interval.
Reminders are not surveillance with nicer copy. If the software infers that you worked, it is already in the wrong business. MinuteShark reminders are a prompt to you. They are not a claim about you.
What should a reminder be allowed to do?
We gave reminders three jobs, and we kept them boring on purpose.
- Average duration. If this task usually runs about 50 minutes on your workspace, ping when you are still on the clock past that shape of a session. The average is a hint, not a timesheet line.
- A specific time of day. “Ask me at 5:15 whether the timer is still telling the truth.” Consultants have edges: school pickup, a standing standup, the moment the cafe wifi dies.
- A regular interval. Every 90 minutes, look up. Interval reminders are for people who context-switch across two clients before lunch and forget which task the sidebar is pinned to.
None of those jobs start the one running timer we enforce across web and mobile. None of them close a task. None of them round 10 minutes up to 12. Rounding, if you turn it on, is a billing policy you chose. A reminder is not a policy engine.
If the running timer is already visible — sidebar elapsed time, task name, client, the option to click the clock and edit start/end — a reminder is backup, not the primary UI. People who live in the dashboard do not need a nanny. People who left a timer on through lunch do.
Why the ping has to live on the device
MinuteShark’s web app and iOS + Android apps are the same product family. Time data syncs through your account so the workspace you open on a phone is the workspace you left on a laptop. Reminders are a different layer.
A cloud worker that pings you because a server thinks you should still be working recreates the manager problem in infrastructure. It also fails in the places consultants actually work: basement conference rooms, trains, captive-portal hotel wifi. Local notifications let the device ask the question even when the API is briefly unreachable. The reminder is “look at your timer.” The write still happens later, when you are back in the app, on a task you can see.
That split matters for trust. Firebase is how the catalog and the entries stay consistent across devices. Local notifications are how we avoid pretending a server has a better view of your afternoon than you do. iOS Live Activities can show a running timer on the Lock Screen; that is status, not a reminder policy. Different UI, same rule: the OS may display elapsed time. It does not get to invent a client, a project, or a duration.
The reminder contract (what we will not ship)
- No screenshot sampling. No keystroke story. No “you were idle, so we paused you.”
- No auto-start when you open a repo, a Figma tab, or a calendar event. Calendars are not timesheets; app usage is not a client.
- No silent AI mutate. If you say “I forgot to log 30 minutes on yesterday’s standup task,” you still get a proposal card to edit and confirm.
- No second concurrent timer started “just in case.” One running timer. A reminder can ask you to switch; it cannot dual-wield clocks.
If a specialized consulting workflow needs something we do not ship, we build custom solutions for specialized needs. We do not fake an integration marketplace so the reminder can scrape Slack and call it billable.
How this sits next to the rest of the day
Reminders are optional. So are dashboard widgets: starred tasks, a private notes field, to-do lists, a Pomodoro focus clock, History. The Pomodoro interval is for attention. The sidebar timer is for money. Mixing those two clocks is how people send a 25-minute invoice line for a 90-minute implementation block, or the reverse.
If you want the longer argument that this is not an employee monitor, we already wrote why time tracking tools should not feel like surveillance. If you want the product rule about a single clock, see why one running timer beats three open clocks. Widget layout lives in the dashboard widgets guide.
The engineering bet is small: a nudge you can ignore is better than a mutation you have to litigate with a client. Time data should help you think, not comply. Reminders either serve that sentence or they do not ship.