Build or buy: how to decide before you spend.
You've evaluated three or four tools and all of them break on the one requirement you can't waive. You're not sure whether that means you need custom software, or whether you just haven't found the right product yet.
Key takeaways
- The build-versus-buy decision should be tested against a real, unwaivable constraint, not just against how many demos looked close.
- Off-the-shelf wins when your workflow already matches how most companies in your position work.
- Configuration wins when a platform's core model fits but specific fields or workflows do not.
- Custom only wins when a real regulatory, security, or workflow constraint rules out every existing product.
- The honest test is which option is cheapest across the system's full life, including workarounds and maintenance, not just the sticker price.
How it shows up
- Every vendor demo looks close until you ask about the one requirement that actually matters to you.
- You're customizing a tool so heavily that the vendor's own support team no longer recognizes your setup.
- The workaround for a missing feature has become a full-time job for someone on your team.
- A compliance, security, or data-handling rule rules out an entire category of otherwise-good products.
- You've paid for implementation twice, on two different platforms, and neither one stuck.
- Your workflow is specific enough that no product on the market was designed around it.
- The team has quietly built a spreadsheet-based workaround around the system it no longer trusts.
- Leadership is debating build versus buy and nobody in the room has actually done both.
The decision framework
When off-the-shelf wins
Off-the-shelf wins when your workflow is close to how most companies in your position already work. You're paying for a solved problem, and the vendor's roadmap becomes your roadmap. The hidden cost is fitting your process to the product, and living with whatever the vendor decides to change or discontinue.
When configuration wins
Configuration wins when a platform's core model fits your business but the specific fields, workflows, or reports don't, and the platform is flexible enough to be shaped without custom code. The hidden cost is the person who maintains that configuration permanently, plus the ceiling you hit when a future requirement falls outside what the platform allows.
When custom wins
Custom wins when a real constraint rules out every existing product, whether that's regulatory, security, or a workflow no vendor has built for, or when the software is itself the business's advantage. The hidden cost is real: a build takes longer to reach production than a subscription does, and the business now owns the maintenance.
The honest test
The right test is which option is cheapest across the full life of the system, including the workarounds, the maintenance, and the cost of the constraint you tried to ignore. An advisor with no incentive to sell you a build should be able to tell you honestly when buying wins, and most of the time it does.
The decision as a sequence
Inputs carrying uncertainty pass through three gates in order, and build is what's left when the first three fail, which is why it's drawn last.
Four inputs, three gates, four paths. The recommendation is whichever path the criteria reach first, and the record shows which gate the others failed at.
- 01The workflow as it actually runs Input.
- 02Where the data has to live Input.
- 03The constraint no product meets Input.
- 04Cost over five years, as a range Input.
- 05Does a product fit as sold? Decision gate.
- 06Does it fit configured? Decision gate.
- 07Does it fit integrated? Decision gate.
- 08Buy Option.
- 09Configure Option.
- 10Integrate Option.
- 11Build Option.
How we work it
- 01
Diagnose
We test your actual requirement, including the constraint that ruled out the products you already evaluated, against what off-the-shelf and configurable platforms can genuinely do. Then we say plainly whether there's a real gap, or whether an existing product got dismissed too quickly.
- 02
Advise
Where buying or configuring is the answer, we say so and help you select and scope the platform. Where the gap is real, we define exactly what has to be custom and what doesn't, so the build stays as small as the constraint requires.
- 03
Build
When custom is the honest answer, we design the constraint into the architecture before writing the first feature, whether that constraint is regulatory, security, or workflow, and build toward a viable first version, typically live within 120 days. Eleven 186 has shipped 8+ first-of-their-kind systems where no existing product fit the constraint.
- 04
Execute
We stay through the handoff: documentation, training, and a system your own team can run without the firm that built it. The point of a build is a client who no longer needs the builder, not a permanent dependency.
What changes
- You have a specific, written answer for why the business is building or buying, and it survives a skeptical question from a board member or a new hire.
- If you buy, you know exactly which requirement you're choosing to live without, rather than discovering it during onboarding.
- And if you build, the system is scoped to the real gap rather than to every feature a generic platform happens to have.
Questions before you spend
How do I decide between building custom software and buying an off-the-shelf product?
Start by testing whether your requirement is genuinely unmet by the market, or whether it only looks unmet because you haven't evaluated a configurable platform closely enough. Build only when a real constraint rules out every product you can reasonably evaluate, whether that's regulatory, security, or a workflow with no market equivalent.
What are the hidden costs of building custom software?
The two biggest hidden costs are time and ownership. A working custom system takes longer to reach production than signing up for a subscription does, and once it's live the business maintains it indefinitely instead of a vendor doing that as part of a subscription fee.
What are the hidden costs of buying off-the-shelf software?
The main hidden cost is fitting your process to the product's assumptions, plus the risk that the vendor changes, reprices, or discontinues a feature your business now depends on.
Can a firm that builds software give me honest build-versus-buy advice?
Only if it has no default incentive to sell you a build. We recommend buying or configuring when that's the cheaper, faster, and more defensible answer, and we build only when a real constraint rules out every existing option.
Tell us the problem
Describe the requirement that keeps breaking every product you evaluate, and we'll tell you honestly whether it means build.