Buy a packaged ERP when your processes fit its standard configuration. Build a custom ERP when the way you work is the reason you win, or when per-user pricing grows faster than your headcount. The deciding question is not the feature list. It is who decides when your system next changes, and who pays for it.
The question behind the comparison
All three can issue a purchase order and write to the general ledger. They differ in who sets the pace of change.
- A packaged product moves at the vendor's release pace, and your changes must fit that pace.
- A custom build moves at your pace, and you pay to keep it maintained.
Most of what follows comes from that one difference.
What each option is
| ERPNext | Odoo | Custom build | |
|---|---|---|---|
| Licence | GPL-3.0, per its repository | Community edition under LGPL version 3; Enterprise edition under the Odoo Enterprise Edition License v1.0, per Odoo's documentation | Yours; source in your repository |
| Cost model | No per-user licence fee on the open-source code; you pay for hosting, partners and work | Community has no licence fee; Enterprise needs a subscription for the correct number of users | Build cost, then run cost; no per-user fee |
| Who changes it | Frappe's releases plus your partner's work | Odoo's releases plus your partner's work | Your team or your vendor, on your schedule |
| Strong when | Standard operations with a small IT function | A standard process plus a ready-made vertical module | A process no product models |
Two details from the Odoo licence page matter in practice. The Enterprise licence says the software "can only be used" with a valid subscription for the correct number of users, and a partner agreement lifts that only for testing or development. Check which edition each module you rely on belongs to.
Both products carry Indian tax features. Before a shortlist, run your own sample invoices through each product's current tax-invoice and transport-document features. The article on GST e-invoicing and e-way bill integration lists the cases worth testing.
When a packaged ERP stops fitting
Four signals suggest the product is being stretched past its design:
- Users keep a spreadsheet beside the ERP for a core step.
- Each upgrade is delayed because a customisation must be re-tested.
- A partner is needed for every change to a report or a workflow.
- The cost per user rises each year while the work per user does not.
One signal is normal. Three together mean you are paying twice, once for the licence and once to keep the product bent.
The upgrade cliff
Configuration survives an upgrade. Customisation does not always, because every major release forces those changes to be tested, adjusted or dropped. The mechanism and the four counts that expose it are set out in custom ERP versus off-the-shelf. Used as designed, a packaged ERP stays cheap. Bent hard to fit, it costs once to bend and again at each release.
The fit-gap test
A fit-gap is a count, not a feature matrix.
- List the steps of each core process as people really perform them, including the exception paths.
- Label each step: settings cover it (configuration), code must change (customisation), or the product cannot do it (not at all).
- Count the second and third labels only, and note which processes they sit in. Show the count to the people who own those processes before anyone argues about software.
A short list means buy. A long list concentrated in the processes that earn your margin means you will be bending the product for as long as you run it.
Be strict at step one. If you score the process as the manual describes it, the result will flatter the product, because the manual describes the tidy version. Watch the people at their desks and write down what they do.
| Count after the exercise | Reading |
|---|---|
| Few gaps, all in support functions | Buy and configure |
| Several gaps, spread across processes | Buy, but fund an edge layer and budget for upgrades |
| Many gaps in the core money-making processes | Build, or build the edge and buy the rest |
Where each option wins
| Situation | Choice |
|---|---|
| Standard operations, tight budget, small IT team | ERPNext or Odoo |
| A vertical module you need already exists and is maintained | Odoo, after checking the edition |
| Open source throughout, with no paid tier | ERPNext |
| The process that differentiates you has no equivalent product | Custom |
| User count is large and rising | Custom, on per-user cost alone |
| A packaged ERP was tried before and abandoned | Custom, after you learn why it failed |
| The company is still reorganising | Packaged, until the structure settles |
A packaged core with a custom edge
You can also combine them. Let ERPNext or Odoo handle finance, stock and purchasing, where your process is ordinary. Build the distinctive layer as its own integrated system: the product configurator, the plant link or the dealer portal.
The split works when the line between ordinary and distinctive is clean. It fails when the distinctive step sits inside a core process, since you are then back to reshaping the product.
Reading a partner's fit-gap
A partner usually runs the fit-gap for you, so check how they ran it. Ask to see the process steps they listed and who supplied them. Ask which steps were observed at the work site and which were taken from a requirements document. Ask for the gap count by process, not as one total. A total of forty gaps in support functions is a different project from forty gaps in the production flow. Keep the sheet. It is the baseline for every later conversation about scope and price.
Questions to put to a partner or vendor
Whichever route you take, ask for written answers to these before signing:
- Which of our listed steps are configuration, which are customisation, and which are not possible?
- What happens to each customisation at the next major release, and who pays?
- Which modules we need sit in the paid edition, and what do they cost per user?
- How do we export all our data in a usable form if we leave?
- Who holds the source for anything built for us?
Vague answers to the second and fourth are the usual warning.
Costs to compare over 3 years
Put the same 6 lines in front of each option, and total them for 3 years. Odoo's licence page covers version 19, so confirm which version a quote assumes:
- Licence or subscription, per user per year.
- Implementation, including data migration.
- Customisation or edge development.
- Upgrades, each priced as a project.
- Hosting and support.
- Internal time for administration and training.
Quotes that leave out lines 4 and 6 look cheaper than they are, so ask for both in writing. For the build option, the cost drivers of a custom ERP go through these lines in detail.
Is the oddity an edge or a leftover
Before you build around an unusual step in your process, ask whether it gives you an edge or is a leftover. Build or buy for AI applies the same test, and it works for ERP as well. If customers choose you because of the step, build it. If it is only history, tidy the process first and buy the product.
Questions teams ask
Can ERPNext or Odoo carry a mid-sized Indian company?
Often yes, when operations are standard. Run the fit-gap before deciding, and test GST documents on your own data.
Can we start packaged and move to custom later?
Yes, if your data stays clean and exportable and you avoid deep customisation. Running a packaged system also reveals your real requirements, which costs less than learning them during a build.
Where does the wider build-or-buy decision sit?
See custom ERP versus off-the-shelf. If Tally is where you start, read when Tally stops being enough.
Where Brihat fits
Brihat Infotech builds custom ERP systems and can build around an existing packaged ERP. Start a conversation.