Custom ERP or off-the-shelf: how to decide before you pay for either

If your business runs on the same processes as everyone else in your sector, a packaged system is usually the cheaper answer. If two or three workflows decide whether you make money, and no package models them without a workaround, custom software can pay for itself. Most real decisions sit between those two cases — which is why the questions below matter more than the label on the box.

What a packaged ERP is actually good at

A packaged system is a set of decisions someone else already made: what a customer is, what an invoice contains, how stock moves, who may approve what. That is its value. You are buying years of other people's mistakes and their fixes, plus an implementation partner who has done it before.

It is a good fit when:

• your accounting and stock flows are conventional for your sector;
• you can change your process to match the software without losing money;
• you need to be running in weeks, not quarters;
• several people must be trained, and a known interface helps;
• the vendor's roadmap is close enough to your needs that waiting is acceptable.

None of that is an insult to packaged software. A business that sells a standard product through a standard channel should not pay to reinvent a standard inventory model.

What makes custom worth the cost

Custom software is justified by a specific kind of difficulty: a workflow that carries real money and does not match the standard shape.

Watch for these signals:

• The workaround is the business. If your team's real process lives in a spreadsheet beside the ERP, the ERP is not running your business — the spreadsheet is. That spreadsheet is an undocumented custom system already, with none of the safeguards.
• A rule that no package expresses. Tiered credit by customer history, pricing that depends on route and season, stock reserved per contract. Configured rules cover common shapes; they stop where your competitive advantage starts.
• The cost is per seat, per module, per year. Sometimes the licence is cheap and the constraint is not. A per-user price can decide who gets access to information, which is a business decision made by a price list.
• The integration is the product. If two packaged systems must exchange data and neither vendor will own the seam, you are paying for integration either way. The only question is who writes it.
• Offline or unusual conditions. A counter that loses connectivity, a warehouse with no reliable network, a van that works from a phone. Packaged web systems usually assume a connection.

The five questions that decide it

Answer these before comparing prices. They are cheaper than a request for proposal and much cheaper than a failed implementation.

1. Which three workflows decide whether you make money? Not departments — workflows. If the answer is "sales, stock and cash", a package probably covers them. If the answer names something specific to you, write down how it works today, including the exceptions.

2. How many exceptions per week? A rule with two exceptions a year is a note in a procedure. A rule with twenty exceptions a week is a requirement, and software that cannot express it will be bypassed.

3. Who is accountable for each record? One customer, one owner. One order, one status. If two systems both claim to be the truth about the same record, no software choice fixes that — but a custom system can at least enforce the rule.

4. What is the cost of the current workaround, per month? Hours spent retyping, reconciling, and reconstructing the month, multiplied by a real hourly cost. Not a feeling — an estimate you can defend. Compare that to the build, the licence, and the maintenance, over three years.

5. What happens at the next branch, product line or hire? A custom system that took six months to build must be extendable by someone other than its author. A package that took two weeks to configure must not charge you a project for each new location. Both are real risks; choose the one you can live with.

Where custom goes wrong

Custom software fails for reasons that have nothing to do with code quality:

• It replaces an argument with a screen. If the team has not agreed on what "confirmed order" means, software will not settle it. It will expose it, in front of a customer.
• It is built all at once. A two-year build produces a system nobody has used. The first module should be in daily use before the second is designed.
• Nobody owns it after handover. Custom means someone must be able to read the code and change the rules. If that person is only the original vendor, you have bought a dependency, not an asset.
• The data migration is an afterthought. Products, customers and opening balances are the part that decides whether the go-live is a Tuesday or a crisis. Import, clean, and reconcile against a printed control total before anyone switches over.

A cheap way to test the decision

Take the workflow you consider most unusual. Write it as a page of rules: what triggers it, what it produces, who approves it, what happens when it goes wrong. Then show that page to two vendors of packaged systems and ask them to model it in a demo — not to describe it, to show it.

If both can show it working, buy the package. If both need a workaround, you have measured the gap. That page is also the first document any custom build needs, so the work is not wasted either way.

What this means in practice

The honest answer is usually a mix: a packaged system for accounting and payroll, custom software for the two workflows that are actually yours, and a written integration between them. That is more work to specify than a single purchase, and it is often the only shape that matches how the business runs.

We build the custom side — the modules that decide whether the month closes on time — and integrate with what you already own.