How to Build a Custom ERP System

The worked example behind this guide is the Bilawal Electronics ERP, a Laravel system Sigi Technologies built for a Pakistani consumer electronics retailer that sells phones, laptops and appliances on monthly installment plans. Most ERP guides stop at a list of modules. The part that is hard to find anywhere, and the part this guide leads with, is what happens to the data model when the customer pays over twelve months instead of at the counter. Commercial scope for work of this shape sits on Sigi’s custom software development service.

What is a custom ERP system?

An ERP system is a single application whose modules write to one shared database, so a sale draws down stock, opens a receivable and posts to the ledger in the same transaction. A custom ERP is that system built around one company’s process rather than configured from a vendor template. The test is not how many modules it has. The test is whether a transaction is entered once and read everywhere else.

• An ERP is defined by the shared record, not the module count: if stock, receivables and the ledger disagree, the company has separate tools with one login.
• Software choice is not the main risk. A 2022 systematic mapping of 72 peer-reviewed ERP failure studies ranked project management problems as the most important failure factor and ERP software misfit only sixth.
• Heavy customization of a packaged ERP is itself a recorded failure factor, which is why SAP now asks customers to keep the core unmodified and put extensions behind released interfaces.
• Selling on installments changes the schema: the system has to hold the cash selling price separately from the installment total, because revenue is recognized at the cash selling price and the difference is financing.
• Odoo gates Odoo Studio, on-premise deployment and external application programming interface (API) access behind its top Custom plan, while ERPNext is AGPL-3.0 licensed and free to self-host, so build versus buy is a licensing question before it is an engineering one.
• Build the module the business is losing money on first. On Bilawal Electronics that order was stock and sales, then installments and collections, then finance and dashboards.

Which ERP modules do you need, and which one comes first?

An ERP module is a functional area with its own screens and rules that reads and writes the same records as every other area. A mid-market build usually needs six: sales and orders, purchasing and suppliers, inventory, customers, finance and reporting. Manufacturing, human resources and payroll are added only when the company runs those processes at a scale that hurts.

• Sales and orders: quotes, invoices, returns, and the rule that a confirmed sale moves stock.
• Purchasing and suppliers: purchase orders, goods received, landed cost, supplier balances.
• Inventory: quantity by location, movements in and out, adjustments, stock counts.
• Customers: one record per customer with balance, history and credit terms.
• Finance: general ledger, receivables, payables, and postings generated by the operational modules rather than typed again.
• Reporting: the two or three numbers the owner checks daily, available without an export.

Sequence beats coverage. On Bilawal Electronics, the build started from the client’s existing spreadsheets and hand-kept books, and modules shipped in the order the business depended on them: stock and sales first, then installments and collections, then finance and dashboards. Every stock movement, sale and collection carries a branch, so head office sees consolidated inventory and receivables while each location manages its own counts and dues. That sequencing question is the same one Sigi works through in product discovery before any schema is written.

How do you model a sale the customer pays for over twelve months?

An installment sale is a sale where the goods transfer now and the money arrives on a schedule, usually monthly, usually at a price above the cash price. This is where generic ERP advice runs out. A packaged system models credit as an invoice with payment terms: one due date, one balance, paid or unpaid. An installment retailer is running a small lending book, and the schedule is the product.

The accounting sets the schema. Under IFRS 15, revenue is recognized when the performance obligation is satisfied. For a phone that is the day it leaves the shop, not the day the last payment lands. A staff paper for the joint IASB and FASB revenue transition group sets out the objective when a contract carries a significant financing component. Revenue is recognized at the cash selling price, the price the customer would have paid if they had paid cash when the goods transferred. The same paper uses the retail case directly: a phone at 600 dollars upfront, or 25 dollars a month for 24 months. So the gap between the installment total and the cash price is not revenue from selling a phone. It is financing, and the database has to tell the two apart.

What the installment ledger has to store

• The cash selling price and the installment total as two fields, with the markup between them derived rather than typed.
• A schedule row per due date, each with its own amount, due date, running balance and state, because a customer can be current on one plan and overdue on another.
• Payment allocation rules: a partial payment has to land against specific schedule rows, and an early settlement has to close the remaining rows without inventing a refund.
• An overdue state that is computed from dates rather than set by a person, so the receivables report and the collector’s list are the same query.
• Plan history on the customer record, so a repeat buyer is assessed on how they paid last time rather than on memory.
• A branch on every row, if the business trades from more than one location, because collections and stock are both local before they are consolidated.

One more requirement comes with credit rather than with software. Across thousands of open accounts and multi-month relationships, a signature on a form is weak identity. The ERP integrates DigitalPersona fingerprint readers through its REST API layer so a customer is verified against their record at the counter. Financing a sale means the customer record has to be trustworthy, not just present.

Should you build a custom ERP or buy Odoo, ERPNext, NetSuite or SAP?

Buy when your processes are ordinary. A distributor that quotes, ships, invoices and reconciles like every other distributor should configure a package and spend the saved budget on data quality and training. Custom ERP development earns its cost only when the way the company trades is the thing competitors cannot copy, or when the misfit sits in the core object model rather than in a screen layout.

• Odoo publishes its pricing openly. The plan list runs One App Free, Standard and Custom, priced per user per month, and Odoo Studio, on-premise or Odoo.sh deployment, multi-company and external API access sit on the Custom plan, checked on 11 September 2026. The tier you need to customize is the tier that costs most per seat.
• ERPNext is AGPL-3.0 licensed and free to self-host, with managed hosting on Frappe Cloud starting at 5 dollars a month for a single site. There is no per-user license, so the real cost is the implementation and the people who keep it running.
• Oracle NetSuite ships two major releases each year and upgrades customers in phases, and its Release Preview account exists so customers can test their own workflows and customizations before each upgrade. Buying a package does not remove regression testing, it reschedules it.
• SAP now teaches the opposite of deep customization. Its clean core guidance defines the approach as one where extensions are kept strictly separate from the SAP application, with a policy of zero modifications and only released interfaces, so that upgrades become non-events.

Hosting is a smaller decision than it looks. A custom ERP is a web application, so the same codebase runs on a managed cloud instance or on a server in the building, and the choice usually comes down to connectivity and data residency rather than architecture. With a package it can be a licensing decision instead, which is why on-premise deployment sits on Odoo’s top plan.

Read those four together and the build-versus-buy question changes shape. Every vendor is telling you the same thing: the more of your process you push into a package, the more you pay in license tier, upgrade testing or architectural discipline. The research agrees that this is a real risk, not a sales argument. In the 2022 systematic mapping of ERP failure literature, highly customized ERP appears as a failure factor in its own right, associated with inadequate system reliability and a low degree of integration and flexibility. Custom is the honest answer when the process you cannot compromise on is central, as installment finance was for Bilawal Electronics, because a packaged system models credit sales as invoices with payment terms rather than as multi-month plans with per-customer schedules, markups, overdue handling and branch-level collection.

Where does a warehouse or accounting system stop and an ERP start?

A warehouse management system tracks stock to a physical rack and bin. It drives put-away, pick and pack work on the floor, which is one module deep and several layers more detailed than an ERP inventory table. The multi-tenant platform 3DLogistiX shows the boundary: it integrates outward to Xero, MYOB, QuickBooks and NetSuite for accounting rather than keeping a ledger of its own. Accounting works the same way in reverse on the Busy Bean Coffee platform, where the QuickBooks integration pushes each customer invoice, Stripe fee and partner payout to the correct ledger accounts. That removes month-end re-entry without making the platform an accounting product. Decide early which system is the book of record for stock and which is the book of record for money, then let the other one integrate.

Why do ERP implementations fail?

Because ERP implementation is a management project wearing an engineering costume. Coşkun and colleagues, publishing in Data and Knowledge Engineering in 2022, screened 353 articles down to a final pool of 72. Their mapping found that project management problems were the most important failure factor, followed by lack of top management support, poor project team, poor organizational culture and lack of training. Software misfit came sixth. A 2023 systematic review in the Journal of Business and Technology covered 55 studies published between 2000 and 2022. It reached a similar list: lack of top management support, inadequate education and training, mismatch between the system and business strategies, weak project management and users unwilling to use the system.

The widely repeated claim that 70% of ERP projects fail is worth treating carefully. That 2023 review reports published failure estimates ranging from 67% to 90%, but those come from earlier studies with different definitions of failure rather than from one measurement. For current field data, Panorama Consulting’s 2026 ERP Report states that more than a quarter of organizations exceeded their project budgets, with additional technology needs cited as the leading cause. What survives every source is the pattern: the money is lost late, when the misfit between the software and the process is finally admitted.

• Name an owner inside the business who can decide, not a steering committee that can only escalate.
• Map the current process from the artifacts people actually use, the sheets and books, before designing screens.
• Migrate a real slice of live data in the first month, because data quality is discovered, never assumed.
• Train against the new process, not the new buttons, since resistance to change and lack of training rank above technology in both reviews.
• Run the old and new systems in parallel for one full accounting cycle before switching off the spreadsheets.

How much does a custom ERP cost and how long does it take?

There is no catalogue price. Any figure attached to a named client on a vendor website should be read with suspicion. The bands below are typical-scope planning estimates in United States dollars, consistent with those Sigi publishes in its guide to how much it costs to build an app. A focused first release with one or two modules and a single location sits in the 40k to 80k band. A production ERP with sales, stock, purchasing, finance and a light admin surface sits in the 80k to 180k band. A multi-branch system with hardware, external integrations and reporting sits in the 150k to 350k and above band. These are order-of-magnitude figures for planning, not quotes, and none is attached to a Sigi client.

On timeline, the 2023 systematic review cites an average ERP implementation period of between six months and two years. A useful planning shape for a custom build: two to four weeks mapping the process and the data model, eight to sixteen weeks for the first two modules in production use, then integrations, reporting and rollout. Phasing matters more than speed, because a first module that people actually use funds the rest of the project politically.

In what order should you build an ERP system?

1. Model the shared records first: customer, product, location, transaction, ledger entry. Everything else is a screen over these.
2. Decide the book of record for stock and for money, and list the systems that will integrate rather than duplicate.
3. Build the module the business is losing money on today, in production, for real users, before starting a second one.
4. Add the money layer next: receivables, payment allocation and automatic postings, so finance stops re-keying operations.
5. Migrate live data early and reconcile it against the old books for one full cycle.
6. Add reporting last, once the numbers underneath it are trustworthy, and keep integrations behind a documented interface so a new channel is an adapter rather than a rewrite.

Related reading

The full write-up of the system this guide draws on is the Bilawal Electronics ERP case study. For the floor-level system that sits beside an ERP, read how to build a warehouse management system, and for turning one of these systems into a product other companies pay for, multi-tenant SaaS architecture. Scope and sequencing are covered in the product discovery process, and budget context in how much it costs to build an app. Sigi’s custom software development and retail and e-commerce pages cover the commercial side, or talk to Sigi about the modules your business needs first.