HourStack

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 a planning calendar that replaces HourStack: I block out what I intend to do, and afterwards I can see what actually happened on the same grid.

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
- projects: id, client_id, name, colour, is_billable, archived_at
- tasks: id, project_id, name, external_ref, estimate_minutes, status
- blocks: id, user_id, project_id, task_id, title, planned_date, planned_start_local, planned_minutes, position, carried_from_block_id, created_at — the plan
- entries: id, user_id, block_id, project_id, task_id, started_at, ended_at, duration_seconds, notes, source — the actuality
- A block may have no entries, and an entry may have no block. Both cases are real and both are informative: work planned and not done, and work done and never planned
- integrations, external_items: tasks mirrored from another tracker
- Every instant UTC, every plan a local date and time with the user's zone

THE ONE IDEA
- The week is a grid of days. You drag a task onto a day and give it a duration; that is the plan
- As the week happens you track time against those blocks, and the same grid fills in behind the plan
- The value is entirely in the comparison: planned two hours, took five. A tool that only totals hours cannot tell you that, and a calendar that only plans cannot either
- So both must be visible at once, on the same block, at a glance. Design that view first and let everything else follow from it

PLANNING
- Drag a task from a backlog list onto a day, or create a block directly
- Resize a block to change its planned duration, drag to move it between days
- A daily capacity per person, shown as a bar filling: planned 7 of 6 available hours is a warning before the day starts rather than a disappointment after it
- Recurring blocks for standing commitments
- Anything unfinished at the end of a day is offered for carrying forward, with the carry recorded — a task carried five times is telling you something

TRACKING
- Start a timer on a block with one click, or log time against it afterwards
- One running timer per person, enforced with a partial unique index
- An entry is two instants and the duration is derived
- Time can be tracked against a project with no block at all, and that lands in the day as unplanned work, visibly distinct. Unplanned work is the most interesting thing this tool measures

PULLING IN TASKS
- Adapters for the trackers you already use: fetch tasks assigned to you, with their identifier, title, project and status
- The external identifier is the link, never the title. A renamed task must not orphan a week of plans
- Read-only by default; optionally write the tracked total back
- Each adapter is a small module with a fixture and a test, because these break when the host changes and a failing test beats a mystery

THE COMPARISON, WHICH IS THE REPORT WORTH HAVING
- Planned against actual per block, per task, per project, per day, per week
- The ratio, and its distribution — 'we estimate at about 60% of reality' is a fact you can plan with, and it takes a month of data to learn
- Estimate against actual per task, so estimates get better
- Unplanned time as a share of the week
- Carried-forward count per task
- Everything computed at query time from blocks and entries. No stored totals

CAPACITY AND TEAMS
- A team view: the week's grid per person, with each person's capacity
- Who is over-planned before the week starts, which is the only moment the information is useful
- Permission to see others' plans is explicit, and time entries stay the person's own

EXPORT
- CSV of blocks and entries with everything needed to reconcile them
- A weekly summary suitable for a client or a manager

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

WHAT MATTERS MOST
The grid showing plan and actual together, and the unplanned-work case. Build that one screen and use it for three weeks of your own work before adding anything. The insight this tool sells is uncomfortable and specific — you plan about twice what fits — and it only arrives if the comparison is in front of you every day.

Give me the repository, migrations, .env.example, a seed week, and a README with deploy steps behind Caddy.