Can a packaged product carry your business model, or only most of it?
The real platform question is whether a product fits your business model. If it does not, or you are not sure, a proper buy-vs-build evaluation decides, not a forced fit.
Every platform decision starts with one honest question: can a packaged product carry your business model as it actually works, or only most of it? The wrong instinct is to bend the business to fit the product. The right first move is to test the fit.
If it clearly fits, buy and configure
When a mature product covers the core of the process without fighting its own data model, configure it and move on. It is faster to stand up, the vendor funds the upgrades, and there is no bespoke code to maintain. This is the honest default, and most of the time it is the right answer.
If you are not sure, or it does not, evaluate
The moment the answer is “no” or “not sure” is the moment a real buy-vs-build evaluation has to happen: not a gut call, not a forced fit. Weigh what the product genuinely cannot do, the cost of forcing it (customisation that breaks on every upgrade), what it takes to maintain, whether it holds where reliability matters, and whether its roadmap goes where you are going. Bending the business around a product it was never shaped for is how projects crack later.
Building is an outcome of that evaluation, not a failure
When the evaluation says build, we build: an orchestration core on an event layer, with the failure modes engineered in (idempotent handlers, sagas and compensating actions, a dead-letter queue). Choosing to build, on the evidence, is judgment, not defeat. The real failure is configuring a product that almost fits and finding out where it does not during an incident.
The value isn’t defaulting to buy or to build. It’s testing the fit honestly and, when a product can’t carry your business model, evaluating properly instead of contorting the business to fit it.