Most CRM decisions get made on the wrong number. Someone compares a licence quote with a build estimate, and the bigger figure loses. The costs that decide the question usually sit elsewhere: hours spent working around the system, the admin needed to keep it usable, and the price of every new seat as you grow.
This is the framework we use when a business asks whether to keep paying for Salesforce, HubSpot or GoHighLevel, or build its own. Sometimes the answer is build. Often it is buy, or fix what you have.
What "build" and "buy" actually mean
A custom CRM is a customer relationship management system designed and built around one organisation's sales, service and account processes, instead of configured from a commercial platform. The business owns the data model, the code and the roadmap, and takes responsibility for hosting, security and ongoing improvement, either in house or through a partner it chooses.
In practice the choice is rarely binary. There are four positions on the spectrum:
- Buy and configure: a commercial CRM set up as closely to your process as its settings allow.
- Buy and integrate: the same platform, properly connected to quoting, finance, job or booking systems.
- Buy plus a custom layer: the CRM stays the system of record, with a purpose-built tool on top through its API.
- Build: a custom CRM replaces the platform, and sometimes the tools around it.
Seven tests for build or buy
If most point to buy, fix the configuration. If several point firmly to build, run the numbers properly.
1. Fit to process
How much of your real process happens inside the CRM? If quoting lives in spreadsheets and approvals in email, the platform is recording your process rather than running it. Poor fit shows up as double entry and reports nobody trusts.
A standard sales cycle fits almost any commercial CRM. Engineered quoting, distributor pricing, membership renewals or multi-site scheduling often does not.
2. Seats and growth
Per-seat pricing scales with headcount, not with value. Salesforce's Australian Sales Cloud pricing page lists its editions in AUD per user per month, with most editions billed annually. HubSpot's own documentation says purchased seats can't be reduced until your next renewal date. So ask how many people will need access in three to five years, and whether each creates enough value to justify a seat.
Flat-fee platforms change the maths. HighLevel's pricing page lists monthly plans with unlimited users, with usage-based costs for telecommunications and AI services on top. On a platform priced like that, the case for building rarely rests on licence savings. It rests on fit, data and admin.
3. Integration needs
List every system the CRM must exchange data with: forms, phones, quoting, accounting, job management, inventory and booking. If integrations are the point of the system, a custom build treats them as core design rather than bolt-ons running through middleware. If you need two or three standard connections, a platform marketplace usually covers them.
4. Data ownership and control
Exporting records is easy. Owning the data model is different: deciding what a customer, a site, a contract or a distributor is, and how they relate. If your commercial model is unusual, that matters.
Privacy obligations don't change with the choice. If you're covered by the Privacy Act, Australian Privacy Principle 11 requires reasonable steps to protect personal information from misuse, interference, loss and unauthorised access, and APP 8 sets out steps before it is disclosed overseas. Ask where data is hosted and who can access it, either way.
5. Customisation debt
Every custom object, scripted workflow and bespoke connector inside a commercial platform is code you maintain on someone else's roadmap. If you already pay specialists to maintain heavy customisation, you are building on rented land. That is the strongest single signal that a custom system deserves a proper look.
6. Admin overhead
Count hours spent on users, permissions, field clean-up, reports and broken automations, plus any partner retainer. A custom system still needs an owner, but nobody should spend their week fighting the configuration.
7. Total cost of ownership over three to five years
The first six tests feed the last one. Here is how they line up:
| Test | Points to buy | Points to build |
|---|---|---|
| Fit to process | Standard sales cycle | Process lives in spreadsheets and email |
| Seats and growth | Stable, modest seat count | Seats growing faster than revenue per seat |
| Integration needs | A few standard connectors | Integrations are the point |
| Data ownership | Standard customer and deal model | Unusual commercial model |
| Customisation debt | Light configuration | Heavy scripted customisation |
| Admin overhead | A few hours a month | An administrator plus partner fees |
| Five-year TCO | Break-even budget thin or negative | Break-even budget funds a proper build |
The total cost of ownership formula
Only include costs that differ between the options, and ignore money already spent on the current platform: it is sunk either way.
Staying on a commercial platform
TCO(buy) = Σ (seats in each year × price per seat per month × 12) + N × (A + I + W)
Building
TCO(build) = B + O + G + N × (m × B + H + R + W2)
Set the two equal and solve for B. The result is the break-even build budget: the most you could spend on a build and still come out level over N years.
Break-even B = (TCO(buy) − O − G − N × (H + R + W2)) ÷ (1 + m × N)
| Variable | What it covers |
|---|---|
| N | Years compared, usually 3 to 5 |
| A | Annual admin and partner support |
| I | Annual middleware subscriptions |
| W | Annual cost of today's workarounds: re-keying, side spreadsheets, reconciliation |
| B | One-off discovery, design, build and testing |
| O | Licences still paid during the build and parallel run |
| G | Migration: data cleansing, mapping, testing, training |
| m | Annual maintenance and improvement, as a share of B |
| H | Annual hosting, monitoring, backups and security tooling |
| R | Annual internal product-owner time |
| W2 | Annual cost of workarounds remaining after the build |
If you haven't costed your workarounds before, the method in how to calculate the cost of manual admin gives you W and W2.
Worked calculation: a growing sales team
Every figure below is an assumption for illustration. None is a vendor price or a quote from us.
| Input | Assumption |
|---|---|
| N | 5 years |
| Seats | 40 in year 1, adding 8 a year |
| Blended licence cost | $250 per seat per month |
| A | $60,000 a year |
| I | $6,000 a year |
| W | 15 hours a week, 48 weeks, at $60 an hour loaded |
| Build and parallel run | 6 months, current licences continuing |
| G | 300 staff hours at $60 |
| H | $24,000 a year |
| R | 0.2 of a $130,000 loaded role |
| W2 | 3 hours a week |
| m | 20% of the build cost a year |
| Line | Calculation | Result |
|---|---|---|
| Licences | (40 + 48 + 56 + 64 + 72) seat-years × $250 × 12 | $840,000 |
| Admin | 5 × $60,000 | $300,000 |
| Middleware | 5 × $6,000 | $30,000 |
| Workarounds | 15 × 48 × $60 = $43,200 a year, × 5 | $216,000 |
| TCO(buy) | Sum of the above | $1,386,000 |
| Overlap (O) | 40 × $250 × 6 months | $60,000 |
| Migration (G) | 300 × $60 | $18,000 |
| Hosting (H) | 5 × $24,000 | $120,000 |
| Product owner (R) | 5 × $26,000 | $130,000 |
| Remaining workarounds (W2) | 3 × 48 × $60 = $8,640 a year, × 5 | $43,200 |
| Build-side costs before B | Sum of the five lines above | $371,200 |
| Break-even B | ($1,386,000 − $371,200) ÷ (1 + 0.2 × 5) | $507,400 |
On these assumptions, a build that genuinely replaces the platform and costs less than about $507,000 to deliver comes out ahead within five years. Add a 5% licence increase at each renewal and the break-even figure rises to about $558,000.
The same formula, a different business
Now assume a stable team of 20 seats at $150 per seat per month, $15,000 a year of admin, the same middleware and just 3 hours a week of workarounds (all assumptions). Five-year TCO(buy) is $180,000 + $75,000 + $30,000 + $43,200 = $328,200. Build-side costs before any build work already total $329,200. Break-even is below zero. Keep the platform.
Run your own figures through the software licence calculator. A break-even figure doesn't tell you whether a build is wise. It tells you how much room there is.
The honest case for buying
- Speed: a commercial platform can be running in weeks. A custom system needs discovery, design, build, testing and migration first.
- Breadth: mature platforms ship features you haven't thought to ask for yet.
- Shared risk: security patching and uptime are the vendor's job, with the cost spread across many customers.
- Hiring: people who know the major platforms are easier to find than people who know your custom system.
- Exit: a subscription is easier to stop than a system to retire.
If your process is close to standard and your seat count is stable, buying is usually right. We will say so in a Diagnostic, because Buy and Leave alone are legitimate recommendations. We are not looking for things to build.
The middle path: configure, integrate or build on top
Before replacing anything, check whether one of three smaller moves solves the problem.
Configure better
Remove unused fields, rebuild pipelines around real stages, fix permissions and audit who holds a paid seat. HubSpot, for example, offers free, unlimited view-only seats on its paid subscriptions, so people who only read records and dashboards may not need a paid seat.
Integrate properly
Many "the CRM doesn't work" complaints really mean "the CRM doesn't talk to anything". Connecting it to your website, phones, accounting and job systems through system integrations removes re-keying without moving a single record.
Build a focused layer on top
Keep the CRM as the system of record and build only the piece that sets you apart: a quoting engine, a client portal, a field app or a reporting dashboard. You get custom software where it pays and keep the commodity part as a subscription. The manufacturer quoting example shows how a quoting tool and a CRM can be scoped as one system.
Migration risk, and how to manage it
We'd put more of the risk in a CRM change on migration and adoption than on the build itself. Plan for these before you commit:
- Data quality: duplicates and missing history surface during migration. Budget time to cleanse and map data, and decide what not to bring across.
- Hidden logic: inventory every automation, email template and report before you switch anything off. Many were never documented.
- Contract timing: licences are usually committed in advance. Map renewal dates so the parallel run ends before the next term starts.
- Adoption: involve daily users in design and testing. A better system the sales team avoids is a worse system.
- Dependency: own the code, run it in accounts you control, and document it well enough for another developer to take over.
- Parallel run: run old and new side by side, reconcile the numbers, then cut over.
The association platform replacement example walks through a staged move from a CRM, events and email stack to one member platform. Our platform replacement service is planned around exactly these risks.
How to make the decision
- Map your actual process end to end, spreadsheets and emails included.
- Count seats today and in three to five years.
- List every integration and who maintains it.
- Measure admin and workaround hours for two weeks.
- Run the TCO formula with your contract figures.
- If the break-even budget is thin, try the middle path first. If it is comfortable, scope the build properly before committing.
We scope AI, systems and platform work individually, usually after a Diagnostic or a fixed-scope discovery, so a build estimate can be tested against your break-even figure before anyone writes code. We run our own finance on a platform we built, so we know the ownership trade-offs from the inside.