Insights · 5 min read
Most companies do not need to build an ERP from nothing. How to decide between a packaged system, a custom build, and adapting open source, with real costs.
By GGP Editorial
Every growing company hits the same wall. Spreadsheets and three different tools worked until they did not, and now someone is typing the same invoice twice. That is the moment people start searching for an ERP. Most of them skip the real question: should you build one at all?
There are three ways to get an ERP, and they are not equally good for every company.
Buying a packaged system like SAP or Odoo is fastest if your processes are standard. The catch is that your business rarely is. You end up paying for modules you do not use and bending your workflow to fit the software, or paying consultants to bend the software to fit you. Licence fees also repeat every year, which adds up faster than most buyers expect.
Adapting open source means taking something like Odoo or ERPNext and modifying it. Cheaper than a full build, but you are still paying developers to understand a codebase they did not write, and every upgrade risks breaking your customisations.
Building custom means the system follows your actual workflow. It costs more up front and takes longer. For a company with unusual processes, strict compliance needs, or a desire to own the system outright, it is often the only option that actually works.
| Option | Up-front cost | Time to value | Best when |
|---|---|---|---|
| Packaged | Low to mid | Fast | Standard processes, small team |
| Open source, adapted | Mid | Medium | Budget matters, some customisation |
| Custom build | High | Slower | Unusual workflow, compliance, ownership |
An ERP is a set of modules sharing one database. Most companies start with finance and inventory, then add the rest. Here is the typical shape:
| Module | What it does |
|---|---|
| Finance | General ledger, payables, receivables, reporting |
| Inventory | Stock levels, transfers, valuation |
| Procurement | Purchase orders, supplier management |
| Sales and CRM | Quotes, orders, customer history |
| HR | Payroll, leave, employee records |
The value is in the shared data. An order placed in sales should update inventory and finance without anyone re-keying it. If your modules do not talk to each other, you have built an expensive set of spreadsheets.
Custom ERP development earns its price in three situations. First, when you have a process that is genuinely unusual and a packaged system would force you to change how you work. Second, when you face compliance or audit requirements that off-the-shelf systems handle poorly. Third, when you plan to own and extend the system for years and do not want to be locked into licence fees and consultant rates.
The work is not exotic. It is careful database design, a clean API layer, and screens your staff will actually use. Most ERP projects fail not on the technology but on requirements. If nobody can agree what a finished order looks like, no amount of code will fix it.
Most ERP failures are not technical. They happen when the team refuses to change how it works, or when management buys a system and expects the software to fix a broken process. Software records your process; it does not invent a better one. If the current process is a mess, automating it just produces a faster mess.
Data migration is the other quiet killer. Your history lives in spreadsheets and an old system, often dirty and duplicated. Budget real time for cleaning it, because an ERP full of bad data is worse than no ERP at all. People will stop trusting it within a month.
A sensible build happens in stages. The first month is spent mapping your actual processes, not your ideal ones, because the ideal ones live in a manager's head and not on the shop floor. Then comes the data model and the core finance and inventory screens, which get shown to real users early and often. Integrations with your bank, payment gateway, or e-commerce platform come next. Only after the core is running do you add the fancier reporting.
Expect six to twelve months for a meaningful system, and resist the urge to build every module on day one. The companies that succeed start narrow and expand once people are actually using the thing.
Plan the rollout in phases. Run the new system in parallel with the old one for a while, at least for finance, until the numbers match. Train one department at a time and give people a named person to call when they get stuck. The software matters less than whether your team actually adopts it.
We have built ERP and finance systems for trading, property, and retail clients across several markets, so the module list above is not theory to us. If you are weighing build against buy, tell us your workflow and we will give you an honest read on which path costs less over five years.
Tell us what you are building and where you are today. We typically reply within 24 hours.
