Zoho CRM

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

This is one of the cheapest full suites available, and the price is genuinely hard to beat on features per euro. What it costs instead is fit: a general CRM is somebody else's guess at your sales process, and configuring one into your shape is its own project. Build when your process is specific and small.

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
- organisations: id, name, domain, address, owner_id, custom_json
- people: id, organisation_id, name, emails_json, phones_json, title, owner_id
- pipelines and stages: id, name, position, rotting_days
- deals: id, pipeline_id, stage_id, organisation_id, person_id, title, value_cents, currency, expected_close_on, owner_id, status, won_at, lost_at, lost_reason_id, source
- stage_history: id, deal_id, from_stage_id, to_stage_id, at, actor_id — append-only, and where every honest number comes from. It cannot be reconstructed later
- activities: id, kind, subject, note, due_at, done_at, deal_id, person_id, owner_id, source
- emails: id, message_id, thread_id, direction, from_address, subject, snippet, occurred_at, deal_id, person_id
- lost_reasons: id, label — required on a lost deal, because that is the only way anybody learns from losing

THE TWO THINGS THAT DECIDE WHETHER IT IS USED
- **Email filed automatically.** Read-only mailbox sync, matched to a person by address and to a deal by thread, storing the address, direction, subject, timestamp and a short snippet — never the body. Store the thread id on the deal the first time and everything in that thread follows. When two open deals share a contact, file against the person and ask rather than guess
- **A next activity on every deal.** A deal with nothing scheduled is shown as such, prominently. Add a rotting period per stage and that pair does more for a pipeline than any forecast

REPORTING THAT IS HONEST
- Conversion between stages and time in each stage, computed from stage_history
- Deals not moved in longer than the median stage duration, ranked
- Weighted pipeline shown beside the unweighted total, with the weights stated — better, conversion rates from your own closed deals applied to what is open
- Everything computed at query time. No stored totals

THE REST
- Views as saved filters, a board per pipeline with drag to move a stage
- Deduplication by email and domain, reviewed by hand, merges reversible. Never automatic
- FTS5 across people, organisations, notes and activity subjects
- Export everything as CSV and JSON in one command, including stage history

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

WHAT MATTERS MOST
Email filing and stage history. The first is why the CRM stays current; the second is the only thing that will ever tell you something you did not already know.