Custom CRM

What a custom CRM is

A custom CRM is a Customer Relationship Management system designed and built specifically for one company’s revenue motion, instead of configured on top of a platform like Salesforce, HubSpot, or Zoho. The core data model — accounts, contacts, opportunities, activities — is shaped to match how the business actually sells, supports, and renews customers.

Custom CRMs sit on the other end of a spectrum from platform CRMs. Platforms give you a generalized model and powerful configuration; custom CRMs give you exact fit and ownership of the code. The right answer depends on the motion.

When to build custom

Three signals point toward custom:

1. The sales motion does not fit a pipeline-stage model. Some businesses sell continuously, in batches, or through events that no preset stage system represents cleanly. Trying to bend Salesforce to fit usually produces a brittle config that breaks the moment the motion evolves.
2. Critical data lives in objects the platform cannot represent. If revenue depends on tracking, say, every shipment that a freight broker quotes, with custom relationships to invoices, the platform’s custom-object overhead overwhelms the value.
3. You expect the model to change for the next two years. Platform CRMs reward stability. Custom CRMs reward iteration. If the model itself is the product, custom usually wins.

The studio’s CRM development practice starts every engagement with this decision, and the studio’s comparison page lays it out side-by-side.

When to extend a platform instead

The reverse signals are simpler:

• The motion is recognizably pipeline-stage-shaped.
• The data fits accounts, contacts, opportunities without violence.
• You want to plug into ecosystem apps (Outreach, Gong, Apollo) without writing the integrations.

In these cases, extending Salesforce, HubSpot, or Zoho is faster, cheaper, and more durable than rebuilding the wheel.

What a custom CRM build looks like

A typical custom CRM engagement ships in stages:

1. Modeling sprint. Map the actual sales motion, the data, the integrations, and the reporting. Output: a domain model that everyone on the revenue team recognizes.
2. Pipeline build. The opportunity, account, and contact tables; the workflow engine; the activity log; the assignment logic (lead routing included).
3. Integrations. Email, calendar, calling, billing, and warehouse sync. Each behind a clean interface so vendors can be swapped later.
4. Reporting. Pipeline, forecast, win/loss. Often warehouse-native — querying Snowflake or BigQuery directly rather than building a parallel reporting engine.
5. Adoption and migration. Move data from the legacy CRM (or the spreadsheet); train the team; ship in waves, not big-bang.

Code-shape example

A minimal custom-CRM data model with the activity-as-event pattern that scales:

// Core entities are simple. Activity is where the value lives.
export interface Account {
  id: string;
  name: string;
  domain: string | null;
  ownerId: string;
  segment: "smb" | "mid_market" | "enterprise";
  createdAt: string;
}

export interface Contact {
  id: string;
  accountId: string;
  name: string;
  email: string;
  role: string | null;
  createdAt: string;
}

export interface Opportunity {
  id: string;
  accountId: string;
  ownerId: string;
  stage: string;     // App-defined, not platform-imposed.
  amount: number;
  currency: string;
  closeDate: string;
  createdAt: string;
}

// Activities are append-only events. Every email, call, meeting, deal-stage
// change, and note becomes an activity. Roll-up is a query, not a state.
export interface Activity {
  id: string;
  type: "email" | "call" | "meeting" | "stage_change" | "note" | "task";
  accountId: string;
  contactId: string | null;
  opportunityId: string | null;
  actorId: string;       // user or "system"
  occurredAt: string;
  payload: Record<string, unknown>;
}

// Lead routing service: rule chain, idempotent, audit-logged.
export async function routeLead(lead: NewLead): Promise<Activity> {
  const rules = [matchedAccount, byTerritory, byScore, roundRobin];
  for (const rule of rules) {
    const match = await rule(lead);
    if (match) {
      const activity = await activities.insert({
        type: "stage_change",
        accountId: match.accountId,
        actorId: "system",
        occurredAt: new Date().toISOString(),
        payload: { rule: rule.name, ownerId: match.ownerId },
      });
      return activity;
    }
  }
  throw new Error("no rule matched");
}

The key shape is activities as the truth. Pipeline reports, forecasts, and audit trails all derive from the activity stream. State is a query, not a column.

How we implement it at Dashhold

Patterns we ship on every custom CRM:

• Activities are append-only. Same shape as a ledger. State changes are events, not column updates.
• The opportunity stage is a string, not an enum. Sales teams will rename and reorder stages. A string + a stages config table is far less brittle.
• Reporting on the warehouse, not the OLTP. Pipeline and forecast queries hit Snowflake or BigQuery. The application database stays small and fast.
• Email, calendar, and calling integrations are pluggable. Adapters per vendor; the activity ingest layer is shared. Swapping Outreach for Salesloft becomes a config change.
• Lead routing as a documented rule chain. Configurable, auditable, idempotent. Every assignment writes an activity. Ops teams can debug “why did this lead go to me” in 30 seconds.

Common pitfalls

• Over-engineering the data model on day one. Ship the minimum that supports the actual sales motion. Add complexity when the motion demands it, not before.
• Mixing CRM and product database in one schema. They have different access patterns and different lifecycles. Keep them in separate services or at least separate schemas.
• Hard-coding stages. Sales teams iterate on stages constantly. Treat stages as configuration.
• Skipping warehouse sync. Without a warehouse, every reporting question becomes engineering work. Pipe to Snowflake or BigQuery early; build dashboards there.
• No assignment audit log. “Why did this lead go to me” is the most common ops question. Without an audit log, the answer is always “I don’t know.”
• Migrating big-bang from Salesforce. Wave migrations are safer. Run both in parallel until the wave is stable, then cut over.

Where custom CRMs fit

Custom CRMs fit unusual revenue motions, fast-evolving businesses, and platforms that need a CRM as a load-bearing piece of their product (think marketplaces, fintech onboarding flows, and B2B SaaS where the CRM is the sales surface). The studio’s CRM development team ships custom CRMs and platform extensions side by side, picking the right answer per engagement.

See also

• Custom CRM vs Salesforce comparison — side-by-side decision guide
• Custom CRM vs HubSpot comparison — side-by-side guide for the friendlier platform
• Lead routing — assignment logic every CRM (custom or not) ships