Custom ERP Development

Signs that spreadsheets have run their course

Most businesses do not set out to buy an ERP. They arrive there after years of spreadsheets, a separate accounting package, WhatsApp groups and one or two people who hold everything in their heads. The usual symptoms are easy to recognise.

• Sales promises a delivery date without knowing what is actually in stock.
• Two departments report different numbers for the same thing.
• Month-end closing depends on manually reconciling several files.
• Nobody can say what a particular job or order really cost until long after it shipped.
• The business slows down badly when one key employee goes on leave.

Build or buy: an honest comparison

Buying should be your default starting point to evaluate. Packaged ERP products, including open-source options such as Odoo and ERPNext, have standard accounting and inventory logic that has been tested by many users. If your processes are fairly conventional and you are willing to adapt to the software, they can be quicker to deploy.

The problems begin when the business is unusual in ways that matter. Heavy customisation of a packaged product can make upgrades painful, and per-user licence costs grow as you add people, including those who only need one screen.

A custom build makes sense when your workflow is part of how you compete, such as job-work tracking, unusual costing, batch traceability or an approval chain that no product models well. You own the system and pay for what you use. The price is a larger upfront effort, more decisions on your side, and full responsibility for long-term maintenance.

There is also a middle path: keep your existing accounting software for statutory books and build custom modules for operations, connected through an integration. For many mid-sized companies this delivers most of the value at a lower risk. It also avoids rewriting tax and compliance logic that a mature accounting package already handles.

Modules we can build

An ERP is a set of connected modules, and very few companies need all of them at the start. Which ones matter depends on whether you manufacture, trade, distribute or provide services.

• Purchase: indents, supplier quotations, purchase orders, goods receipt and vendor bills.
• Inventory: multiple warehouses, batch or serial tracking, stock transfers, reorder levels and physical stock counts.
• Production: bills of materials, work orders, routing, material issue, scrap and job-work with outside vendors.
• Sales: quotations, orders, dispatch, invoices, returns and customer outstanding.
• Accounts: receivables, payables, GST-ready invoicing and export to your accounting system.
• Quality: inspection records, rejection reasons and traceability back to a batch.
• HR and payroll links: attendance, leave and the data your payroll process needs.
• Management dashboards: live views for owners, with drill-down into the underlying transactions.

Why ERP projects go wrong, and how we try to avoid it

The technology is seldom what sinks an ERP project. The trouble usually comes from unclear processes, poor data and staff who keep their old spreadsheets running alongside the new system.

Before anything is built, we map how work really moves through the business, including the exceptions, such as a part-shipped order, a rejected batch or a rate agreed over the phone. Those exceptions are where generic designs break down. A named person from your side who can make decisions is also essential, because an ERP forces choices that only the business can make.

Data migration deserves its own line in the plan. Item masters with five spellings of the same product, unverified opening stock and old customer records all need cleaning before they go in. This work needs your people, and it should start well before go-live.

Rolling out in phases

We follow our usual path of discover, design, develop, launch and support, with milestone-based quotes and weekly demos. For an ERP, the important decision is order. Switching every department on a single day concentrates the risk, so we generally recommend starting with the module that addresses your sharpest pain, often inventory or sales orders, and making sure it is in daily use before adding the next one.

Before each module goes live, a short parallel run lets your team compare results with the old method. User training happens on real scenarios from their own work. The weekly demos are also the right time to involve the supervisors and clerks who will use the system, because they spot impractical screens long before management does.

Technical decisions worth asking about

An ERP lives for many years and holds sensitive business data, so a few technical questions are worth raising with any vendor.

• Roles and permissions at a fine level, including who can see costs and margins.
• An audit trail recording who changed what and when, especially for stock and invoices.
• Automated, tested backups, and a clear recovery procedure.
• Hosting on a VPS or AWS, with access from the factory floor and branches on ordinary connections.
• Documented APIs for connecting barcode scanners, weighbridges, accounting software or a CRM.
• Mobile screens or an app for stores staff, supervisors and field teams.
• Written documentation and source code access, so you are not tied to one vendor forever.

What affects the cost of a custom ERP

Estimating an ERP before discovery is mostly guesswork, which is why we scope first and then quote by milestone. The main cost drivers are listed here.

• The number of modules, and how deeply each models your exceptions.
• Number of plants, warehouses, branches or companies in the system.
• The state of your existing data, and the volume to migrate.
• Integrations with accounting software, machines, scanners or e-commerce channels.
• Complexity of costing, approval chains and reports.
• Training needs, and the level of support required after go-live.