Buying an ERP versus building the two parts you need

Buy an ERP when the gap is standard back-office work — finance, payroll, procurement, inventory — and your process can bend to the software. Build custom when the gap is customer-facing, fast-changing, or a genuine competitive edge. The ERP vs custom build decision is rarely all-or-nothing: most companies need both, in a defined order.

Key Takeaways

• An ERP is a licence to a shared data model with a vendor roadmap; a custom build is software you own, scoped to how your business actually works.
• Buy the commodity, build the edge. Nobody wins by writing their own general ledger, and nobody wins by forcing a vendor's portal onto a process customers judge you by.
• Integration — not the licence — is where ERP projects overrun. Data migration, API work and reconciliation are the real cost drivers.
• The two paths fail differently: an ERP breaks at upgrade time, a custom build breaks when the person who wrote it leaves.
• Run a pilot on real records before you commit. A two-week data pilot tells you more than three months of demos.
• Keep the accounts, the code and the credentials in your own name, whichever path you take.

What is the difference between an ERP and a custom build?

An ERP is a licensed product with one shared database: finance, inventory, purchasing and HR all read the same customer and item records, and the vendor ships upgrades on their schedule. A custom build is an application your team owns, scoped to your process, with no vendor release cycle. One buys coverage; the other buys fit.

Why does the ERP vs custom build choice matter in production?

Because the two paths fail differently. An ERP fails at upgrade time — a version bump reshuffles a screen your warehouse staff use every morning, and you wait for the vendor. A custom build fails quietly: nobody else maintains it, and the one engineer who wrote the billing rules leaves. Blast radius matters more than the feature list.

When do you actually need an ERP, and when is a custom build the better answer?

You need an ERP when the work is commodity back-office and an auditor, a bank or a tax authority expects standard reports. You build custom when the workflow is the product — a customer portal, a booking engine, a pricing model competitors cannot copy. If the process is dull and regulated, buy. If it is visible and changing, build.

• Buy: general ledger, statutory reporting, payroll, fixed assets, standard procurement and stock valuation.
• Build: customer-facing ordering, partner portals, quoting logic, field workflows, anything your sales team demos.
• Buy then integrate: warehouse operations feeding a licensed finance module.
• Build small: a single internal tool for one team, where a licence renewal costs more attention than the tool itself.

We have written about the middle ground in custom software versus off-the-shelf packages, and the reasoning there applies directly to ERP modules.

How does an ERP implementation actually work under the hood?

Most modern ERPs expose the same three surfaces: a relational schema, an API layer, and a permissions model tied to roles. Your custom work connects at the API, or reads replicas for reporting. Everything else — screens, approvals, integrations — is configuration layered on top. That is why data quality, not screen design, decides whether the rollout holds.

Reconciliation between the two systems is where teams get caught. A nightly query like this one finds catalogue records that exist in your custom app but never made it into the ERP:

SELECT count(*) FROM erp_items i
LEFT JOIN custom_catalog c ON c.sku = i.sku
WHERE c.sku IS NULL;

If you are storing the system of record in PostgreSQL, the transaction handling in the PostgreSQL tutorial is worth reading before you write migration scripts that touch live tables.

How do you run the evaluation? A step-by-step approach

1. Write down the process as it runs today, including the spreadsheet workarounds. If you cannot describe it in one page, the problem is the process, not the software.
2. Separate the list into commodity work and differentiating work. Commodity goes to a vendor demo; differentiating goes to whoever would build it.
3. Ask each vendor for a sandbox and load your own messy data — duplicate customers, half-filled addresses, discontinued SKUs. Clean demo data hides everything.
4. Get a written build estimate for the differentiating part, including who maintains it after handover.
5. Run a two-week pilot on real records: one month of transactions through the candidate system and your reconciliation query.
6. Compare upgrade paths. Ask the vendor what happens to your customisations at the next major release, in writing.
7. Check exit cost. How do you get your data out, and in what format, if you leave in three years?
8. Decide, then freeze scope for the first release. Both paths fail when the go-live scope keeps growing.

Which integration details decide whether the rollout holds?

Three details decide it: the item master, the customer master and the tax logic. If those three do not line up between systems, every downstream report drifts. Agree on which system owns each field, build one reconciliation query per master record, and run it daily. Teams that skip this spend months arguing about whose numbers are correct.

How do you verify the system before go-live?

Run a parallel period. Keep the old process alive for one full month and compare closing balances, stock counts and invoice totals line by line. Variance should be explainable, not approximate. Then test the boring paths: a refund, a partial delivery, a credit note, a customer merge. Those edge cases are where data models break, and they show up in week two of real use, not in the demo.

What breaks after go-live, and how do you debug it?

Watch for four signals. Stock quantities that drift by small amounts point at timing — someone posting a receipt after the nightly sync. Duplicate customers mean the API retried without an idempotency key. Slow month-end reports usually mean the reporting query is hitting the transactional database instead of a replica. Failed logins cluster around role changes you made in a hurry.

• Numbers disagree: check the reconciliation query first, then the sync window.
• Sync job failing silently: alert on row counts, not just on job exit codes.
• Custom screens breaking after an upgrade: you touched internals the vendor never promised to keep stable.

What does each path cost you operationally?

Factor	Licensed ERP	Custom build
Upfront effort	Configuration, data migration, training	Discovery, development, testing
Ongoing cost driver	User count, modules, edition, support tier	Engineer time, hosting, maintenance
Who fixes bugs	The vendor, on their schedule	You, or the team that built it
Change speed	Slow for core, faster via configuration	As fast as your release process
Blast radius of an upgrade	Broad — one release touches every module	Narrow — you choose when to deploy

Licence fees, user tiers and support contracts change often, so confirm current figures on the vendor's own pricing page or ask us for a scoped quote rather than budgeting from an old number.

What are the security and data-ownership risks?

Both paths carry the same core risk: your business data living somewhere you do not control. With an ERP, that usually means a vendor's cloud tenant under their terms. With a custom build, it means your own hosting, your own backups and your own patching. Either way, insist the accounts, repositories and credentials sit in your company's name, and that you can export everything.

What mistakes do teams make most often?

• Buying an ERP to fix a process nobody has written down.
• Building a general ledger because the licence felt expensive.
• Treating integration as a two-week task at the end of the project.
• Letting one person become the only human who understands the custom system.
• Skipping the parallel run because the go-live date was already announced.

A realistic scenario

A Kathmandu distributor we spoke with had 40 staff, a licensed accounting package and a homegrown order system built by a contractor who had since moved abroad. Finance wanted a full ERP. Sales refused, because their quoting workflow took three clicks and the ERP demo took eleven.

The answer was neither extreme. Finance kept the licensed package and added an inventory module. The quoting and customer portal stayed custom, rebuilt on a stack their next developer could pick up. One reconciliation job now runs each night and compares stock between the two systems. That work is closer to what we do in custom software development and portal projects than to a full ERP replacement, and the monthly close went from nine days to four.

Which alternatives sit between the two extremes?

Plenty. You can license an ERP and write only the customer-facing layer. You can keep the accounting package and add a custom portal in front of it, which is often the cheapest real improvement. You can adopt a low-code internal tool for one department. The pattern we see work most often is a small custom layer over a licensed core, with one reconciliation job holding the two together.

If the customer-facing side is the gap, the business case for a customer portal is usually easier to defend than a full ERP replacement, and it ships in weeks rather than quarters. You can see how that looks in practice in our portal and internal systems work.

In short: buy the dull, regulated, standard work. Build the visible, changing work that customers and competitors notice. Then spend the effort you saved on the integration between them, because that is what actually keeps the numbers honest.

People also search for

• Custom software vs off-the-shelf: how to choose
• Building the business case for a customer portal
• What is actually in a software development quote
• Risks of depending on third-party platforms
• Where your customer data actually lives
• Rebuild or refactor: which one do you need
• Common questions about business systems

If you are weighing an ERP licence against a custom build, our team can help you map the process, price both paths honestly and run the data pilot before you commit. Get in touch through our contact page and we will start with a review of what you already run.