Custom CRM vs HubSpot or Salesforce: When Building Your Own Actually Makes Sense

Buy first. Build when your core business object doesn't exist in the CRM you're paying for, or when the vendor's price for modelling it exceeds the cost of owning the data yourself. That's the whole decision, and it has almost nothing to do with how many salespeople you have.

Nearly every "custom CRM vs HubSpot vs Salesforce" article is written by an agency that sells custom builds, and they all land on the same arithmetic: under 20 seats buy, over 60 build. That math isn't wrong, it's just not the thing that breaks. I've built vertical platforms for a venue sales team, a three-location auto repair chain, and a courier operation. In none of them was per-seat pricing the reason — it was the data model.

The short version

Keep HubSpot or Salesforce if your business runs on contacts, companies, and deals moving through stages. Build custom when the thing you actually manage — a booking, a vehicle, a delivery route, an event date — is the centre of your business and the CRM can only represent it as a note field.

Most teams that ask me for a custom CRM don't need one — they need three integrations and a cleanup of their pipeline stages. The ones who do need a build usually know it already.

The real trigger is your data model, not your headcount

Here's the test: name the single object your business schedules, dispatches, or fulfils. If your CRM has a first-class object for it, buy. If your team is squeezing it into a deal record with eleven custom properties and a naming convention, you're already paying for a custom build — in staff time instead of engineering.

A wedding venue's core object is a date on a room, with a hold, a deposit, and a conflicting-events rule. A courier's is a shipment, with a zone-aware price, a driver, and proof of delivery. An auto repair chain's is a repair order, with a VIN, parts on backorder, and a bay at one of three locations. None of these are deals. Forcing them into a deal pipeline works until you need to ask a question the shape doesn't support — like "which Saturdays in October are held but not deposited?"

This is where pricing gets interesting. HubSpot does support custom objects — exactly the feature you'd need to model any of the above properly — but as of 2026 it's Enterprise-only, not available on Free, Starter, or Professional. Sales Hub Enterprise is $150 per seat per month with a 10-seat minimum, so modelling your own business object starts around $1,500/month before any configuration. Salesforce is more flexible out of the box, but you trade that for admin overhead.

If the feature that makes the CRM fit your business is gated behind the top pricing tier, the build-vs-buy comparison you were quoted is comparing the wrong numbers.

Run the seat math, but count what's actually on both sides

Off-the-shelf isn't just the sticker price, and custom isn't just the build quote. The honest three-year comparison includes what nobody puts in the proposal.

• Buy side: per-seat licences, the tier upgrade you need for the one feature that matters, data migration, each integration built and maintained, admin time, and per-feature upcharges — AI add-ons being the fastest-growing line.
• Build side: the initial build, then 15–25% of it annually in maintenance, plus hosting, on-call, and key-person risk.
• The curve that eventually crosses: custom cost is flat as you add seats and contacts. Licences aren't.
• What custom can't buy: it works on Monday, and someone else fixes it at 2am.

Be suspicious of any build quote with no maintenance line — that's how a custom CRM becomes shadow IT.

The third option most comparisons skip

You usually don't have to choose. The pattern that works best for small teams: keep HubSpot as the system of record for people and revenue, and build a focused custom app for the one workflow it can't hold, syncing over the API. You keep the reporting, email tooling, and integrations, and get a booking or dispatch system shaped like your operation.

The constraint that decides whether this works is your API budget, not the feature list. HubSpot's privately distributed apps get 100 requests per 10 seconds on Free and Starter (250,000/day) and 190 per 10 seconds on Professional and Enterprise (625,000 and 1,000,000/day). The CRM Search API sits outside those numbers with its own stricter limit — which matters, because search is what a naive sync reaches for. Batch and cache from day one:

// Sync bookings into HubSpot without tripping the 10-second limit.
// Private-app limits: 100 req/10s (Free/Starter), 190 req/10s (Pro/Enterprise).
// Batch endpoints move 100 records per request — use them.

const BATCH_SIZE = 100;
const MAX_RETRIES = 5;

async function upsertContacts(records: ContactInput[], token: string) {
  for (let i = 0; i < records.length; i += BATCH_SIZE) {
    const chunk = records.slice(i, i + BATCH_SIZE);
    await withRetry(() =>
      fetch("https://api.hubapi.com/crm/v3/objects/contacts/batch/upsert", {
        method: "POST",
        headers: {
          Authorization: `Bearer ${token}`,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          inputs: chunk.map((r) => ({
            idProperty: "email",
            id: r.email,
            properties: r.properties,
          })),
        }),
      })
    );
  }
}

async function withRetry(fn: () => Promise<Response>) {
  for (let attempt = 0; attempt < MAX_RETRIES; attempt++) {
    const res = await fn();
    if (res.status !== 429) {
      if (!res.ok) throw new Error(`HubSpot ${res.status}: ${await res.text()}`);
      return res;
    }
    // 429s must stay under 5% of daily requests, so back off properly.
    const waitMs = Number(res.headers.get("Retry-After") ?? 0) * 1000
      || 2 ** attempt * 1000;
    await new Promise((r) => setTimeout(r, waitMs));
  }
  throw new Error("HubSpot rate limit: retries exhausted");
}

Two rules keep this alive in production. Use webhooks for CRM-to-app updates instead of polling — workflow webhook calls don't count against the rate limit. And pick one system as the writer for each field; bidirectional sync with no ownership rules produces a conflict you'll debug for a week. The discipline from handling Stripe webhooks in production transfers directly.

Five questions that settle it

Answer these five in order. If four or more point the same way, you have your answer without needing a consultant to tell you.

1. What is your core object, and does your CRM have it? Contact or deal, buy. Booking, vehicle, route, case, or unit of inventory, keep going.
2. Which tier do you need for the feature that fits? Price the plan that solves the problem, not the entry plan.
3. What's on the side spreadsheet? Whatever your team tracks outside the CRM is the spec for the build. If it's empty, you don't need one.
4. Who owns it in year three? Name a person or a retainer. If you can't, buy.
5. Is the workflow a competitive advantage or just admin? Build what makes you different. Buy what makes you the same as everyone else.

Four pointing to build is a build. Anything less is a configuration project with a better integration layer.

What a right-sized custom build looks like

A good custom CRM is narrow. It models the one or two objects off-the-shelf tools can't, and hands everything else off — email to a mail provider, payments to Stripe, documents to whatever the team already uses. The failure mode is rebuilding HubSpot.

In practice: a multi-location service platform where the record is the job and the location, not the lead (Miller40, three Miami shops, 14k+ customers); a courier platform where the record is a shipment with zone-aware pricing and tracking (Dryva); and a venue sales layer where the record is an event enquiry tied to live calendar availability (VenueX). More on how I scope these at custom CRM development.

When I tell people not to build

I turn down custom CRM work regularly, almost always for one of four reasons. Hearing this early is cheaper than finding out at month four.

• The process isn't settled. If the workflow changes materially in six months, code freezes the wrong version. Run it in a configurable tool first.
• Nobody internally owns the data. A custom CRM with no owner becomes a database nobody trusts.
• The real problem is adoption. Reps who don't log activity in HubSpot won't log it in a bespoke tool either. That's a management problem wearing a software costume.
• You need the ecosystem. If marketing, support, and sales all run on marketplace integrations, replacing them is a bigger project than the CRM.

Common questions

What does a custom CRM actually cost to build?

For a focused vertical CRM — one or two custom objects, a pipeline, integrations, and reporting — expect a mid-five-figure range for a first version, plus 15–25% of that per year in maintenance. Quotes vary enormously because scope does; anything quoted without a written object model is a guess. Same honest-numbers logic as AI sales agent pricing.

Is Salesforce more customisable than HubSpot?

On the data model, yes — custom objects, fields, and validation rules are core to the platform rather than a top-tier feature. The trade-off is that meaningful changes usually need an admin or consultant, so you swap a licence cost for an expertise cost. HubSpot is easier for a small team to run day to day, which is why it's the better default under about 20 seats.

Where to start

Write down your core object and its fields on one page before you talk to any vendor or developer, including me. That page tells you whether an off-the-shelf CRM fits — and if it doesn't, it's most of the spec for the build.

I build custom CRMs and vertical platforms for small teams, and I'll tell you when HubSpot is the cheaper answer — I'd rather lose a project than build the wrong system. If you want an honest read on your situation, send me the details.