Basecamp

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 project management that replaces Basecamp — and understand what you are actually replacing.

The features are a fortnight. What is being bought is **an opinion**, held without wavering for twenty years: every project gets the same five things, and nothing can be configured. That opinion is why teams stop arguing about process. You cannot buy it, and you certainly cannot build it — but you can copy it, by deciding your five things now and then refusing every request to add a sixth. That refusal is the hard part, and it is why this is ALMOST.

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 FIVE THINGS, FIXED
- A to-do list, a message board, a schedule, files, and a chat room. Per project. That is the whole product
- No custom fields, no workflow builder, no views, no statuses beyond done and not done. Every one of those is a request you will receive and must decline
- Write the refusal in the README so future you remembers why

THE DATA MODEL
- projects: id, name, description, is_archived, client_id, created_at
- todo_lists: id, project_id, name, position; todos: id, list_id, content, assignee_ids_json, due_on, completed_at, position, notes_md
- messages: id, project_id, title, body_md, author_id, category, created_at; comments on anything, polymorphic by kind and id
- events: id, project_id, title, starts_at, ends_at, all_day, participants_json
- files: id, project_id, folder_id, name, path, sha256, bytes, mime, uploaded_by
- chats: id, project_id; chat_messages: id, chat_id, author_id, body, created_at
- checkins: id, project_id, question, cadence_json; checkin_answers: id, checkin_id, user_id, body_md, at
- subscriptions: what each person follows, and notifications derived from it
- clients: id, name; client_access: project_id, client_user_id — see below

THE TWO IDEAS WORTH COPYING
- **Automatic check-ins.** A recurring question — what did you work on today, what is blocking you — asked on a schedule, answered in a sentence, posted where everyone can read it. It replaces a meeting and costs a minute, and it is the most underrated feature in this product
- **Client access as a first-class idea, not a permission checkbox.** A client sees a project's messages, files and schedule but never the internal chat, and every message is explicitly marked as client-visible or not before it is posted. Getting that wrong once — an internal note appearing on a client's screen — is unrecoverable, so make the two visually unmistakable and make internal the default

DISCUSSION OVER EMAIL
- Messages and comments are threaded, and every notification email can be replied to, with the reply becoming a comment
- Inbound mail parsed properly, threading by Message-ID, quoted history stripped for display and kept in full, and bounces and automatic replies never posted
- One digest per person per day by default, with mentions immediate. The product's whole claim is that it keeps discussion out of inboxes, and an over-notifying version does the opposite

THE REST
- Search with FTS5 across everything in a project, permissions checked inside the query
- Files stored by hash, type from content, served through a permission check
- Archive rather than delete, and a project archive that stays readable forever — old projects are a record, and being able to read one from three years ago is worth more than any feature

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, SMTP_URL, IMAP_URL
- Migrations on boot, each once; nightly backup off the machine, restore script
- Health endpoint checking both mail directions

WHAT MATTERS MOST
Client visibility and the check-ins. Build those two properly and then stop adding things — the discipline is the product.