The question rarely arrives in its clean form. It usually shows up as friction: an ERP that only works with a spreadsheet open beside it, a CRM the sales team quietly stopped updating, a customer portal that was “almost” what the business asked for. At that point someone asks whether the organization should build its own system or move to a different platform, and the conversation quickly turns into a debate about technologies rather than a decision about the business.
Both directions are expensive when chosen for the wrong reasons. Building what could have been licensed ties up budget and talent in software that creates no advantage. Buying a platform that does not fit forces the organization to reshape its operations around someone else’s assumptions. The framework below is the one we apply to make that decision deliberately.
Decide per capability, not per system
“Should we build or buy an ERP?” starts from the wrong unit of analysis. A system is a bundle of capabilities (approving a purchase request, scheduling a field technician, pricing a quote, onboarding a customer), and each one deserves its own answer. List the capabilities the initiative must deliver, then sort them into three groups:
- Commodity capabilities: general ledger, payroll, core HR, email, document storage. Every organization needs them, and doing them differently rarely creates value. These are strong candidates to buy.
- Differentiating capabilities: the pricing logic, service model, customer experience or operational workflow that sets you apart. If a competitor could license the same thing tomorrow, it is not differentiating. These are candidates to build.
- Localized and regulated capabilities: Arabic right-to-left interfaces, Hijri and Gregorian dates, ZATCA e-invoicing, national identity and payment integrations, sector-specific reporting. Platforms vary widely here, so test fit with evidence rather than brochures.
Five questions that settle most cases
- Is this capability a source of advantage, or simply a cost of doing business?
- How far does our process deviate from the platform’s default model? Configuration is healthy; heavy customization of a core product is usually a warning sign.
- What does total cost of ownership look like over five years, including licenses as headcount grows, customizations maintained through upgrades, integrations, support, and the eventual cost of leaving?
- Who controls the data and the roadmap? Look for complete data export, documented APIs, clear data residency, and contractual clarity about future pricing.
- Can we own software as a product? A custom system needs a product owner, a prioritized backlog and a maintenance budget long after launch.
The costs nobody puts on the first slide
Off-the-shelf platforms
- Per-user pricing that grows faster than the value delivered.
- Customizations that break, or must be re-tested, with every vendor upgrade.
- Integration limits: API rate caps, missing events, or premium tiers required for basic access.
- Process compromise, as teams quietly adapt their work to the tool instead of the other way around.
- Lock-in that only becomes visible when you try to leave.
Custom software
- A longer path to first value than configuring an existing product.
- Ongoing responsibility for security patches, dependency updates and infrastructure.
- Knowledge concentrated in a few people if architecture decisions are not documented.
- Scope creep when “we can build anything” replaces disciplined prioritization.
The hybrid path most enterprises take
In practice, the strongest architectures are rarely pure. A common and healthy pattern is to buy a proven system of record for commodity functions and build the differentiating layer around it: a customer-facing portal, a field operations mobile app, an analytics product, or an AI assistant that reads from the core through a well-designed integration layer.
The rule that keeps this pattern healthy is simple: keep the core close to its standard configuration, and extend at the edges through APIs. Once you start modifying the internals of a licensed platform, you inherit the downsides of both options: the vendor’s constraints and the maintenance burden of custom code.
Buy what makes you equal. Build what makes you different. Integrate everything in between.
A scoring exercise you can run in one workshop
For each capability, have business and technology leaders score five criteria from 1 to 5: strategic differentiation, process fit of the best available platform, integration complexity, localization and regulatory needs, and the organization’s capacity to own and operate software. Weight differentiation and fit most heavily.
- High differentiation and low platform fit point toward building.
- Low differentiation and high platform fit point toward buying.
- Mixed scores call for a hybrid design, or a time-boxed pilot before committing.
The real value of the exercise lies less in the numbers than in the conversation. Disagreements between departments about what is truly differentiating are exactly the disagreements that derail projects later if they are not settled early.
Plan the exit before you enter
Whichever way you decide, design the way out. For platforms, confirm that you can export all of your data in usable formats and that critical integrations do not depend on proprietary features you cannot replace. For custom software, make sure the contract assigns you ownership of the source code, infrastructure-as-code, documentation and credentials, and that handover is a defined deliverable rather than a courtesy.
How AMA GROUP approaches the decision
Our engagements begin with discovery: mapping capabilities, reviewing existing systems and integrations, and testing assumptions against real workflows. Sometimes the right recommendation is a well-configured platform with a modest amount of integration work; sometimes it is a custom enterprise system designed around how the business actually operates. The goal is the same either way: a decision the organization can still defend in five years, not just on launch day.