Why Closing a Task Should Stop the Clock Without Erasing the History - MinuteShark

Engineering

Why Closing a Task Should Stop the Clock Without Erasing the History

Most project tools treat “done” as a cleanup job: archive the card, grey out the row, eventually delete it so the board looks tidy. That is a terrible model for a timesheet. When a freelancer closes a task, the clock has to stop — and the history has to stay. Otherwise Friday’s invoice is a reconstruction, not a record.

MinuteShark tracks time on a task. The hierarchy is Workspace → Client → Project → Task → Subtask. Closing or locking a task is the billing stop we actually shipped: no further tracking on that leaf of work, while reports, History, and invoices can still see what already happened. This is not a kanban ritual.

The product bet: delete is how you lose a timesheet. Close/lock is how you refuse new time without pretending the week never existed. We would rather a closed task look “in the way” in search than a missing row on a PDF.

Why “done” in a board is not a billing event

In a process tool, moving a card to Done is a status for other people. In a freelance workspace, the dangerous moment is the next timer. Someone — you, a teammate, MinuteShark AI after a confirmation card — will search for “Homepage” at 4:40 p.m. and hit play on whatever still looks open. If the homepage was supposed to be finished Tuesday, that play icon is how Wednesday leaks onto an invoice line the client already approved.

We already wrote about why one running timer beats three open clocks. Closing a task is the other half of that constraint. One timer is the runtime rule. A closed task is the catalog rule: this leaf is not a legal place to start time anymore. Projects stay open, because a website redesign is not “done” when homepage mockups are. MinuteShark AI can close and open tasks; it does not close projects. That split is intentional.

Delete looks cleaner in a demo. Delete also orphans the question “what did we actually bill for Homepage mockups?” Time entries that vanish are not a rounding problem. They are a forensic problem. Duplicate and delete already have safeguards in the product. Close/lock is the everyday stop, not the emergency wipe.

What we actually persist when you lock a task

Lock/close is a workspace mutation, not a local cosmetic. History still lists the entries. Reports still pivot by that task. Invoices generated from a report can still include the time. The original duration of each entry stays stored; if rounding is on, the BILLABLE figure is a derived view, not a rewrite of the past.

Assignees live on leaf work, not on a closed parent

Tasks with subtasks cannot have an assignee. The assignee is on the leaf. That rule is easy to ignore in a status-driven PM suite, where a parent epic owns a person and the children are decoration. In MinuteShark, time belongs to the task you start. If you close a parent that still has open subtasks, you have not finished the work — you have lied to the catalog. The implementation has to keep the leaf as the thing you lock when a revision round or a phase is actually over.

That is also why we did not invent “close the project and cascade-lock every task.” Cascades feel powerful and bill badly. A consultant closing “Website Redesign” because the homepage shipped would silently block support hours that still belong on a sibling task. Humans close the leaf they mean. AI can propose a close; nothing is written until you confirm the card.

Search and the one-timer rule still have to honor the stop

Dashboard search is how most timers start: type, play. If a closed task still offers a play icon, lock is theater. If it disappears from Algolia entirely, you cannot answer “what was that task called when we billed it?” The honest index is: findable, not startable. Create-from-search still has to make a new task when the work is genuinely new — a R2 round, a support bucket — instead of resurrecting a locked R1 by accident.

If a timer is already running on a task you then close, the runtime and the catalog disagree until we stop that timer. One running timer is a cross-platform Angular service, not a per-device courtesy. Closing a task is not idle detection, not a screenshot, and not a silent rewrite of elapsed time. It is a person saying this leaf should not accept more clock. The sidebar should not keep counting on a leaf that just became illegal.

How we tell if the stop is working

We do not grade lock/close on how hidden the task becomes. We grade it on whether a teammate can fail to add Wednesday to a Tuesday-complete line item.

  • Does a confirmed AI “start a timer on Homepage mockups” fail closed if that task is locked, instead of opening it as a convenience?
  • Does a report for last month still include time that landed while the task was open?
  • Can a Regular User lock their own work without an Admin ceremony?
  • Does re-opening require the same confirmation posture as any other mutation — especially from chat?

If those answers drift by platform, consultants will keep a zombie task named “Homepage FINAL v3” forever, which is how timesheets become folklore.

What we left out on purpose

We do not auto-lock from inactivity. We do not watch the screen. We do not close a task because a Pomodoro ended. Those products exist for managers. MinuteShark’s stop is explicit, the same way a time entry is explicit. Getting started is still Add Client → Add Project → Add Task → Start Task. Closing is the matching end of that sentence, not a workflow engine.

We also do not treat lock as accounting. Cost profiles, rounding, and invoice files live on other surfaces. A closed task simply stops being a place to put more minutes. The features list keeps timers, reports, and invoices as separate doors into the same hierarchy. Mixing “mark done” with “mark paid” would look integrated and bill like a mess.

Decide whether “done” means hide, delete, or refuse new writes. For anyone who invoices from time, refuse new writes. Keep the document. Let History stay boring.

Previous Post Back to Blog Next Post