Ask whether this is where you compete
The strongest reason to build is that the process itself is a source of advantage — you do it differently from competitors, and that difference matters to customers.
For everything else — payroll, accounting, support ticketing, email — a bought product is almost always correct, because you will never out-invest a vendor whose entire company is that one product.
Cost both sides honestly
Build estimates habitually omit maintenance, which runs for the life of the system and typically exceeds the original build. Buy estimates habitually omit implementation, integration, training, and the internal time to run it.
Compare five-year totals with those included. The comparison often reverses once they are.
Distinguish configuration from customisation
Configuring a product within its intended flexibility is cheap and upgrade-safe. Customising it beyond that — bespoke modules, modified core, extensive workflow rewrites — is expensive, fragile, and frequently blocks upgrades permanently.
During evaluation, establish which of your requirements are configuration and which are customisation. A product needing heavy customisation is often more expensive than building, with less control.
Consider the hybrid
The best answer is frequently both: buy the commodity core, build the thin layer that is genuinely yours, and integrate them properly.
This requires the bought product to have a real API and sane extension points, which is worth weighting heavily during selection precisely because it preserves this option.
Weigh the risks against each other
Building risks: it takes longer than planned, the people who built it leave, and it becomes a maintenance obligation nobody wants. Buying risks: the vendor changes pricing, gets acquired, deprecates what you depend on, or simply cannot do the thing you need next year.
Neither is safe. The question is which failure mode you are better positioned to survive.
Decide reversibly where you can
Prefer the option that keeps a path back. Buying with clean data export and a documented exit is more reversible than a deep bespoke build; building against a standard interface is more reversible than embedding a vendor's model throughout your systems.
Where a decision cannot be made reversible, that is precisely where to spend more time on evidence before committing.