How to Build a Custom CRM

Off-the-shelf CRMs are excellent right up until your process stops being standard. A multi-stage onboarding that spans three teams. Pricing that depends on a configuration nobody's fields can express. Partners who bring in customers and need their own view. A per-seat bill that grows faster than the team. At that point companies do one of two things: bend the business around the tool, or build the tool around the business.

This is a practical guide to the second option — what a custom CRM actually consists of, how I design one, and when it is the wrong call.

First: should you build one?#

Build when at least two of these are true:

• Your pipeline stages, entities or rules genuinely differ from the generic model, and the workarounds are costing time every day.
• The CRM must integrate deeply with systems you already own (a booking engine, an LMS, an ERP, a product database).
• You have a specific group of users — partners, students, field staff — who need a tailored interface, not the vendor's.
• Licence costs at your scale exceed what a build and its upkeep would cost over three years.

Do not build when the real problem is adoption (a custom tool will not fix a team that does not log activity), when the process is still changing weekly (build once it stabilises), or when a standard CRM plus a few integrations would do 90% of the job.

The core data model#

Every CRM, custom or not, rests on a small set of entities. Get these right and the rest follows.

Organisation ──< Contact
     │               │
     └──< Deal ──────┘        Deal belongs to an Organisation and has a primary Contact
           │
           ├──< Activity      calls, emails, meetings, notes — the timeline
           ├──< Task          follow-ups with owner and due date
           └──  Stage         current position in a Pipeline

• Organisation — the company or account. In B2C this may collapse into Contact; keep the table anyway, because "household" or "family" usually appears later.
• Contact — a person, with roles relative to organisations (decision maker, billing, technical).
• Deal (or Opportunity, Enquiry, Application — name it what the business calls it) — the thing that moves through a pipeline. It has a value, an owner, a stage and a history of stage changes.
• Pipeline and Stage — configurable, not hard-coded. Stages have an order, a probability if you forecast, and optional rules (required fields before entering, automatic tasks on entry).
• Activity — everything that happened, in one timeline. Emails, calls, meetings, notes, system events. This table is the heart of the CRM; if it is fragmented across features, users lose the story.
• Task — follow-ups with a due date and owner. The "what do I do today" view is built on this.

Two design decisions matter more than the rest:

Custom fields as data, not migrations. Businesses add fields constantly. Model a field_definitions table (name, type, entity, options, validation) and a field_values table, or use a JSON column with a schema per entity. Either way, adding a field must not require a developer.

Stage history as its own table. Store every transition (deal, from stage, to stage, by whom, when). Conversion rates, time-in-stage and forecast accuracy all derive from it, and none of them can be reconstructed if you only store the current stage.

Pipelines and rules#

A pipeline is more than a list of columns. What makes a custom CRM earn its keep is encoding the business rules that a generic tool cannot:

• Entry requirements — a deal cannot move to "Proposal sent" without a value and a decision-maker contact.
• Automatic tasks — entering "Trial started" creates a check-in task for day 3 and day 10.
• Ownership rules — leads from a partner are assigned to that partner's manager.
• SLAs — an enquiry untouched for 48 hours is flagged and escalated.

Implement these as a small rules layer that fires on stage change and on a schedule. In a Laravel application that is events and listeners plus scheduled commands; in Node, an event emitter and a cron worker. Keep the rules in configuration where the business can read them, and log every automatic action to the activity timeline so nothing happens invisibly.

The follow-up engine#

Most sales are lost to silence, not to competitors. The follow-up engine is the feature that pays for the CRM:

1. Every deal always has a next task. If a task is completed without a new one being created, the deal is flagged.
2. A daily digest per user: overdue, due today, deals with no activity in N days.
3. Sequences — a scheduled series of touches (email day 0, call day 2, email day 7) that pause automatically when the contact replies.

Sequences need reliable email integration — sending through the user's own mailbox (Google Workspace or Microsoft 365 APIs) so replies land in the right thread and are captured back into the timeline.

Integrations#

A CRM that stands alone becomes a second place to type things. The integrations that matter, in rough priority order:

• Email and calendar — two-way sync of messages and meetings into the activity timeline. This is the difference between a CRM people use and one they update on Friday afternoon.
• Web forms and lead sources — enquiries flow in automatically with source attribution.
• Accounting or billing — when a deal is won, the invoice or subscription is created; payment status flows back.
• Telephony — click to call, call logging, recordings attached to the timeline.
• Product or operations systems — order status, bookings, usage data visible on the customer record.

Treat each as an integration with its own error handling, retry logic and reconciliation view. Silent sync failures erode trust faster than no integration at all — I cover this in more depth in the system integration service.

Reporting#

Management will ask for three things on day one: pipeline by stage and owner, conversion between stages, and forecast for the period. All three come directly from the deal and stage-history tables.

Build reporting as saved queries over the data, not as a separate warehouse, until volume forces the split. Provide CSV export from every list view — the spreadsheet is not the enemy; it is where the ad-hoc analysis happens.

Permissions#

CRMs hold sensitive data. Model permissions from the start:

• Roles (admin, manager, sales, partner, read-only).
• Record ownership with team-level visibility rules (see own, see team, see all).
• Field-level restrictions for things like contract values or personal data.
• Audit log of who viewed or changed what, for compliance and for the inevitable "who deleted this?".

Partner portals — external users seeing only their own leads — are a common reason to go custom, and they are only safe if ownership rules are enforced in the data layer, not just hidden in the UI.

Technology choices#

For most custom CRMs I build on Laravel with MySQL or PostgreSQL — a mature framework with first-class queues, scheduling, authentication and an ecosystem for email, PDF generation and API integration. The interface is either Blade with lightweight interactivity or a React/Next.js frontend against a Laravel API when the interface needs richer interaction (drag-and-drop pipelines, live timelines).

The data volume of a typical SME CRM is small. Optimise for developer speed and reliability, not for scale you will not reach.

Where AI fits#

Once the data model and activity timeline exist, AI features become straightforward additions rather than a rebuild:

• Summarise the timeline before a call.
• Draft follow-ups in the user's voice from the deal history.
• Classify inbound enquiries by intent and route them.
• Extract structured updates from call notes or transcripts.

Each of these is a structured AI step inside a workflow, and each benefits from the clean data a custom CRM produces.

Phasing the build#

Do not build the whole thing before anyone uses it. A sequence that works:

1. Contacts, organisations, deals, one pipeline, activity timeline. Migrate existing data. Team starts using it.
2. Tasks and the follow-up engine. Daily digests.
3. Email and calendar integration.
4. Rules, sequences and reporting.
5. Partner or customer portal, if that was the driver.
6. AI assistance on top of the accumulated data.

Each phase is a working system. The business gets value early, and the later phases are shaped by real usage instead of guesses.

The honest summary#

A custom CRM is a small number of well-modelled tables, a configurable pipeline, an activity timeline that everything writes to, a follow-up engine, a handful of integrations that remove double entry, and permissions enforced in the data layer. It is not a moonshot. Built in phases around a real process, it becomes the system the business actually runs on — which is the only reason to build one.