We turn down custom builds fairly often. Not because the work is unappealing, but because a subscription would have solved the problem for a fraction of the cost, and saying so is the whole job.
The decision is not really "custom versus off-the-shelf". It is a question about where your competitive advantage lives.
The test
For any process you are considering systematising, ask: would a competitor doing this exactly the same way as us be at no disadvantage?
If the answer is yes, buy. Payroll, accounting, email, helpdesk, calendar, storage. Nobody has ever won a market by having a distinctive approach to payroll. Buy the best-supported option, configure it, and move on.
If the answer is no, if the way you do this thing is part of why customers choose you, then a generic tool will force you to do it the generic way. That is when building earns its cost.
The cost nobody quotes
The build price is the smallest number in the decision. What follows it:
- Hosting and infrastructure, forever
- Security patching and dependency upgrades
- Changes as your business changes
- The institutional knowledge required to keep it running
- The replacement cost when the original developers move on
A reasonable planning assumption is that ongoing ownership runs 15–20% of the original build cost per year. If that figure makes the project untenable, it was untenable. Better to find out during planning than in year three.
Off-the-shelf has an equivalent hidden cost, and it is usually understated too: the per-seat price that scales with headcount, the migration cost when you outgrow the tool, and the process compromises you absorb in the meantime.
The third option
Most teams frame this as a binary and miss the answer that fits best: buy the commodity parts and build only the connective tissue.
Use the accounting package. Use the CRM. Then build the thin layer that makes them behave like one system for your specific workflow: the integration, the automation, the single dashboard that answers the question your team actually asks every morning.
This is where the return is highest and the risk lowest. You are not rebuilding solved problems; you are solving the one problem nobody else has, which is how your operation fits together.
When to revisit
Buy-versus-build is not a permanent decision. The signals that it is time to look again:
- Your team has built a shadow spreadsheet to work around the tool
- You are paying for seats to give people read-only access
- A workflow that should take one system takes three
- You are being charged for scale you are not using, or throttled on scale you need
None of those mean "build immediately". They mean the assumptions behind the last decision have expired.
If you are weighing this up and want an outside read, we do this as a scoped engagement. That includes, sometimes, telling you not to build anything.
