Linear

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 an issue tracker that replaces Linear — and be honest about why this is ALMOST.

**The speed is the product.** Linear feels instant because the whole workspace is in the client and every action applies locally before the server hears about it. That local-first sync engine is a hard engineering problem, not a feature you add later, and matching it is most of the project. The rest — issues, cycles, projects — is a fortnight. Decide up front whether you are building the fast version or the ordinary one, because retrofitting is not possible.

STACK
- Node 20+ with Fastify for the server
- SQLite through better-sqlite3, WAL mode
- The client holds the workspace in IndexedDB and evaluates every view locally
- WebSockets for the change stream
- Caddy in front

THE LOCAL-FIRST ENGINE, WHICH IS THE DECISION
- The client downloads the workspace once, then receives a stream of changes. Every list, filter and search runs against local data, so opening a view is instant with no request at all
- Mutations apply locally, immediately, and are queued to the server. The interface never waits for a round trip
- Each mutation carries a client-generated identifier and a base version. The server accepts or rejects, and the client reconciles — rolling back an optimistic change visibly rather than silently
- Ordering by a server-side change counter, never a clock. A missed change means a client quietly showing stale data, so the client asks for everything since its last known counter on every reconnect
- The workspace must fit in memory. Tens of thousands of issues do; millions do not. Write down that limit and what you would do past it — usually loading only recent and open issues, with the archive fetched on demand

THE DATA MODEL
- teams: id, key, name, cycle_duration_weeks, cycle_start
- issues: id, team_id, number, title, description_md, state_id, priority, assignee_id, estimate, cycle_id, project_id, parent_id, position, created_at, completed_at, canceled_at, archived_at
- states: id, team_id, name, type, position — the type is backlog, unstarted, started, completed or canceled. Custom names, fixed types, because every report depends on the type
- cycles: id, team_id, number, starts_on, ends_on; cycle_issues with added_at and removed_at, so scope change is visible rather than invisible
- projects: id, name, state, lead_id, target_date, team_ids_json; project_updates: id, project_id, body_md, health, at — written by a person, never computed
- labels, comments, reactions, relations, attachments, subscriptions
- issue_history: id, issue_id, field, old, new, actor_id, at — append-only, and where every metric comes from. It cannot be reconstructed later
- Issue numbers per team, allocated in the creating transaction and never reused. That identifier goes into commit messages and lives forever

THE OPINION, WHICH IS THE OTHER HALF
- Cycles are fixed-length and automatic. Issues not finished roll to the next cycle, and the roll is recorded
- One estimate scale per team, and it is a number, not a size name
- A small set of state types, so a burndown is always computable
- Triage as a real state for issues from outside the team
- Resist configurability. The reason this product is fast to use is that there are few decisions to make, and every option you add is a decision somebody has to take before they can file a bug

KEYBOARD FIRST
- Every action has a shortcut, and a command palette covers the rest. Filing an issue should take under five seconds from anywhere
- Multi-select in every list, with bulk actions
- If a common path needs the mouse, it is a bug

THE REST
- Search across titles, descriptions and comments, running locally against the client's own copy, which is why it feels instant
- Git integration: a branch or commit mentioning the issue key links it, and a merged pull request moves the state. Read the forge's events; never write to the repository
- Notifications batched, with mentions immediate
- Export everything as JSON in one command

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, OIDC_*, SMTP_URL, FORGE_WEBHOOK_SECRET
- Migrations on boot, each once; the change stream in its own process
- Nightly backup off the machine, restore script
- Health endpoint reporting connected clients and the newest change counter

WHAT MATTERS MOST
The sync engine and the history table. Build the local store, the change stream and optimistic mutation before a single screen looks good — that is the product, and the issue tracker on top of it is the easy part.