The build, buy, or configure question gets argued as if it were a matter of philosophy. Some people are builders by temperament, some are buyers, and they will each defend their instinct with conviction. We try to ignore the temperament and answer the question the only way that holds up, which is by looking honestly at the thing itself. Most of the time the right answer is sitting there in plain view, once you stop asking which approach you prefer and start asking what the work actually is.
The first cut is simple. Is this thing genuinely distinctive to your business, or is it the same as it is for everyone else? Payroll is payroll. Accounting is accounting. You should almost never build those, because someone has spent a decade polishing a product that does it well, and you will not beat them by starting from scratch. Buy it, configure it, move on. The mistake is treating a commodity as if it were special and pouring effort into rebuilding what you could have rented.
The harder and more interesting cases are the things that are genuinely yours. The particular way you handle a charter, route a job, or manage an exception that your competitors do not have. That is where your edge lives, and it is exactly where off the shelf products fit worst, because they were built for the average and you are not trying to be average. Here the honest answer is often to build, or more precisely to configure with low code so that the thing fits your operation rather than forcing your operation to fit the thing.
The second cut is speed of change. If a process is settled and will look the same in five years, a packaged product is fine, even if the fit is imperfect, because you can adapt around it once and forget it. But if the process changes constantly, if your edge is partly that you can move faster than the people you compete with, then you need something you can change on your own timetable. Waiting on a vendor's roadmap to adjust how your core operation works is a slow way to lose what made you good.
This is where low code has quietly changed the maths. It used to be that build meant slow, expensive, and risky, which pushed everyone toward buying even when the fit was poor. Low code makes it realistic to build the distinctive parts quickly and keep changing them, while still buying the commodities. Most of our clients end up with a sensible blend. Bought tools for the universal work, configured low code for the work that is theirs, the two connected so the truth stays in one place.
The Discovery Sprint exists partly to make this call with evidence rather than instinct. In two to four weeks we can usually tell which parts are commodity and which are your edge, and the prototype proves the fit before anyone commits real money. Decide it that way, on what the thing is and how fast it moves, and the build, buy, or configure argument mostly answers itself.
Facing something similar in your business?
Talk it through with our AI guide, or send the team a note. We will tell you straight whether and how we can help.