Build vs Buy for ERP Software: When to Build, When to Buy, and When to Do Neither

If you have ever searched for "build vs buy ERP software", you have probably seen the same advice repeated across a dozen consultancy blogs: "buy unless your requirements are truly unique." That advice is not wrong, but it is incomplete.

The build vs buy decision is not a binary toggle. There are actually four options, and the right one depends on your specific circumstances, budget, timeline, and risk tolerance. This guide lays out all four, then gives you a decision framework to choose the right path for your business.

We have built this framework from real projects with UK manufacturers and distributors. It is not theoretical. It is the same set of questions we walk through with every client before we quote a single line of work.

The Four Options, Not Two

The standard framing of "build vs buy" assumes just two paths. Here is the reality for most ERP-adjacent software decisions:

1. Buy an off-the-shelf ISV add-on — a pre-built extension from the ISV ecosystem
2. Build custom (bespoke development) — commission a software agency or internal team
3. Low-code / Power Platform — use Microsoft Power Platform or a similar low-code tool
4. Do nothing — accept the current state and work around it

Each option has a legitimate use case. Each has a cost range, a risk profile, and a set of warning signs. Let us walk through them.

Option 1: Buy an Off-the-Shelf ISV Add-On

Most major ERP platforms have a thriving ISV (Independent Software Vendor) ecosystem. Dynamics 365 Business Central has hundreds of extensions on AppSource. Sage has its marketplace. SAP has SAP Store. These add-ons range from simple reporting tools to full warehouse management systems.

When it works

An ISV add-on is the right choice when your requirement matches the add-on's core functionality with minimal customisation. If you need standard warehouse barcoding, a well-reviewed add-on will get you there faster and cheaper than any other route. The vendor maintains the code, handles updates, and provides support. You pay a predictable annual subscription.

When it does not work

ISV add-ons break down when your processes diverge from the vendor's assumptions. Every ERP vendor's product roadmap evolves. Every ISV extension must keep pace. If the ISV stops updating their add-on for the latest ERP release, you have a problem. If your business has unique workflows in pricing, order routing, or production scheduling, you will spend as much time fighting the add-on as you would building your own solution.

Pricing range

£5,000–£50,000 per year in licensing, plus implementation fees of £5,000–£30,000. Total Year 1 cost: £10,000–£80,000.

Pros

• Fastest time to value (weeks, not months)
• Predictable subscription pricing
• Vendor maintains compatibility with ERP updates
• Support and documentation included

Cons

• You inherit the vendor's product roadmap (and its delays)
• Customisation is limited to what the add-on exposes
• Vendor lock-in for the add-on itself
• If the ISV goes under or stops updating, you are stranded

Option 2: Build Custom (Bespoke Development)

Bespoke development means commissioning a software agency (or using an internal team) to build a solution from scratch, tailored precisely to your workflows.

When it makes sense

Custom development shines when your requirements are genuinely unique. If your business has a specialised pricing engine, a complex production scheduling algorithm, or industry-specific compliance logic that no off-the-shelf product addresses, building from scratch avoids compromise at every level. You own the intellectual property. You control the roadmap. There is no vendor to go out of business.

When it does not make sense

Custom development makes no sense for commodity problems. Do not build your own accounting module. Do not build your own inventory system. If a good off-the-shelf product exists and covers 80% of your needs, buying it and living with the 20% gap is almost always cheaper and lower risk than building from scratch.

The other warning sign: if you cannot articulate your requirements in writing, you are not ready for custom development. Bespoke builds require clear specifications. If your requirements change mid-project, costs spiral.

Pricing range

£50,000–£250,000+ for a full application built by a UK agency. Ongoing hosting and maintenance at £12,000–£50,000 per year. Total Year 1 cost: £62,000–£300,000+.

Pros

• Fully tailored to your exact workflows
• You own the IP and control the roadmap
• No vendor dependency or roadmap risk
• Can integrate with anything; no platform constraints

Cons

• High upfront cost
• Long timeline (3–9 months typically)
• Ongoing maintenance burden (you own the code)
• Risk of scope creep and budget overrun
• Requires clear, stable requirements upfront

Option 3: Low-Code / Power Platform

Microsoft Power Platform (Power Apps, Power Automate, Power BI) has become a popular middle ground between buying and building. It lets non-developers create applications and workflows with minimal code.

When it works

Power Platform is excellent for internal departmental tools: an approval workflow for purchase orders, a simple dashboard, a leave-request form, or a lightweight data-entry surface for a small team. It is fast to prototype and easy to iterate on. For 5–20 users solving a contained problem, it is often the fastest path to a working solution.

When it hits limits

Power Platform hits hard limits on three fronts: complexity, scale, and external users. Complex business logic (BOM explosions, multi-tier pricing engines, real-time inventory calculations across multiple warehouses) becomes unwieldy in Power Apps. Performance degrades noticeably beyond 50–100 concurrent users. And while Power Apps Portals supports external users, the capabilities are limited compared to a proper web application — complex authentication, rich data entry, custom branding, and responsive design all require significant workarounds.

The licensing cost also scales linearly with users. At 500+ users, Power Apps Premium licensing alone can exceed £100,000 per year — more than a custom-built application hosted in the cloud.

Pricing range

£5,000–£80,000 for development (internal or partner). Licensing at £15–£50 per user per month. Total Year 1 cost for 50 users: £14,000–£110,000.

Pros

• Fast prototyping and iteration
• Low technical barrier to entry
• Native integration with Microsoft 365 ecosystem
• Good for small internal tools

Cons

• Performance limits at scale
• Complex logic becomes unmanageable
• Licensing costs scale linearly and can exceed custom build
• Limited for customer-facing portals
• Vendor lock-in to Microsoft ecosystem

Option 4: Do Nothing

The option no one talks about is doing nothing. And sometimes it is the right answer.

The hidden cost of inaction

Doing nothing is not free. The hidden cost is your team's productivity. When your sales team spends three hours per day exporting data from your ERP to Excel so they can actually do their jobs, that is a cost. It does not show up in any budget line item, but it hits your P&L every month.

Research on spreadsheet workarounds in manufacturing suggests that hidden productivity losses from manual data handling run between £30,000 and £120,000 per year for a typical 50–200 person manufacturer. There is also the cost of errors — data entry mistakes, stale information, wrong decisions based on yesterday's numbers.

When this is actually the right call

Doing nothing is the right call when: your current system genuinely works for the majority of users and you are fixing a pet peeve rather than a business problem; your organisation is going through a restructuring, acquisition, or other major change that makes investment timing wrong; or the problem affects fewer than 5 users and can be solved with a simple process change or training.

If you are honest with yourself and the cost of the problem is below your threshold for action, doing nothing is a legitimate strategic decision, not a failure.

Decision Framework: 8 Questions That Guide You to the Right Option

Here is the framework we use with clients. Answer these eight questions honestly, and the right option becomes clear.

Decision Matrix: Which Option Fits Your Profile?

Cost Comparison Over 3 Years

To make an informed decision, you need to look beyond Year 1. Here is a realistic 3-year cost comparison for a medium-scope project supporting 50 users:

Notice something: doing nothing costs more than any solution over 3 years if the productivity loss exceeds the cost of the fix. This is the most common mistake in the build vs buy debate — failing to price in the cost of inaction.

Risk Comparison

Cost is only one dimension. Risk is arguably more important, because a failed project costs far more than its budget.

Flexibility Comparison

Flexibility matters because your business will change. The question is not just "what works today" but "what still works two years from now when your processes have evolved."

Hybrid Approaches: Build the Unique Parts, Buy the Commodity Parts

The most sophisticated approach is not any single option but a hybrid. Build the parts that give you competitive advantage; buy the parts that are standard industry capability.

Here is what this looks like in practice for a manufacturer:

• Buy: Your core ERP system (Business Central, Sage 200, etc.) handles accounting, standard inventory, and basic order processing. This is commodity functionality — let the ERP vendor own it.
• Build: Your customer-facing portal, your specialised quoting engine, your production scheduling interface — these are areas where your business differentiates itself. Build them to match exactly how you operate.
• Connect: Use an interface layer (like Sysgraft's approach) to bridge the two — the built application reads and writes through the ERP's API, keeping your data in one system while giving users the experience they need.

This hybrid model gives you the best of both worlds: the stability and compliance of a maintained ERP platform, plus the flexibility and user experience of a purpose-built application. And because the interface layer connects via API, your custom frontend survives an ERP replacement — only the adapter layer needs to change.

If you are considering a hybrid approach, the decision framework above still applies. Use the framework independently for each component. Buy the commodity pieces. Build the differentiated pieces. Connect them through well-defined APIs.

FAQ

Is it ever cheaper to build than to buy?

Over a 3-year horizon, almost never for standard functionality. The build cost plus ongoing maintenance nearly always exceeds ISV licensing. The exception is at very large scale (500+ users) where per-user licensing costs accumulate to more than a custom build, or when your requirements are so unique that off-the-shelf solutions require expensive customisation anyway.

What is the single biggest factor that determines which option is right?

The uniqueness of your requirements. If an off-the-shelf product covers 80%+ of your needs, buy it. If your requirements are genuinely unique and stable, build it. Most companies overestimate how unique they are — get an honest assessment before deciding.

How do I calculate the ROI of doing nothing compared to building something custom?

Calculate the hidden cost of the current workaround your team uses. The easiest way: estimate the total hours per year your team spends on manual data entry, exporting to Excel, reconciling numbers across systems, and compensating for UI friction. Multiply by blended loaded cost per hour (typically ££40–£75 for skilled staff in manufacturing and distribution, including salary + overheads). Add material error costs from order entry mistakes, pricing errors, stock discrepancies (typically 1–3% of revenue). If that total exceeds the cost of your intended solution, you have a business case. If it does not, do nothing and move on.

What happens if the ISV add-on vendor goes out of business?

This is a genuine risk. Mitigate it by choosing vendors with multiple revenue streams, observable market traction, and a clear track record of updates. Ask about their data export policy, their escrow arrangements, and whether you can get a copy of the code if they cease trading. Some large ERP vendors have partner continuity programs. Size matters here — a well-funded ISV with hundreds of customers is lower risk than a three-person shop.

Can I combine low-code and custom development in the same project?

Yes, and this is increasingly common. Use Power Automate for simple integration workflows and data movement. Use Power BI for dashboards and reporting. Use a custom-built React or Next.js application for the main transactional interface. Each tool plays to its strengths. The key is designing clear boundaries between the layers so you are not fighting platform limitations inside your core application.

When should I worry about vendor lock-in?

Vendor lock-in is most dangerous when: (a) the integration is tightly coupled (custom APIs, direct database access), (b) the vendor controls your data export, (c) you cannot replicate the functionality without rebuilding from scratch, or (d) the switching cost exceeds the cost of the solution itself. Mitigate lock-in by insisting on API-based integration, ensuring data portability, and structuring contracts with clear exit provisions. This is where the interface layer approach shines — it decouples your application from the underlying system, making future changes vastly cheaper.

---