Custom software vs off the shelf: which one you actually need
Buy when the process is standard, the vendor category is mature, and the product can represent how you actually work. Build when the process is something you compete on, or when the products on offer are either far too heavy or so generic that configuring them becomes its own project. Most businesses land between the two, and that middle answer is usually the right one.
When off the shelf wins
If your process is roughly how everybody in your industry does it, somebody has already built software for it and spent years finding the edge cases you have not hit yet. Payroll, accounting, email, help desk ticketing: these are solved categories, and building your own version of one is an expensive way to arrive somewhere a product would have taken you on day one.
A mature category is the strongest signal. Several credible vendors competing means the products have been pushed hard by demanding customers, the integrations you need probably already exist, and if the relationship goes wrong there is somewhere to go. A single vendor with no real competitor is a weaker position than it looks, whatever the demo showed.
HDS says this from having done it. One of the engagements on both a rebuild and a ground-up platform was a Dynamics 365 Sales rebuild rather than a new system: mid-market concrete contractor, with the platform kept and reshaped around the sales process the business actually ran, plus the reporting layer on top of it. That is buy-and-configure work, and it was the right call.
When custom wins
The clearest case is a process the business genuinely competes on. If how you run something is part of why customers choose you, forcing it into a vendor's object model flattens exactly the thing that makes you different, and the workarounds needed to preserve it end up living in spreadsheets and in one person's head.
The second case is the squeeze between too heavy and too generic. A brokerage on the work page hit precisely that. A relationship-led practice cannot run on a generic CRM. Deal tracking, market intelligence, and follow-up all wanted different tools, and every one of them expected the broker to sit at a dashboard rather than work the market. That is not an unusual position, and it is the one where a bounded build stops being a luxury.
The third is an integration surface nobody sells. When the useful answer only exists by combining three systems that were never designed to talk, the connective work is the product, and no vendor is going to ship it for your particular three. What custom is not is a way to avoid the discipline of buying well: if the problem fits a product, the honest recommendation stays buy it.
Configure the platform, build the edges
Most businesses do not face a clean choice, and the honest third answer is that they should not pretend to. Keep the platform for the work it already does well, where its maturity is a genuine asset, and build only the parts it cannot represent. That way you are not rebuilding solved problems and not distorting your operation to fit somebody else's model either.
What makes this work is the connection between the two. The failure mode is a platform and a custom tool that only meet through somebody exporting a CSV every Monday, which is a manual process with extra steps and a place for the numbers to quietly diverge. Done properly the two share a source of truth, and the custom piece reads and writes through the platform's own interfaces.
This is also the sequence with the least regret in it. Configure what exists, run it under real load, and let the genuine gaps declare themselves. The gaps still there after six months of daily use are the ones worth building, and they are a far better specification than a requirements document written before anybody had used anything.
The decision, factor by factor
Read down the column that matches more rows. Few businesses match one column cleanly, and a split verdict is the middle path rather than a tie.
| Factor | Points to buying | Points to building |
|---|---|---|
| The process itself | Standard, and roughly how everyone in the industry does it | Something the business competes on, or genuinely peculiar to it |
| Vendor category | Mature, several credible products, real competition | Products are either built for a far larger operation or so generic that configuring them is its own project |
| Integration surface | Little, or covered by connectors the vendor already ships | Several systems that have to agree, and nobody sells the bridge |
| Time to first use | Immediate, once configuration and data migration are done | A first phase in production early, with scope shaped against it |
| What you own afterwards | A subscription and a configuration you can take elsewhere with effort | The system and the data model, on infrastructure you control |
| Where the cost sits | Per seat, forever, rising as headcount does | Up front, then hosting and the changes you choose to make |
Clarksville, Nashville, and Middle Tennessee
The decision does not change by city, but who you can ask about it does. HDS works from Clarksville across Middle Tennessee including Nashville and Montgomery County, and scoping conversations routinely end with a recommendation to buy something rather than a proposal to build.
For local engagements that conversation is easier to have in person, particularly when the disagreement is about whether a process is genuinely unusual or just familiar. Watching the work get done settles that faster than describing it does. If the answer turns out to be build, the money side is on what building costs, and the practice itself is under custom software engineering.
Build versus buy questions
Will you tell me to buy something if that is the right answer?
Yes, and it happens in scoping regularly. If the problem fits a product you can buy, buying it is the honest recommendation, and hearing that costs you one conversation rather than a project. A shop that only builds has an obvious reason to never reach that conclusion, which is worth keeping in mind whoever you ask.
Is custom always more expensive than a subscription?
Not always, and the comparison is usually drawn wrong. Per-seat pricing scales with headcount indefinitely while a build is mostly an up-front cost, so the crossover depends on how many people use it and for how long. The stronger argument for buying is rarely price, it is that a mature product has already solved problems you have not thought of yet.
We bought a platform and it does not fit. Do we start over?
Usually not. The common answer is the middle path: keep the platform for what it does well and build only the parts it cannot represent, connected properly rather than bridged by exports. Starting over is occasionally right, but it is a much bigger claim and it should have to earn itself.
How do we know if our process is genuinely unusual?
A useful test is what happens during a product demo. If the vendor keeps showing you a workflow adjacent to yours and your team keeps saying yes, but, that gap is the thing. If instead you are quietly noticing you should probably work the way the product does, that is a strong signal to buy and change the process.
Can we start with the platform and build later?
That is often the lowest-risk sequence. Configure what is available, run it, and let the genuine gaps declare themselves under real use rather than during a requirements exercise. The gaps that survive six months of daily use are the ones worth building, and they are a far better specification than anything written in advance.
Describe the process and find out which answer it deserves.
Start with a free scoping conversation with Mike Hyams, the person who builds and supports the work.