Build vs buy: when custom sales tools beat another platform
The build-versus-buy question is usually framed wrong. It is not custom code against a licence fee. It is fit against configuration: how much of your process you are willing to bend to match software someone else designed.
Buy when your process is genuinely standard. Build when the process is how you compete, or when the platform that fits costs more in configuration and unused seats than the tool is worth. Five tests below will tell you which you are looking at.
Why the usual framing fails
The classic version of this decision compares a licence fee against a development estimate, concludes that building is more expensive, and stops. That comparison made sense when building meant six months and a team of engineers.
Two things broke it. First, AI development tooling collapsed the cost of the first working version from months to weeks. Second, the real cost of buying was never the licence: it was configuration, implementation, integration, training, and the seats you pay for but never use.
So run the comparison on total cost and fit, not sticker price against estimate.
Test 1: Is the process standard or is it how you compete?
Email sequencing is standard. Everyone does it roughly the same way, and the vendors have spent a decade polishing it. Buy it.
But if your pricing logic, your renewal motion, or the way you qualify an account is genuinely different from your competitors, and that difference is part of why you win, then bending it to fit a platform's data model actively costs you money. That is the part to build.
The test: if a competitor copied this process exactly, would it hurt you? If yes, do not outsource its shape to a vendor.
Test 2: How many systems does it have to touch?
Count the systems that need to be in one view: CRM, billing, support desk, product analytics, a data warehouse, two spreadsheets.
One or two, a platform will probably handle it. Four or more, particularly with anything old or in-house, and you reach the point where "integrates with everything" turns out to mean "integrates with the twelve tools we picked". The integration surface is usually the real reason custom wins, and it is the thing most build-versus-buy analyses forget to price.
Test 3: Do the seat economics work?
Per-seat pricing punishes exactly the pattern most revenue tools have: a handful of heavy users and a long tail of people who need to look at it occasionally.
Do the arithmetic honestly. Forty seats at $120 per user per month is $57,600 a year for a tool where six people use it daily. That is not a licence decision, it is a build decision, and it will keep being one every year.
Enterprise platforms in this category commonly land near $48,000 a year with a six-month implementation. If a custom build solves the actual problem for a fraction of that and you own it afterwards, the comparison is not close. If the platform genuinely fits, that money is well spent.
Test 4: When do you need it working?
An enterprise implementation is a two-quarter project before anyone sees value, and it consumes internal time you are not counting: workshops, data mapping, testing, training.
A focused custom tool is two to three weeks to something real people use. If the problem is costing you money now, time-to-value is not a soft consideration, it is most of the return.
Test 5: Who maintains it?
This is the test that should stop some build decisions, and it is the one enthusiasm skips past.
Custom software needs an owner. Someone has to fix it when an upstream API changes, add the field the team asks for in month four, and care whether people still use it. If you have nobody, either buy, or hire the build with an ongoing arrangement that covers maintenance. Do not commission a one-time build into an organisation with no capacity to keep it alive. That is how companies end up with three abandoned internal tools and a policy against building.
Scoring it
| Test | Points to buy | Points to build |
|---|---|---|
| Process | Standard, everyone does it this way | Distinctive, part of how you win |
| Integrations | One or two mainstream systems | Four or more, or anything legacy |
| Seats | Most seats are heavy users | Few heavy users, long occasional tail |
| Timeline | Two quarters is acceptable | Needed this quarter |
| Ownership | Nobody will maintain it | Named owner, or a retained builder |
Three or more pointing the same way is your answer. A genuine split usually means the honest answer is the third option nobody offers.
The third option
Do nothing yet. If the process is still changing every week, building around it produces the wrong shape and buying locks in a mismatch. Leave it in the spreadsheet deliberately, for now, and revisit when it settles. A spreadsheet is a perfectly respectable prototype. It is only a problem when it becomes load-bearing infrastructure by accident.
What "build" actually costs now
For a single team tool with real data, authentication, and per-user permissions, expect two to three weeks and a project fee in the low five figures, plus either an internal owner or a maintenance arrangement. Compare that to the platform's first-year total: licence, plus implementation, plus the internal hours nobody logs.
What tips it further is that you keep the result. The build does not renew, does not reprice at 18% next year, and does not sunset the feature you depend on.
For what these tools look like team by team, see our guide to custom GTM tools.
Frequently asked questions
Should we build or buy sales software?
Buy when the process is standard and the platform genuinely fits. Build when the process is part of how you compete, when four or more systems must be integrated, when few people need heavy access but many need occasional access, or when you need value this quarter rather than in two.
Is building custom sales tools cheaper than buying a platform?
Often yes now. A focused team tool typically costs two to three weeks and a low five-figure fee, against enterprise platforms commonly near $48,000 per year plus a six-month implementation. The decisive factor is whether you have someone to maintain the result.
What is the biggest risk of building custom internal tools?
No owner. Tools die in month three when nobody fixes breakages, adds requested fields, or tracks whether people still use them. If you cannot name an internal owner, either buy instead or contract the build with ongoing maintenance included.
When should we do neither?
When the process is still changing weekly. Building around an unsettled process produces the wrong shape, and buying locks in a mismatch. Keep it in a spreadsheet deliberately and revisit once the process stabilises.
Want a second opinion on a build-vs-buy call?
We'll tell you if a platform fits better. Thirty minutes, and we have talked people out of building before.
Book a 30-minute call