What is custom ERP development?
Building the system a business runs its orders, stock, purchasing, invoicing and accounting handoff on, written around how that business actually works instead of around how a vendor thinks a business should work. The word ERP covers a lot; what matters is one place where a sale becomes a pick, a pick becomes a shipment, a shipment becomes an invoice, and the stock number is true afterwards.
Custom does not mean bigger. It usually means fewer screens, the two rules your current tool cannot express, and no export-and-retype step between departments. I build it in Next.js and TypeScript with PostgreSQL or Supabase behind it, one module at a time, with coding agents doing the drafting and me owning the rules.
Do I need a custom ERP, or should I buy one?
Buy one, most of the time. If your process is normal for your industry, a package will be cheaper, better tested and easier to staff, and I will say so on the first call. NetSuite and SAP Business One are strong products; people pay for them because the work inside them is real and finished.
Custom earns its place when the process is the reason you are different, or when the package's rules cost you hours every week. The honest signals: you keep exporting to a spreadsheet to finish a job the system should do; you pay for a module you use for one screen; a consultant is needed every time something small changes; or your stock and your floor disagree and nobody knows which is right.
If two or more of those are true and the pain sits in one department, start with one module, not a program. Replacing a whole ERP is a long decision with a long payback; getting orders and stock onto one truthful screen is a much smaller one, and it is the one I would do first.
Is it better to customise Odoo or build my own?
It depends on how much of the package you will actually use, and who you can find to hold it. This is the honest comparison, and none of these options is cheating.
| The question | Off-the-shelf ERP | Customising Odoo or ERPNext | A custom ERP I build |
|---|---|---|---|
| Cost to start | Highest, plus implementation | Low to medium, but a partner's time adds up | One fixed price, starting at $799 |
| Licence per user | Yes, and it scales with headcount | Community editions carry no licence fee if you host them, and leave out parts of accounting and perpetual inventory; Enterprise adds them for a per-user subscription | No licence fee. You pay for hosting and the database |
| Fit to your process | You change to fit it | Close, then custom work for the gaps | Written around it, including the odd rules |
| Who owns it | The vendor | You own the install, the partner holds the knowledge | You own the code and the data |
| What breaks at scale | The per-user bill and the edge cases the package will not do | Upgrades, and whoever configured it leaving | Capacity: one engineer, so scope and dates go in the written plan |
| Changing it later | A vendor release cycle | Whatever the module supports | Any engineer with the repository |
Which module should you build first?
Almost always the one that touches money or stock, because that is where a wrong number costs you. In practice the order is: items and stock levels, then sales orders and fulfillment, then purchasing and suppliers, then invoicing and the accounting export, then pricing rules and approvals, then reporting across all of it.
Reports come last on purpose. A report built before the transactional data is trustworthy is a decoration, and the reporting layer over a working ERP is a project of its own, not the first thing you pay for.
How do you roll it out without stopping the business?
In phases, never big bang. One module goes live first and runs alongside the spreadsheet or the old system for as long as it takes to prove the numbers agree. Then the next module. The old way stays available until the people using it choose to stop, which is also how you find out whether the screens are wrong.
Two things make this work. A dry run of the migration on a copy, with totals reconciled against the source, before anyone touches production. And one named person per module who signs off that it is right, because a system nobody approved is a system nobody trusts.
Where does AI belong in an ERP?
In two places, and only where it pays for itself. The first is the build: coding agents draft the forms, filters, list screens and report queries, which is a large share of an ERP, and I check and test what they produce.
The second is inside the system, on a decision you make every day and can measure. A client of mine runs a commerce business that was setting prices and reorder levels by hand, item by item. I built an engine that reads their sales, costs, stock history and competitors' public prices and recommends a price and a stock level for every item, run as a daily job rather than a chat window. That is the shape worth automating: a narrow recommendation, checked item by item against the data before anyone acts on it.
What I do not put in an ERP: a chat box in front of your database with no permission model, or an agent making irreversible stock movements on its own.
What does a custom ERP cost?
The starting point is the same as internal tools and dashboards: $799 for a first module. Small jobs start at $49. A fix, a report or one extra screen sits in that small-job band. The full number is one fixed price agreed in writing after a free call, because ERP work is scoped module by module and nobody should discover the cost halfway through a migration.
Running costs are separate and I estimate them before the build: hosting and the database, any accounting or shipping APIs you connect to, and the model spend if you want an AI feature inside the system.