How to build a custom CRM

Most teams do not need "a CRM." They need the three or four things their sales process does every day, done in a way that matches how they actually work. Salesforce can do everything, which is exactly why nobody enjoys opening it. A custom CRM wins when your pipeline, your data, and your follow-up rules are weird enough that off-the-shelf software fights you more than it helps.

What it is and who it is for

A CRM is the system of record for the people and companies you sell to, and the conversations that move them toward a deal. That is it. Everything else (reports, automations, dashboards) is built on top of that record.

Consider building a custom one when the standard tools force your team into a shape that does not fit. Maybe you sell through a multi-stage approval process, your "contacts" are actually households or clinics or fleets of trucks, or your reps live in a spreadsheet because the real CRM is too slow to update mid-call. If your process is genuinely ordinary, buy HubSpot and move on. If it is not, a tool built around your exact pipeline is the difference between reps logging activity and reps avoiding it.

The one core job it must do well: make it faster to update a deal than to not. A CRM that reps skip is worse than no CRM, because now your data lies to you. Every design decision flows from that rule.

The MVP feature set

Build the smallest thing that a real rep can run their week on. That usually means:

• Contacts and companies with a clean relationship between them (a contact belongs to a company, a company has many contacts).
• Deals or opportunities that move through stages you define, attached to a company and an owner.
• Activity logging: notes, calls, emails, and tasks, all timestamped and tied to a contact or deal.
• A pipeline view: the board or list where a rep sees what is theirs and what needs attention today.
• Search that is instant, because reps look things up constantly and a slow search kills adoption faster than any missing feature.

That is a CRM. Ship it, get three reps using it daily, then build phase two from what they complain about.

Phase two is where the tempting stuff lives: email sync, automated follow-up sequences, reporting dashboards, lead scoring, role-based permissions, and integrations with your billing or support tools. All useful, all easier to scope once you have real usage data instead of guesses. Resist the urge to build reporting before anyone has entered a single deal.

The hard parts most people underestimate

CRMs look like simple CRUD apps. They are not. The difficulty hides in four places.

The data model is deceptively relational. A contact changes jobs and now belongs to a different company, but you still want their history. A deal involves three people at two companies. A company gets acquired and merges with another record. Activity needs to attach to a contact, a deal, or both. Get the schema wrong and every feature after it gets harder. Here is a starting point worth stealing:

create table companies (
  id          uuid primary key default gen_random_uuid(),
  name        text not null,
  domain      text,
  owner_id    uuid references users(id),
  created_at  timestamptz not null default now()
);
 
create table contacts (
  id          uuid primary key default gen_random_uuid(),
  company_id  uuid references companies(id) on delete set null,
  full_name   text not null,
  email       text,
  phone       text,
  owner_id    uuid references users(id),
  created_at  timestamptz not null default now()
);
 
create table deals (
  id          uuid primary key default gen_random_uuid(),
  company_id  uuid references companies(id),
  owner_id    uuid references users(id),
  title       text not null,
  stage       text not null default 'new',
  amount_cents bigint,
  currency    text not null default 'USD',
  closed_at   timestamptz,
  created_at  timestamptz not null default now()
);
 
create table activities (
  id          uuid primary key default gen_random_uuid(),
  contact_id  uuid references contacts(id) on delete cascade,
  deal_id     uuid references deals(id) on delete cascade,
  user_id     uuid references users(id),
  kind        text not null,          -- note | call | email | task
  body        text,
  due_at      timestamptz,            -- for tasks
  created_at  timestamptz not null default now()
);
 
create index on deals (owner_id, stage);
create index on activities (contact_id, created_at desc);
create index on activities (deal_id, created_at desc);

Notice the indexes. The activity timeline is the screen reps stare at all day, and it gets slow the moment a customer has a few hundred interactions. Indexing the timeline queries from day one is not premature optimization, it is the feature.

Permissions get political fast. "Can a rep see another rep's deals?" sounds like a checkbox. It is actually a question about how your company runs sales, and the answer changes when you hire a manager, add a region, or close a deal someone else sourced. Build ownership in from the start, even if everyone sees everything for now. Retrofitting row-level access onto a CRM that assumed open data is a genuinely painful migration.

Imports and merges are a whole project. Your data is coming from a spreadsheet, an old CRM, or both, and it is messy: duplicate companies, half-filled contacts, deals with no owner. A good import flow with deduplication and a merge tool is often more work than the pipeline view, and skipping it means reps lose trust in the data on week one.

Email and calendar sync is where timelines go to die. Two-way email sync (so a rep's Gmail threads show up on the contact automatically) involves OAuth, webhooks, rate limits, and a lot of edge cases. It is genuinely valuable and genuinely expensive. Treat it as its own phase, and consider whether a lighter "BCC this address to log it" approach gets you most of the value first, for a fraction of the work.

The stack we would reach for

Nothing exotic, because a CRM lives or dies on reliability and speed, not novelty. We would build the app on Next.js with TypeScript for the frontend and API routes, Postgres for the data (its relational model is exactly what a CRM needs), and a hosted auth provider like Clerk or WorkOS so we are not writing login and SSO from scratch.

For the pipeline and timeline views, server components plus a thin layer of client interactivity keep things fast without a heavy single-page-app. Background work (email sync, reminders, scheduled reports) goes through a job queue rather than blocking requests. If you want this delivered as a real product your team can grow into, this is squarely SaaS platform engineering territory, and our API and backend work is where the integration glue (email, calendar, billing) gets built properly. The frontend is the easy part; the value is in the data model and the integrations.

Rough timeline and cost

These are ranges, not quotes. The real number depends on how strange your process is and how clean your existing data is.

• A focused MVP (contacts, companies, deals, activities, pipeline, search, auth): roughly 6 to 10 weeks with a small senior team, landing in the low five figures to around 40k.
• A team-ready CRM (the above plus imports and merge tooling, role-based permissions, basic reporting, and one or two integrations): more like 3 to 5 months and the mid five figures to low six figures.
• Email and calendar sync, automation, and custom reporting push you further in both time and money. These are the features that justify going custom in the first place, so budget for them deliberately rather than treating them as extras.

The honest framing: a custom CRM rarely beats off-the-shelf on raw cost. It beats it on fit, and fit is what gets your team to actually use the thing.

What to watch out for

Building for the org chart instead of the rep. Managers want dashboards. Reps want to log a call in two seconds. If you optimize for the manager's reports before the rep's daily flow, nobody enters data and the reports are empty anyway. Reps first, always.

Treating it as a one-time build. A CRM grows with your sales process: new stage, new field, new integration, new rule. Plan for ongoing maintenance and iteration from the start, because a frozen CRM slowly drifts away from how you actually sell.

Underestimating data migration. The week you switch reps over from the old system is the riskiest week, and bad imports erode trust permanently. Budget real time for cleaning and validating the import, and run a parallel period where both systems are live.

Over-customizing the data model. Custom fields are great until every record has forty of them and nobody knows which matter. Start opinionated and narrow. Add fields when a rep can name the decision the field helps them make.

Takeaway

A custom CRM is worth it when your sales process is genuinely yours and off-the-shelf tools make your team work around them instead of with them. Build the smallest thing reps can run their week on, get the data model and permissions right early, and treat imports and email sync as the real projects they are. Everything else is iteration.

This is exactly the kind of system we build: data-heavy, integration-heavy, and only useful if people actually adopt it. If you are weighing whether to buy or build, talk to us and we will give you the honest answer, even when it is "just buy HubSpot."