Build vs buy ERP: a decision guide for 2026

For most companies the right answer is neither pure build nor pure buy. It’s an open ERP like ERPNext or Odoo for the parts every business shares (accounting, stock, purchasing, payroll), plus custom modules for the two or three processes that make you different. Build a fully custom ERP only when your core operation doesn’t resemble any standard model and you have someone who will own the software for years. Buy plain off-the-shelf when your processes are genuinely ordinary and you’re willing to change them to fit.

That’s the short version. The rest of this guide is how to work out which camp you’re actually in, because almost every company believes it’s special, and only some of them are right.

The three options that are really on the table

People frame this as a binary. In practice there are three paths, and the middle one is where most sensible projects end up.

1. Off-the-shelf, configured

You pick a product and use it as shipped. You set up the chart of accounts, naming series, workflows, print formats and roles, and you change your processes where the software disagrees with you. No code is written.

This is cheaper and faster than people expect, and it hurts more than people expect. The pain isn’t money. It’s the warehouse lead who has done cycle counts one way for eight years being told the system does it differently.

2. Off-the-shelf plus custom modules

You take a platform with a real extension model and add your own code on top. On ERPNext that means a Frappe app with its own DocTypes, hooks.py and fixtures, installed next to erpnext and never editing it. On Odoo it means your own addons using _inherit to extend standard models and views, with their own ir.model.access.csv and a manifest.

You get a maintained general ledger, tax handling and inventory valuation for free, and you only write code where your business actually differs. The catch is that you now own that code, including through every upgrade.

3. Fully custom

You design the data model from scratch and build every screen, report and posting rule. Sometimes on a framework (Frappe itself works well as a base without ERPNext), sometimes on a general web stack.

You get exactly what you asked for. You also get exactly what you remembered to ask for, which is the problem.

Decision criteria that actually separate the options

Skip feature checklists. Every serious ERP ticks the boxes. These are the questions that change the answer.

How much of your operation is standard?

Write down your ten most important processes. For each one, ask whether a competitor in a different city would do it roughly the same way. Order to cash, procure to pay, payroll, month-end close: nearly always yes. Those should run on standard software.

If seven or more of the ten are standard, you’re buying, possibly with modules. If most of them are unusual (a rental business priced by machine-hour with damage deposits, a lab that bills per test with regulatory chain-of-custody), a platform will fight you on the core and a custom build starts to make sense.

Where does your margin come from?

The process that earns you money is the one worth writing code for. A distributor who wins on delivery speed should care deeply about pick lists and dispatch, and not at all about how the balance sheet is laid out. Spend custom effort there and accept defaults everywhere else.

Who owns it in three years?

This question kills more custom ERP plans than any other, and it should. Software without an owner rots. Someone has to handle the tax rule change, the bank that alters its file format, the new branch in another state. If your answer is “the agency that built it”, check how long that agency has kept its developers.

A platform spreads that ownership across a vendor and a community. A custom system puts all of it on you.

Compliance and localisation

E-invoicing mandates, GST or VAT return formats, statutory payroll: these change often and are dull to maintain. ERPNext and Odoo both have country-specific localisation work, some official and some community-driven, with uneven quality by country. Check yours before deciding. Rebuilding a country’s tax logic yourself is rarely a good use of money.

Time to first invoice

A configured platform can be raising real invoices within weeks. A fully custom ERP can’t, because the ledger, tax and document numbering all have to exist first. If cash flow depends on going live before a particular date, that alone may settle it.

Total cost of ownership, without made-up numbers

We won’t give you a percentage breakdown, because honest ones vary too much by company. What we can give you is the list of line items people forget. Put a figure next to each for every option you’re considering, over five years, not one.

Cost line	Off-the-shelf	Platform + modules	Fully custom
Licences or subscription	Per user, grows with headcount	Same, or none on self-hosted open source	None
Implementation and data migration	Yes	Yes	Yes, and larger
Custom development	None	Per module	Everything
Hosting and backups	Often bundled	Yours or managed	Yours
Upgrades	Vendor does it	You retest your modules	You are the vendor
Internal owner’s time	Some	More	Most
Training and documentation	Vendor docs exist	Mostly exist	You write all of it
Cost to leave	Data export	Data export, code is yours	Code is yours, knowledge may not be

Two lines deserve more attention than they get. Upgrades are where platform-plus-modules projects quietly lose money, usually because someone edited core files instead of extending them. And the internal owner’s time is a real salary even if their job title doesn’t say “ERP”.

For a closer look at pricing custom work on one platform, see our breakdown of what ERPNext customization really costs.

Our opinion: don’t build your own general ledger

We build custom ERPs, so take this seriously: most companies that ask us for one shouldn’t have one.

Double-entry accounting, stock valuation, multi-currency revaluation, fiscal year closing, tax reports. None of this is where you’ll beat your competitors, and all of it is full of edge cases that mature platforms found years ago. We’ve seen custom systems that handled the operational side beautifully and then needed a separate accounting package bolted on because the ledger never balanced cleanly.

If you do go custom, consider building the operational core yourself and posting summarised entries into a standard accounting system. That keeps your auditor happy and your developers focused on the part that’s unique.

The opposite mistake is just as common. Teams bend a standard ERP into shapes it was never meant for, with hundreds of Server Scripts and Studio fields, because “we already paid for it”. When customisations start rewriting how a core document behaves rather than adding to it, you’re building a custom ERP anyway, just on a foundation that fights you. Our Odoo vs custom ERP comparison goes through where that line tends to fall.

Red flags on each path

When buying

• The demo only ever shows the vendor’s sample company, never your data or your awkward process.
• The vendor or partner can’t tell you how customisations survive a major version upgrade.
• The partner quotes the implementation but won’t put the annual upgrade effort in writing.
• Per-user pricing looks fine for today’s headcount and next year’s hasn’t been modelled.

When adding custom modules

• The developer’s plan involves changing files inside erpnext or a standard Odoo addon.
• Business rules are enforced only in client-side scripts, where an API call can skip them.
• There’s no staging copy of the live database to test against.
• Nothing is in version control. If the customisation only exists in one production database, it isn’t really owned by anyone.

When building from scratch

• The spec describes screens, not the posting rules behind them.
• There’s no plan for audit trails, document cancellation or period locking.
• “We’ll add reporting later.”
• The budget has no line for year two.

How the hybrid path usually plays out

The pattern we’d recommend, and the one that tends to hold up, goes like this. Pick the platform whose standard modules cover your finance and stock without changes; our ERPNext vs Odoo comparison helps with that choice. Go live on standard processes first, even if a few are clunky. Live with it for a couple of months so you learn which gaps are real and which were habit. Then build modules for the gaps that remain, as proper apps or addons in a Git repository.

Doing it in that order stops you paying to customise things that turn out to be fine once people get used to them. It also means the custom code is written against a live system with real data, which catches problems a specification never will.

If the gaps are big enough that you’re rewriting the core, that’s the point to have the fully custom conversation, with evidence rather than guesses.

Where erpfly fits

erpfly generates the custom part: Frappe apps for ERPNext, Odoo addons, or a custom ERP built from scratch when that really is the right call. The code lands in your repository and you own it. We’ll also tell you when a request is better handled by configuration, because a module you don’t need is still a module you have to upgrade.