Clockify

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me time tracking that replaces Clockify: timers, timesheets, projects, rates and the reports that turn hours into money.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode
- Caddy in front

THE DATA MODEL
- users: id, email, name, role, hourly_cost_cents, is_active, created_at
- clients: id, name, currency, notes, archived_at
- projects: id, client_id, name, code, colour, is_billable, budget_kind, budget_amount, budget_hours, archived_at
- tasks: id, project_id, name, is_billable, estimate_hours, archived_at
- rates: id, scope, scope_id, user_id, hourly_cents, currency, effective_from — a rate has a start date, and an entry is billed at the rate in force when the work happened. Changing a rate must never restate last quarter
- entries: id, user_id, project_id, task_id, description, started_at, ended_at, duration_seconds, is_billable, is_locked, invoice_id, tags_json, source, created_at, updated_at
- entry_revisions: id, entry_id, field, old_value, new_value, changed_by, changed_at — an edited timesheet in an append-only log, which is what makes it defensible
- approvals: id, user_id, period_start, period_end, status, submitted_at, reviewed_by, reviewed_at, note
- Every instant in UTC. Every amount in integer cents with a currency

TIME, WHICH IS SUBTLER THAN IT LOOKS
- An entry is two instants, and the duration is derived. Never store a duration alone, or a day with a clock change will not add up
- A running timer is an entry with no end. One running timer per user, enforced in the database with a partial unique index, not by hope
- A timer left running overnight is caught: warn at a configurable length, and offer to trim it to the last activity rather than silently discarding it
- Manual entries and timer entries are the same row with a different source, so reports never have to look in two places
- The week starts where the workspace says, and the day boundary is the user's zone

TRACKING
- Start and stop from anywhere in the interface, with the project, task and description
- A weekly timesheet grid: rows of project and task, columns of days, type hours into cells
- Duplicate yesterday, continue a previous entry, and split an entry in two
- Idle detection where the browser can tell, offered as a suggestion, never applied automatically
- Bulk edit by selection, with every change written to the revision log

BUDGETS AND ALERTS
- A budget per project in hours or money, recurring monthly or for the whole project
- Progress shown as it is consumed, and an alert at configurable thresholds to the project's owner
- The difference between billable and cost is kept: a user has a cost rate and the project has a billable rate, and margin is the gap. A tool that tracks only one of the two cannot answer whether the work was worth doing

REPORTS
- Group by any of client, project, task, user, tag or day, and filter by all of them
- Summary, detailed and weekly views
- Billable and non-billable, amounts, and margin
- Export CSV, and a PDF for a client that shows exactly what was worked on
- Every report is computed from entries at query time. No stored totals, ever — a total that disagrees with its rows is the failure this category is prone to

APPROVAL AND LOCKING
- Submit a period, a reviewer approves or returns it with a note
- Approved periods are locked: an entry inside one cannot be edited without an explicit unlock, which is logged
- Locking is what makes the hours usable for payroll and for an invoice, and it is the feature homemade trackers never have

INVOICING HANDOFF
- Select approved billable entries and mark them invoiced with a reference, so nothing is billed twice
- Export the selection in a shape an invoicing tool can read

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, SMTP_URL
- Migrations on boot, each once
- Nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
Rates with effective dates, and the revision log. Build those before anything visible, and test a rate change in the middle of a month against a report of the previous one. Hours are a record people are paid from and argued over, and a tracker that quietly restates history is a tracker nobody can trust twice.

Give me the repository, migrations, .env.example, a seed workspace with three clients and a month of entries, and a README with deploy steps behind Caddy.