monday.com

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 the work tracker I actually need instead of monday.com — and be honest about what you lose.

**What is being bought is that somebody who does not write code can build the whole thing.** That is a real property, and a bespoke tool does not have it. Build when the process is settled and specific; keep paying when the shape changes monthly and the person changing it is not you.

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

THE DATA MODEL
- boards: id, name, description, is_archived
- groups: id, board_id, name, colour, position — the coloured sections a board is divided into
- columns: id, board_id, key, label, kind, config_json, position — text, number, status, person, date, timeline, checkbox, link, file, formula, mirror
- items: real rows in a real table per board, created and altered by generated migrations. **Not a generic key-value store**: real columns mean real constraints, real indexes and a query that stays fast at fifty thousand rows
- subitems: one level, and only one. Deeper is where these tools become unusable
- item_revisions: id, board_id, item_id, column_key, old_value, new_value, actor_id, at — append-only, and where every report comes from
- automations: id, board_id, trigger_json, conditions_json, actions_json, is_active; automation_runs, recorded
- views: id, board_id, kind, filters_json, sorts_json, group_by, columns_json

THE STATUS COLUMN, WHICH IS THE WHOLE IDEA
- A fixed set of labels with colours, defined per board, and that is what people actually manage by
- **Every status change writes a revision row.** Time in status, cycle time and 'what is stuck' all come from that table and cannot be reconstructed later. Build it before anything is pretty
- A status has a kind underneath the label — not-started, working, done, stuck — so a report can be written once rather than per board

VIEWS FROM ONE QUERY BUILDER
- Table, board grouped by any status or person, calendar on a date column, and a timeline for anything with a start and an end
- Four renderers over one query builder, never four implementations. That decision is the difference between a fortnight and six months
- Ordering by fractional positions, not floats, or rows swap places after enough drags

AUTOMATIONS, KEPT SMALL
- Triggers: a status changed, a date arrived, an item created, a column filled, a schedule
- Actions: set a column, move to a group, assign, notify, create an item elsewhere, call a webhook
- Every run recorded with its result. An automation that silently does nothing is worse than none
- **A per-recipient daily notification cap**, so a loop cannot email somebody four hundred times. An afternoon's work that prevents a very bad day
- Three triggers people understand beat twenty they do not

FORMS AND INTAKE
- A form that creates an item with columns mapped, public or internal, with a honeypot and a rate limit
- That is how work arrives from outside the team, and it is the feature that makes a board replace an inbox

THE REST
- Updates on an item — a thread, with mentions that notify — kept beside the row rather than in chat
- Files stored by hash with the type from content
- Notifications batched into a digest, mentions immediate
- Export everything as JSON and CSV in one command

WHAT MATTERS MOST
The revision log and real columns. Both are invisible on day one and impossible to add later — and between them they are every report you will ever want.