Custom ERP Development, Rolled Out One Module at a Time
ERP projects fail at a notorious rate, and they nearly always fail the same way: everything is replaced at once, on a date, and the business discovers on go-live which assumptions were wrong. We deliver one module at a time, each one earning its place before the next begins.
Discuss your projectWhy phased, and what it costs you
A single cutover concentrates all of the risk on one day. Every integration, every migration, every retrained process and every unexamined assumption is tested simultaneously, and if it goes wrong the business cannot ship, invoice or pay anyone. That is why ERP horror stories are about companies, not about software.
Phased delivery spreads that risk. One module goes live, runs in production, and is proven before the next starts. If a module is wrong, you find out while the rest of the business is unaffected. You also start getting value in month two rather than month eighteen, which changes the internal politics of the project considerably.
The honest cost is that phasing takes longer overall and needs temporary bridges between the new module and the systems it has not yet replaced. Those bridges are real work and they are thrown away afterwards. We quote them openly as the price of not betting the company on a single weekend, and in our view it is a price worth paying.
The order is chosen by what is hurting most and what has fewest dependencies. Inventory and purchasing are common starting points because the pain is acute and the boundaries are clean. Finance usually comes late, because nearly everything feeds it.
Modules
Inventory and warehouse
Stock by location, movements, counts, adjustments, and reservations. Multi-location where two channels can sell the last unit in the same second.
Purchasing
Requisitions, approval thresholds, purchase orders, receiving, and three-way matching against invoices. Where the clearest financial controls live.
Sales and order management
Orders through to fulfilment, with pricing rules, customer-specific terms, and allocation against available stock.
Production and jobs
Bills of material, work orders, routing, and consumption of components. For manufacturers this is usually the module that justifies going custom at all.
Finance
Invoicing, receivables, payables and the ledger — or an integration to the accounting system you already run, which is often the better answer.
Reporting
Margin by product and customer, stock valuation, ageing, and the operational numbers your managers currently assemble by hand.
Custom, or NetSuite or Odoo
We build custom ERP and still think most companies should look hard at a product first. Here is the comparison we would make in your position.
| NetSuite | Odoo | Custom | |
|---|---|---|---|
| Time to first module | Months | Weeks to months | Months |
| Licence cost | High, recurring | Moderate, recurring | None |
| Implementation cost | High | Moderate | The whole cost |
| Fits an unusual process | Configure, then customise | Customise freely, it is open source | Exactly |
| Breadth out of the box | Very broad | Broad | Only what you build |
| Upgrade burden | Vendor handles it | Customisations can complicate upgrades | You control the schedule |
| Compliance and audit features | Mature | Good | Built to your requirement |
| Lock-in | High | Low, open source | None |
Buy if your processes are close to standard: you will get more working software for the money. Odoo is the sensible middle ground and we would rather implement it for you than build from scratch where it fits. Build custom when your production or operational model is genuinely unusual, when licence cost at your headcount exceeds a build over five years, or when a product would force you to change a process that is your competitive advantage.
Controls, built in rather than added
The features that distinguish an ERP from a set of internal tools, and the ones auditors ask about.
- Role-based permissions per record type, enforced on every server request rather than by hiding menu items.
- An append-only audit trail recording who changed what, when, and what the previous value was. Corrections are new entries, never edits.
- Approval thresholds, so a purchase order above a value requires a named approver and the approval is part of the record.
- Separation of duties, so the person who raises a purchase order cannot also receive it and approve its invoice.
- Period locking, so a closed accounting period cannot be altered after the fact.
- Reason codes on adjustments, so a stock write-off carries an explanation attached to the transaction.
Common questions
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch