Pipedrive

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 sales CRM that replaces Pipedrive — and know what makes this ALMOST.

The pipeline is a fortnight. What is not is **two-way email sync that files every message against the right deal without anybody remembering to**, which is the reason a sales team adopts a CRM rather than resenting it. Calling and recording from inside the record is the other half, and that is a telephony provider with a per-minute cost.

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, custom_json
- pipelines: id, name; stages: id, pipeline_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, custom_json
- 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
- value_history: id, deal_id, old_value_cents, new_value_cents, at — because a deal whose value changed is two facts, and the forecast should know which
- activities: id, kind, subject, note, due_at, done_at, duration_ms, deal_id, person_id, organisation_id, owner_id, source
- emails: id, message_id, thread_id, direction, from_address, to_json, subject, snippet, occurred_at, deal_id, person_id, is_manual_link
- calls: id, provider_ref, direction, from_number, to_number, started_at, duration_ms, recording_path, transcript_path, deal_id
- lost_reasons: id, label — required on a lost deal, because that is the only way anybody learns from losing

EMAIL FILING, WHICH IS THE HARD PART
- Read-only sync of the mailbox over the provider's API or IMAP, incremental with a cursor, idempotent by message id
- Match to a person by address, then to a deal: the open deal for that person, or the one whose thread the message belongs to. Store the thread id on the deal the first time a message is filed, and everything in that thread follows automatically
- When it is ambiguous — two open deals with the same person — file against the person and ask. Never guess, because a message on the wrong deal is worse than one on none
- A manual link that is remembered, so correcting it once teaches the rule
- Store the address, direction, subject, timestamp and a short snippet. Never the body. Say so in the README — that restraint is what makes a sales team willing to connect their mailbox
- Sending from inside the record uses the person's own mailbox, so the reply arrives where they expect it

ACTIVITIES AND THE ROTTING RULE
- Every deal must have a next activity scheduled. A deal with nothing planned is shown as such, prominently, because that is the actual pipeline problem
- A stage has a rotting period: a deal sitting longer than that is flagged. Simple, visible, and it does more for a pipeline than any forecast
- Activity types with a duration, and a list of what is due today

REPORTING THAT IS HONEST
- Conversion between stages and time in each stage, computed from stage_history
- Won and lost by period, by source, by owner, with lost reasons ranked
- Weighted pipeline shown next to the unweighted total, with the weights stated. Better: conversion rates from your own closed deals applied to what is open, which is a forecast with evidence
- Deals not moved in longer than the median stage duration, ranked. That list is worth more than any forecast
- Everything computed at query time. No stored totals

CALLING
- A telephony provider, a per-minute cost, and consent to record where the law requires it — announce it, record that you did, and check the rules for both ends of the call
- Log the call against the deal automatically with its duration and recording

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
- FTS5 across everything, and export as CSV and JSON in one command including stage history

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, ENCRYPTION_KEY, provider credentials
- Migrations on boot, each once; nightly backup off the machine
- Health endpoint reporting sync age per mailbox

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.