Build, buy, or build on top: the CRM decision

Buying is cheapest until your process does not fit. Building from scratch buys a perfect fit at a price most teams should not pay. Building on top of an existing core gets most of the fit for close to the price of buying. Which is right comes down to one question: how standard is your process, honestly.

Most build-versus-buy articles present two options. There are three, and the third is where most small and mid-size companies should end up.

Option 1 - Buy

Pick a product, pay per seat, use what is there.

What you get. Working software today. Years of accumulated features. A support team. Someone else's problem when it breaks. Integrations already built. This is a genuinely strong offer and most companies should take it. We have compared the main options in HubSpot alternatives for small teams.

What it costs. The licence is visible. The rest is not:

• Per-seat pricing scales with your growth, not with your usage
• Tier gating means one needed feature can move your whole team up a bracket
• Add-ons accumulate until the base price is a minority of the bill
• Implementation, which the industry treats as a two to three month project

The cost nobody models. If the product does not fit, you pay in workarounds - hours maintaining a spreadsheet beside the CRM, errors from two sources of truth, every new starter learning the exception, reporting that is never quite right. It never appears on an invoice, which is exactly why it does not get counted.

Choose it if your process is standard. Most are.

Option 2 - Build from scratch

A development team builds you a CRM starting at nothing.

What you get. Exactly what you specify. No licence per seat. Full control of the roadmap. Your data, your infrastructure.

What it costs. More than the quote, in a specific way that catches people: you are paying to rebuild contact management, deal tracking, pipeline views, permissions, email sync, search, notifications, mobile access and reporting. None of that is where your business is different. All of it is required before the system is usable.

Then you own it. Bugs, browser updates, security patches, the API that changes underneath you, and the feature your team asks for in month eight. Software is not a purchase, it is a subscription you pay in engineering time.

Choose it if the CRM is your competitive advantage - if how you manage relationships is the business. That is real for some companies. It is not real for most, and we have talked people out of it.

Option 3 - Build on top

Start with a working CRM whose core can change. The standard 80% exists. The part specific to your business gets built into the product rather than worked around.

What you get. Working software today, and a route for the thing that does not fit. No shadow spreadsheet, because the exception becomes part of the system. This is what we mean by a custom CRM, and it is not the same as building one.

What it costs. Close to buying. Ours is priced per engagement rather than per seat, with a fixed quote after one scoping call covering migration, the first custom build and training. The economics work because customisation here is additive - you are not paying for the foundation, only for the part that is about you.

The trade-off, stated honestly. You are dependent on a smaller vendor than HubSpot. Fewer third-party integrations exist out of the box. If you want a marketplace with four hundred apps in it, this is not that. What you get instead is that a change request is a conversation rather than a feature request into a queue.

Choose it if one or two parts of your business are genuinely different and the rest is normal. That describes a lot of companies.

Three years, side by side

Monthly price is the wrong comparison because the three options fail differently over time.

Buying starts cheapest and stays cheap if the fit holds. If it does not, cost grows invisibly through workarounds, and the visible bill grows through seats and tiers.

Building from scratch is expensive up front and does not stop. Year two and three carry maintenance, and the team that built it has usually moved on.

Building on top starts near the buying price and grows in steps, when you ask for something. No surprise tier jumps, no invisible workaround tax.

The number worth calculating is not the licence. It is: how many hours a month does someone spend doing something the software should be doing? Multiply by their cost. That figure decides this more often than the invoice does.

How to decide in one sitting

Is there already a spreadsheet the CRM cannot replace?
No → buy. Yes → keep reading.

Is the thing in the spreadsheet one or two workflows, or is it the whole way you work?
One or two → build on top. The whole thing → possibly build from scratch, but get a second opinion first.

Is the CRM your competitive advantage?
Honestly, almost certainly not. If it genuinely is, building from scratch becomes defensible.

Would you rather pay in money or in engineering attention?
Money → buy or build on top. Attention → build, and be sure you have the attention to spare.

The asymmetry worth knowing

Choosing wrong is not equally bad in both directions.

Buy wrong and you migrate. It is annoying, it costs a few weeks, and you keep your data.

Build wrong and you own a system nobody wants to maintain, along with the sunk cost that makes replacing it politically hard. That asymmetry is a good argument for starting at the cheaper end and moving up only when something forces you to.

Which is the actual case for option three. It is the one you can be wrong about most cheaply.