Configure, buy or build: the three-way decision most people get wrong
Configuration is the answer far more often than either vendor will tell you, because nobody makes money recommending it. Try it first, deliberately and with a deadline. Buy when the function is a commodity. Build only when you can name the specific object or workflow that no product models — and then build only that, not everything around it.
Should we configure what we have, buy something new, or build?
How to decide:
You have not used the features you already pay for. Configure. Most teams run a fraction of their current tier. Audit that before spending anything.
The objects fit and the workflow does not. Configure. Workflow is what configuration is for. A rebuild here solves a problem you do not have.
The function is a mature commodity. Buy. Accounting, payroll, e-signature and helpdesk are solved. Building them is a hobby.
You need it working in weeks. Buy. Time is a real constraint and buying wins it decisively.
You can name the object no product models. Build. This is the only reliable trigger for building. If you cannot name it in one sentence, you are not there yet.
The process is what customers pay you for. Build. Renting your differentiator from a vendor every competitor can also hire removes your advantage.
What drives the cost:
Configuration is cheap and it is not free. It costs a good admin's time and a deadline. Open-ended configuration projects are their own failure mode — set a date to stop and decide.
Buying costs more than the licence. Implementation, migration and training are the real number. Compare total first-year cost, not the per-seat headline.
Building costs more than the build. Maintenance, hosting and the person who understands it are permanent. A build with no owner has a shorter life than a licence.
Doing nothing has a price too. The hours currently spent working around the gap are a real recurring cost. Quantify them, because they are usually the largest number on the page and the only one nobody has written down.
What people get wrong:
Skipping configuration because it is boring. Building is more interesting than configuring and that biases the decision more than any spreadsheet. Notice when that is happening.
Letting the vendor scope the decision. A platform partner recommends configuration, a dev shop recommends building, and both are answering honestly from inside their own business model. Ask each what would make them recommend the other.
Deciding once, forever. This is a decision with a shelf life. Revisit when headcount, regulation or your process changes materially.
Building everything around the one real gap. The gap might be one object. The temptation is to rebuild the whole surrounding system while you are in there, and that is how a six-week project becomes a year.
Why does nobody recommend configuration?
Because there is no margin in it. A platform partner bills implementation, a development firm bills a build, and configuration of what you already own bills almost nothing. It is still frequently the right answer.
How long should we try configuring before deciding?
Set an explicit deadline — a few weeks is usually enough to know. The failure mode is an open-ended configuration effort that quietly consumes a year and ends in a rebuild anyway.
Can we build one piece and buy the rest?
That is usually the best architecture available. Buy the commodity functions, configure the platform, build only the object nobody models. Coherent systems are assembled this way far more often than they are bought whole.
Who should make this decision?
Someone who owns the operational outcome, not the IT budget alone. The cost of the wrong call lands on the team doing the work, and they are the ones who can name the missing object.
Last reviewed 22 August 2026