We build custom software for a living, so treat what follows with appropriate scepticism — and then check it against your own numbers. The comparison below is the one we actually walk clients through, including the cases where we tell them not to build.
The distinction that matters isn't "custom vs. not custom." Configuring Salesforce is customization. So is a HubSpot workflow, an Airtable automation, or a no-code app. The real distinction is whether your system is shaped inside someone else's product model or built directly against your own.
Cost: the shapes are different, not just the numbers
Platform customization is cheap to start and priced perpetually. You pay per seat, per month, forever, plus the implementation partner, plus the connectors, plus the add-on modules that turn out to be necessary. The cost curve rises with headcount and complexity, and it never terminates.
Custom software is expensive to start and cheap to hold. You fund a build, then pay for hosting and maintenance. The cost curve is steep at the front and flat afterwards, and it does not rise when you hire twenty more people.
The crossover point depends almost entirely on seat count and integration load. A ten-person company on standard tooling will likely never reach it. A sixty-person operation paying for four platforms, three connectors and a part-time admin to keep it running usually reached it a while ago and hasn't done the arithmetic. Run the five-year total for both, including internal time spent on workarounds, before deciding.
Timeline: fast to launch vs. fast to change
A platform gets you live faster. That's a genuine advantage and shouldn't be minimised. A competent implementation partner can have a configured CRM running in weeks.
Custom builds take longer up front — for a real operational system, typically a few months rather than a few weeks. What you buy with that time is a different change velocity afterwards. On a platform, a change that fits the product model is quick and a change that fights it can be impossible at any price. On a custom system, change cost scales with the actual complexity of what you're asking for, not with whether the vendor anticipated it.
The right question isn't "how fast can we launch?" It's "how fast can we change this in year three, when we know things we don't know now?"
Flexibility: bounded by a product model or by engineering effort
Everything you build on a platform lives inside its data model, permission system, API limits and release schedule. Within those bounds you can do a great deal. Outside them you can do nothing, and no budget changes that.
Custom software has no product-model bound. Its constraint is engineering effort — real, but purchasable and predictable. Complex payroll rules, unusual compliance workflows, industry-specific scheduling logic and multi-entity permission structures are just work, rather than a request the vendor may or may not accommodate in a future release.
The corollary is also true: if your process is genuinely standard, that flexibility buys you nothing. Paying to rebuild a normal sales pipeline from scratch is a bad trade.
Ownership, data and risk
On a platform you own your data but not your system. Pricing changes, roadmap changes, deprecations and acquisitions all land on you, and your operational logic is expressed in a configuration format you cannot take anywhere. Migration cost is the real lock-in.
With custom software you own the codebase, the schema and the deployment. Your risk profile inverts: no vendor pricing exposure, but you're responsible for maintenance, security and continuity. That responsibility is only comfortable if the code is well-documented, conventionally built and handed over properly. Ask any vendor — including us — exactly what you receive at the end and what happens if the relationship ends. If the answer is vague, that's your answer.
When the platform is the right call
- Your sales process is broadly conventional and your differentiation isn't in operations.
- You're under roughly 25 seats and integration load is light.
- You need something running in weeks, not months, for a reason that matters.
- You don't have — and don't want — a technical partner relationship over the long term.
- The workflows you need already exist in the product with minor configuration.
When building from scratch is the right call
- Your operational model — how you schedule, dispatch, staff, comply or bill — is the competitive advantage.
- Multiple systems hold partial copies of the same record and someone reconciles them weekly.
- Seat licensing is pushing people out of the system who should be in it.
- You've been told "the platform can't do that" about something that materially matters.
- You expect meaningful headcount or complexity growth over the next three to five years.
The hybrid nobody mentions
It's rarely all-or-nothing. Plenty of companies keep an excellent standard tool where it's genuinely strong — accounting is the usual example — and build custom software around the operational core that no vendor models well. A well-designed custom system integrates with what already works instead of insisting on replacing it.
That's usually the most defensible answer: build what's specific to you, buy what's genuinely commodity, and integrate the two properly rather than through a chain of brittle connectors.
The short version
- Platform customization is faster and cheaper to start, and bounded by a product model. Custom software is slower and costlier to start, and bounded only by engineering effort.
- Run the five-year total cost for both, including internal workaround time, and be honest about whether your operations are actually differentiated. If they aren't, buy the platform.