Attio

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 CRM that replaces Attio — and know why this is ALMOST.

The flexible data model is achievable. The two halves that are not: **automatic enrichment** of companies and people from public sources, which means either paying a data provider or accepting worse data, and **a relationship graph built without anybody typing anything**, which needs a mailbox and calendar sync that is genuinely good. The second is buildable and is where the value is. The first mostly is not — decide whether you actually need it.

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
- objects: id, slug, name, singular, icon — the object types, defined by you
- attributes: id, object_id, key, label, kind, config_json, is_unique, position — text, number, currency, date, select, status, checkbox, url, email, phone, a reference to another object, or a list of them
- records: real tables per object, created and altered by generated migrations. A generic key-value store makes every query slow and every constraint impossible
- record_revisions: append-only, field by field
- relations resolved as real foreign keys and join tables
- activities: id, kind, subject, snippet, occurred_at, record_ids_json, actor, source — email, meeting, call, note
- lists: id, object_id, name, filter_json, columns_json — a saved question, never a copy
- Adding an attribute writes a migration file, so the production change is the one you tested

BUILDING THE GRAPH WITHOUT DATA ENTRY
- Read-only mailbox sync over IMAP or the provider's API: one activity per message with a counterpart — the address, the direction, the subject, the timestamp, a short snippet. Never the body
- Calendar sync: one activity per meeting with its attendees
- Both incremental with a cursor, idempotent by external identifier
- People and companies created from the addresses seen, with the company from the email domain
- The last-contacted date, the frequency and the direction balance all fall out of this for free, and nobody ever updates a record. That is the entire point
- Say plainly in the README what is stored: addresses, subjects, times, a snippet. Not the correspondence. That restraint is what makes it usable

ENRICHMENT, HONESTLY
- What is free: the company's own website and its metadata, a favicon, public DNS, and whatever the email domain tells you
- What is not: firmographics, headcount, funding, job titles. Those come from a paid provider, and the honest options are to pay for one, to fill them by hand, or to do without
- Whichever you choose, record the source and the date on every enriched field so a stale value is visible

VIEWS AND WORKFLOW
- Table and board views over any object, with filters, sorts and grouping, saved as lists
- A pipeline is a status attribute plus a board, and every status change writes a revision row — that history is where all the honest metrics come from and it cannot be reconstructed later
- Tasks and reminders attached to any record
- Deduplication by exact identifier then by name similarity, reviewed by hand, merges reversible. Never automatic

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, ENCRYPTION_KEY, HASH_SALT, IMAP_URL
- Migrations on boot, each once; credentials encrypted at rest
- Nightly backup off the machine, restore script
- Health endpoint reporting the age of the last mail and calendar sync

WHAT MATTERS MOST
Mail sync and status history. Build those two first and run a real quarter through it — a CRM maintained by hand is out of date within six weeks, and one without history can never tell you anything you did not already know.