ERP, without the brochure
ERP is one system of record for the work that makes you money and the work that keeps you legal: orders, stock, jobs, invoices, payments. Custom ERP means that system is designed around your process rather than a vendor’s module list.
Most businesses do not start here. They start with Excel, Tally, a billing package, and a folder of WhatsApp photos. Custom ERP becomes interesting when those pieces start contradicting each other, and when hiring another person to reconcile them is the current “strategy”.
When custom is justified
- Your process is unusual and it is also why customers buy from you — a packaging line, a jobbing shop, a multi-branch service operation with its own billing rules.
- You have already tried a package and the “customisation” quote is approaching the cost of a system you would own.
- You need the data model under your control because you will still be running this in ten years.
When those are not true, buy a product and implement it properly. The comparison is custom ERP versus SAP versus Odoo.
What an implementation actually looks like
Not “go live on the first of the month with everything”. A first live slice — say, orders and stock for one branch — then accounts, then production. Parallel-run the old spreadsheet until the new numbers are trusted. That sequence, and the money attached to it, is in ERP cost and timeline.
What “custom” is not
It is not a rewrite of Tally. It is not a clone of SAP with fewer features. It is not a collection of screens that still leave Excel as the system of record. If after go-live people export to a spreadsheet to “do the real work”, you have built a reporting skin. Custom ERP means the order, the stock movement, the job and the invoice are the same facts, entered once.
The businesses that benefit look like this: jobbing production with their own bill-of-materials rules; multi-branch trade where each branch almost has its own company; service operations that bill time, parts and retainers in a way no package author imagined. The businesses that should buy a product look like this: standard wholesale with standard GST and a willingness to change a form.
Modules you actually launch, not the brochure list
First live slice is usually orders and stock for one location, or jobs and time for one team. Accounts often stay in Tally for a phase, with a nightly or on-post integration, because ripping out the books on day one is how implementations fail. Production, planning, and the customer portal come after the numbers are trusted. That humility is in cost and timeline.
Spreadsheet archaeology, before anyone designs a screen
Photograph the workbooks. Note who updates which tab, and which tab is the one people actually trust. You will find opening stock in a branch book, item codes that collide, and a “final_final_v3” that is the real price list. That pile is the data model. A workshop that ignores it produces a pretty empty system.
We sit with the people who enter orders, not only with the person who bought the project. The order-entry person knows the exceptions. The buyer knows the brochure. Custom ERP is the exceptions, encoded once, so the afternoon is not spent reconciling.
What Monday feels like if it worked
An order is entered once. Stock moves when the dispatch is confirmed, not when someone remembers to update a sheet. The invoice is the same facts, not a retype. Tally still posts the books if that is the phase you chose — but the operational numbers and the accounts numbers can be tied to the same document. Nobody exports “to do the real work”.
If after go-live the WhatsApp group is still the dispatch list, you have a reporting skin. That is not a custom ERP. Fix the path, or admit the project was a screen and budget the next slice honestly.
Tally stays in the first year more often than brochures admit
Accounts know Tally. Auditors know Tally. Ripping it out on day one so the new screens can “do GST” is how you get a go-live that finance refuses. A nightly or on-post integration — order and invoice in the custom system, books in Tally — is a phase, not a failure. You can move the books later if you still want to. Most SME manufacturers we talk to never need to.
The custom part is then the jobbing rules, the branch stock, the dealer portal, the thing Tally will never grow. That split is the point of custom versus a package: you are not buying a religion. You are choosing where the system of record for operations lives.
What we ask for before we will quote a custom ERP
A day with the people who enter orders. A sample of the workbooks, including the ones they are embarrassed by. A list of systems that must stay — Tally, a website, a scale. A first-slice sentence that names one location or one team. If those are missing, we will sell a discovery, not a system. That is not caution for its own sake. It is how you avoid a nine-month build that discovers in week two that two branches do not share item codes.
If a vendor quotes a full ERP from a phone call, they are quoting a product shape, not your process. Sometimes that is what you wanted — a package. Then you are in the SAP versus Odoo versus custom meeting, and you should not call it custom.
Custom ERP is a long relationship with a codebase you can change. Budget maintenance the day you go live — a named window, not “call us if something breaks”. A system with no change budget grows a spreadsheet beside it. That spreadsheet is how you fund the next rewrite. Ownership of source is worthless if nobody is allowed to spend time on it.
We build these as ERP solutions, usually on ASP.NET Core, because the long-term cost is in change, and a system you can change without a vendor’s permission is the point of going custom. If you are still choosing a product, read custom versus SAP versus Odoo first.
Jobbing bills of materials, said plainly
A package “BOM” assumes a finished good you repeat. A jobbing shop often has a recipe that changes per order — hold a batch, substitute a grade, bill the exception the customer already agreed. If that sentence is your week, custom ERP means those facts are entered once and become the job, the stock move and the invoice. If a product can show last Tuesday’s actual job in a sandbox, buy it. If the partner starts talking about a custom module list, you are already building — with someone else’s name on the licence.