Custom software or an off-the-shelf ERP?
The honest version: most businesses should buy, and the ones that should build usually know why.
Buy the package for anything that is not genuinely distinctive about your business, and build only where the process is the thing you compete on. Most businesses need one custom system, not a custom everything.
This question is usually asked of people with an interest in the answer. A software development firm will find reasons to build; an ERP reseller will find reasons to buy. We do both, which does not make us neutral, but it does mean the honest answer is available to us.
The honest answer is that packaged software wins more often than the industry likes to say. Someone has already solved accounting, payroll, and standard inventory, for thousands of businesses, and has spent more on that problem than you ever will. Rebuilding it because your process is 'a bit different' is the most reliable way to spend a lot of money on a worse version of something you could have bought.
Where each one genuinely wins
Buy the package when
- The process is standard — accounting, payroll, statutory filing
- Regulation changes and someone else should track it
- Your team is small and cannot maintain software
- You need it working in weeks, not months
- Being similar to your peers is fine, or an advantage
- You want to hire people who already know the system
Build when
- The process is how you compete, not just how you operate
- No package fits without changing how you actually work
- You would be paying for a great deal you will never use
- Integration between existing systems is the real problem
- Your workflow is the product your customers experience
- You have, or will have, someone to own it
The costs each side quietly omits
Both options are routinely presented with the uncomfortable half left out.
Packages: customisation
The licence is quoted; the configuration and customisation to fit your process often costs more than the licence, and heavy customisation is what makes upgrades painful later.
Packages: the workaround tax
Where the package does not fit, people build spreadsheets around it. That cost never appears in any quote and is frequently the largest number on the page.
Custom: the second year
Build cost is quoted; the ongoing cost of owning software — fixes, changes, dependency updates, someone who understands it — is real and permanent.
Custom: key-person risk
If one developer or one firm is the only party who understands your system, you have swapped a licensing dependency for a sharper one.
Five questions that settle it
Answer these honestly and the decision usually makes itself without a proposal.
- Would a customer notice if this process worked like everyone else's? If not, buy.
- Has any package been rejected for a real reason, or only because change is uncomfortable?
- Who owns this in three years, and are they in the room now?
- What is the cost of the workarounds you are running today? Put a number on it.
- If this must work in eight weeks, is building even an option?
The answer that is usually right
In practice the useful answer is rarely one or the other. It is: buy the package for the commodity work, build the one thing that is genuinely yours, and integrate them properly.
For a distributor that might be Tally or SAP Business One for the books, with a custom order and dispatch system that reflects how they actually sell, connected so nothing is entered twice. For a manufacturer it might be a standard ERP plus a bespoke quality and traceability layer, because that is what customers audit.
The mistake is at both extremes: building everything, which is slow and expensive; or forcing a package to do the one thing it cannot, which is how businesses end up with an ERP and forty spreadsheets.
Build where you are different. Buy where you are not. Almost every expensive software decision is a failure to be honest about which is which.
Custom vs ERP — questions we get asked
We were told a package can be customised to do anything.
Technically often true, commercially usually a trap. Heavy customisation costs more than it appears, and it is what makes upgrades expensive and support arguments circular. If a package needs substantial customisation to fit, that is evidence it is the wrong package — not that it should be bent.
Is custom software always more expensive?
Not always. For a narrow, well-understood process, custom is often cheaper than per-seat licensing over a few years. It is more expensive when the scope is broad, because you are then paying to rebuild things a package already includes.
What if we build and the developer disappears?
That is a real risk and it is managed contractually and technically: you own the code and the repository, the stack is mainstream rather than exotic, documentation and handover are part of scope, and deployment is reproducible. Ask for all four before signing anything.
The work this leads to
Moving from Tally to a real ERP
Most businesses do not need to leave Tally. They need to stop using it for the things it was never built for, and move those onto something else first.
Read itMigrationReplacing a spreadsheet that has become a system
When a workbook has become the system of record for a real process, the failure modes stop being inconvenient and start being expensive. Turning it into an application is usually a short project.
Read itOther guides
Tally, SAP Business One, or Odoo?
These three come up together constantly, despite solving different problems. What actually separates them is how much process you have, and who will maintain it.
Cost guideWhat ERP implementation actually costs in India
Most firms answer this with 'it depends, contact us'. It does depend — on a small number of things you can assess yourself before anyone quotes you.
Still weighing it up?
Most of these questions are quicker to settle in a conversation than in an article — particularly the ones where the answer depends on your numbers.