Insights · 10 min read
A practical roadmap for building a custom ERP: the modules that matter, the phases in order, the team you need, and where projects usually go wrong.
By GGP Editorial
Most companies don't set out to build an ERP. They set out to fix a mess. Finance runs on one spreadsheet, the warehouse on another, sales keeps its own customer list, and at the end of every month somebody spends a week copying numbers between them. Eventually the owner decides the mess has to stop, and the real question appears: buy a packaged system, or build one?
This guide covers the build path. It assumes you've already made the buy-versus-build call. If you haven't, read our comparison of custom ERP, SAP, and Odoo first, then come back.
ERP is a category, not a product. A ten-person services firm and a manufacturer with two warehouses both say they "need an ERP," but the systems they build share very little.
Before you write any requirements, answer three questions:
The answers set the scope. A company whose only real problem is that finance and the warehouse don't share data needs two modules and one integration, not a full platform. Most failed ERP projects start with a scope that was too wide on day one.
An ERP is a set of modules that share one database and one source of truth. These are the ones we see most often in custom builds.
| Module | What it does | When you need it |
|---|---|---|
| General ledger and accounting | Chart of accounts, journals, receivables, payables, financial statements | Almost always; usually the spine |
| Inventory management | Stock levels, warehouses, reorder points, stock movements | If you hold physical goods |
| Procurement | Purchase orders, supplier catalogs, approvals, receiving | If buying is a regular part of operations |
| Sales and CRM | Leads, quotes, orders, customer history | If a sales team or account managers are involved |
| Order management | Order capture through to fulfillment and invoicing | If orders flow across departments |
| HR and payroll | Employee records, leave, payroll, payslips | If you are replacing manual HR work |
| Production planning | Bills of materials, work orders, scheduling | Manufacturing only |
| Reporting and analytics | Dashboards, KPIs, exports | Useful everywhere, but build it last |
You don't need all of these on day one. Pick the two or three modules that carry your core workflow and leave the rest for later releases. Building the whole grid at once is how projects run out of money before anything ships.
Here's the order we follow on ERP builds. Durations are ranges for a mid-size system; your numbers depend on modules and integrations.
We turn the mess into a spec. That means walking through each department's current workflow, writing down who does what, and marking where data changes hands. The output is a list of modules, the integrations required, and a rough data model. This phase is cheap, and it's where the scope gets locked down.
Before any screen is built, we design the data model: customers, products, orders, transactions, and how they relate. Then we list every integration and find out how each one actually works, because an integration is only as good as the other side's API. This is the phase most people skip, and it's the one that comes back to cost them later.
We build one module end to end, usually the general ledger or inventory, with its screens, approvals, and reporting. The point is to get a vertical slice working against the real data model, not to demo something pretty. This first slice tells you whether the data model holds up before you build eight more modules on top of it.
Add the next modules in order of how much they depend on the core. Procurement after inventory, sales after the product catalog exists, reporting after everything else. Each slice goes live and gets used before the next one starts. This keeps feedback coming while the system is still cheap to change.
You move your real data over, then run the new system alongside the old one for a while. The parallel run catches what testing missed: people keying things in slightly differently, fields that were empty but should never be, a report everyone secretly relied on. Never switch off the old system the same week you switch on the new one.
An ERP is never finished. Processes change, new departments join, regulations shift. Plan for a support arrangement and a steady stream of small changes after go-live. A system nobody can change cheaply is a system people will work around.
For most companies the general ledger is the spine. Everything else eventually touches the accounts, so getting the chart of accounts and the transaction structure right first saves rework later. If you're a manufacturer, production planning may be the spine instead; if you're a distributor, inventory is.
A useful test: ask which department breaks first if the system doesn't work. That's the module to build first.
An ERP build needs a mix of your people and the development team's. The gaps are almost always on your side, not the code side.
| Role | What they do | Usually from |
|---|---|---|
| Product owner | Decides what "done" means, answers process questions, tests | You |
| Solution architect | Data model, integration design, module boundaries | Development team |
| Backend engineers | Build the modules and integrations | Development team |
| Frontend engineers | Build the screens and workflows | Development team |
| QA engineer | Tests flows, edge cases, and the parallel run | Development team |
| Project manager | Runs the phases, keeps the roadmap honest | Development team |
The most important person on your side is the product owner. If that role is part-time, the project stalls waiting for answers. We've seen a single missing product owner delay a build more than any technical problem.
Four things come up in almost every ERP project we touch.
Data migration. The old data is messy, duplicated, and inconsistent, and cleaning it takes longer than anyone expects. Budget for it as its own phase, not a task at the end.
Integrations. The third-party API you're connecting to will be less friendly than its documentation. Plan time to test each one against your real data, not just the sandbox.
Scope creep. "While we're in there" is how a two-module project becomes a six-module one. Every new requirement should be dated and pushed to a later release.
Big-bang rollout. Replacing every department's tools at once is how companies discover, on the same day, that three workflows they forgot about are now broken. Slice-by-slice rollout is slower but far safer.
Most companies should buy before they build. If an off-the-shelf ERP covers 80 percent of how you work, the license cost is usually cheaper than a build, and you get it this quarter. Build only when your processes are unusual enough that a packaged system would force you to change how you operate, or when you need the system to grow with you over years. The full trade-off is in our custom ERP vs SAP vs Odoo article.
The honest answer is that both are set by your modules, your integrations, and your data, not by a rate card. A focused system with two modules and limited integrations is a different project from a full platform across finance, inventory, procurement, and HR. We go into the drivers in detail in our guide to custom ERP development cost, but the summary is this: integrations and data migration usually cost more than the core modules, and they're the parts founders most often underestimate.
On time: a first release with one or two modules can go live in months; a full platform across many modules takes longer, which is exactly why phasing matters. Don't commit to a single end date for the whole platform. Commit to a date for the first slice, and let the rest follow.
A phased build with a first release of one or two modules can go live in months. The full platform across finance, inventory, procurement, and more takes longer. The number of modules and integrations, not the code, sets the timeline.
There's no single number, and a figure without a scope is a guess. The price is driven by modules, integrations, and data migration. For the full breakdown of what moves the price, see our cost guide.
No. Build the core module end to end, roll it out, then add the next slice. Big-bang rollouts are where ERP projects fail.
Yes, and you should. Most of our ERP work starts as one or two modules and grows. The key is getting the data model and the chart of accounts right at the start, because everything else hangs off them.
Data migration and integrations. They look small in a plan and turn out to be the most work. Treat them as their own phases and budget for them honestly.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build custom software, ERP and business management systems, financial systems, CRM, SaaS platforms, and AI products on a stack that includes Java, Spring Boot, Spring Cloud, MySQL, Redis, Vue, React, Node, and Go.
ERP is one of the areas we do the most work in. We've shipped a multi-module financial management system and a property rental and lease platform, among others, and we know where the effort in these builds actually goes. You can see how we approach the work on our ERP and operations solution page.
If you're planning an ERP and want a phased plan and an honest price for the first release, tell us what you're building and where you are today. We'll help you scope the modules, integrations, and migration before you commit to anything.
Tell us what you are building and where you are today. We typically reply within 24 hours.
