Build or buy: a decision framework for enterprise software

Every enterprise software conversation eventually arrives at the same fork: build it ourselves, or buy something that already exists. The vendors selling off-the-shelf suites will tell you buying is always cheaper. The consultancies selling custom builds will tell you buying is always a compromise. Neither is telling you the truth, because the answer depends entirely on what you’re actually trying to run.

What buying gets right

Off-the-shelf software wins when the process it automates is not your differentiator. Payroll compliance, expense reporting, ticketing: these are solved problems, and a vendor serving five hundred customers has already found edge cases you haven’t hit yet. Buying also compresses time to value from months to weeks, and it moves the burden of security patching and uptime onto someone whose full-time job that is.

Where the off-the-shelf ceiling shows up

The ceiling appears the moment your organization’s structure stops matching the vendor’s assumptions. We built a platform that now runs more than 100 modules for a government institution: hiring, attendance, career progression, and payroll, all governed by regulations and approval chains no commercial HR suite was built to model. Every attempt to bend an off-the-shelf product to fit produced a worse outcome than starting from the actual org chart and building outward. At that scale, a custom build isn’t a luxury. It’s the only way the software matches how the institution actually works, not how a vendor assumed institutions work.

FIELD NOTE A public-sector client had already spent eighteen months trying to configure a commercial HRIS around a hiring workflow with an audit requirement the product simply could not express. We rebuilt that single workflow from the ground up in six weeks, inside a platform we owned end to end.

The framework we actually use

Before recommending either path, we ask three questions. First, is this process how you compete, or how you comply? Compliance work tends to buy well. Second, will the requirements still be recognizable in five years, or does your organization change faster than a vendor’s roadmap? Third, who inside your organization will own the system once it ships, and does that person want a configuration file or a codebase? The answers, more often than a feature checklist, tell you which side of the fork you’re actually on.

Build or buy isn’t a philosophy. It’s a decision with a correct answer for your specific organization at this specific moment, and the fastest way to get it wrong is to let whoever is in the room selling something make the call for you.