ClickUp

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 the work tool I actually need instead of ClickUp — and start by noticing what the verdict means.

What you are paying for is **breadth bundled into one seat**: tasks, docs, forms, goals, whiteboards, time tracking. Almost nobody uses all of it. The honest move is to identify the two or three you genuinely use and build those well, because a narrow tool that fits beats a broad one you fight. Rebuilding the whole platform is a year and there is no reason to.

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

FIRST, THE SCOPE DECISION
- List what your team actually opened in the last month. Tasks and one view type is usually most of it, with docs a distant second
- Build that. Add a second thing only when somebody misses it twice
- Write this decision in the README, because the temptation to reproduce every tab is what turns a fortnight into a year

THE DATA MODEL
- spaces, folders, lists — a three-level hierarchy above the task. Not five. The deep hierarchy is what agencies want and what everybody else gets lost in, so pick your depth and fix it
- tasks: id, list_id, number, title, description_md, status_id, assignee_ids_json, due_at, start_at, estimate_minutes, priority, position, parent_id, completed_at, created_at
- statuses: id, scope, name, group, position — the group is one of not-started, active, done, cancelled, and every report depends on it. Custom names, fixed groups
- custom_fields and values, per space
- task_activity: id, task_id, field, old, new, actor_id, at — append-only, and the basis of every report. It cannot be reconstructed later
- dependencies, comments, attachments, watchers, time_entries
- views: id, scope, kind, filters_json, sorts_json, group_by, columns_json — a saved question, never a copy

VIEWS FROM ONE QUERY BUILDER
- List, board, calendar, table, and a timeline with dependencies
- Five renderers over one query builder, never five implementations. That single decision is the difference between a fortnight and six months
- Filters saved as views, shareable by URL, with permissions checked inside the query
- Ordering by fractional positions, not floats — floats run out of precision after enough drags and tasks start swapping places by themselves

THE PIECES WORTH ADDING, IN ORDER
- **Time tracking**, if you bill: a timer per task, one running per person enforced by a partial unique index, an entry as two instants with the duration derived
- **Forms**, if you take intake: a form that creates a task with fields mapped, a honeypot and a rate limit
- **Docs**, if you write specifications: Markdown pages linked to tasks, with revisions
- **Automations**, last: a trigger, a condition, an action, every run recorded. Three triggers people understand beat twenty they do not
- Whiteboards are a canvas engine and a project of their own. Embed an existing one or leave it out

THE REST
- Recurring tasks with the two kinds — on a schedule, and N days after completion
- Notifications batched into a digest with mentions immediate. An over-notifying tracker is filtered into a folder nobody opens
- Search with FTS5 across titles, descriptions and comments
- Export everything as JSON and CSV in one command

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, OIDC_*, SMTP_URL
- Migrations on boot, each once; nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
The activity log, fixed status groups, and the discipline to stay narrow. The first two are what every report is derived from; the third is what makes the project finish.