Can I Build My Own ERP? Cost, Timeline and Who Owns It
Yes, a shop can build its own ERP. What each of the 3 ways costs, how long it takes, who keeps the code and the data, and where each one breaks.
The NetSuite renewal notice came in higher again, or the third round of Odoo consulting invoices just landed, and the question on your desk is whether the shop should build its own ERP instead. Yes, you can. The real question is which of 3 ways fits your shop.
The 3 ways are: build it with your own developers, buy an off-the-shelf ERP and customize it, or have a partner build a system around how your shop already runs and hand you the code and the data. Each has a real place. Each has a way it fails.
This post answers what each way costs, how long it takes to go live, who keeps the code and the data afterward, and how each one breaks. The right answer depends on which failures you can absorb and which you cannot.
What "build your own ERP" actually means in 2026
The phrase covers 3 very different things:
- Full internal build. Your engineering team writes an ERP from scratch. Backend, frontend, database, deployment, and maintenance are all in-house.
- Framework-based build. Start from an open-source ERP framework (Odoo, ERPNext, Frappe) and customize until it matches the operation. Own the deployment. Modify the code.
- Partner-built, operator-owned. A firm builds a custom ERP around your workflows and hands your team the code, the data, and the development environment. You keep all of it after handoff.
The internet argues about paths 1 and 2 like they are the only options. Path 3 is the one most comparisons leave out, and it is what we build.
The cost of each path, honestly
Full internal build
A working ERP for a mid-market manufacturer needs a minimum of 4 engineers for 18 to 24 months to reach parity with an off-the-shelf system. Fully-loaded engineer cost in the US is $200k to $300k per year. Call it $1.5M to $3M to first production, plus $500k to $1M per year to maintain.
This is the right number if the ERP is a differentiator. If your operation's competitive edge is the software, that spend makes sense. For a manufacturer whose competitive edge is the physical operation, it does not.
Framework-based build
Start with Odoo or ERPNext. Hire an internal developer or contract with a specialist firm. Customization runs $50k to $250k up front, plus a retainer for ongoing changes ($30k to $100k per year).
The gotcha: every upstream release of the framework can break your customizations. Odoo pushes yearly major versions. Your custom modules need to be re-tested, sometimes rewritten. The retainer never goes to zero.
Partner-built, operator-owned
KoldOps builds the core in under 6 months for under $100k, hands over the code and the data, and trains your ops leadership to extend it. GatorStep, a marine manufacturer, moved off Microsoft and Odoo onto one system in 2.5 months. Ongoing cost is hosting (a few thousand a year) plus an optional KoldOps retainer for the hard parts.
The gotcha: your ops leader has to actually be someone who wants to develop. If your VP of Ops does not want to touch the system, the model breaks and you are back to needing a partner for every change.
Timeline, side by side
| Path | Time to first production | Total first-year cost | Ongoing annual cost |
|---|---|---|---|
| Full internal build | 18 to 24 months | $1.5M to $3M | $500k to $1M |
| Framework build (Odoo/ERPNext) | 3 to 9 months | $50k to $250k | $30k to $100k |
| Partner-built, you keep the code | Under 6 months | Under $100k | Hosting + optional retainer |
| Off-the-shelf SaaS (NetSuite, Acumatica) | 4 to 12 months | $50k to $500k | $50k to $500k, grows yearly |
When each path wins
Full internal build wins when
- Your operation depends on functionality no vendor sells (rare in manufacturing, common in adtech or fintech).
- You have a permanent engineering team with ERP experience and the capacity to absorb the project without dropping other work.
- The company treats software as a strategic asset with dedicated budget and executive sponsorship.
Framework build wins when
- You want ownership of the code but do not want to write the whole thing from scratch.
- Your operation matches the framework's data model closely enough that customization is bounded.
- You have or are willing to hire one internal Odoo or ERPNext developer.
Partner-built wins when
- You want a system that fits how your operation actually runs, not one that forces workflow changes to fit the software.
- Your VP of Ops or COO is a hands-on operator who wants to extend the system themselves rather than waiting on a vendor.
- You want the cost model of custom software (build + host) without the timeline of a full internal build.
- You have already been through an ERP migration and know you never want to be stuck on somebody else's release cycle again.
Off-the-shelf SaaS wins when
- Your operation is close enough to the vendor's model that customization is minimal.
- You value the vendor's roadmap and are willing to pay for it.
- Data residency and per-seat pricing are not concerns.
The failure modes of each path
Every path has a way it goes wrong. Pick knowing what breaks it.
- Full internal build fails when the team gets pulled onto other projects, when a key engineer leaves, or when the executive sponsor changes jobs. The half-built ERP becomes a maintenance albatross that neither ships nor dies.
- Framework build fails when an upstream version bump breaks 40 percent of the customizations and the internal developer left 6 months earlier. You are now paying an Odoo consultant $250/hour to reverse-engineer your own system.
- Partner-built fails when the ops leader who was supposed to own it turns out to hate development work and the system quietly stops evolving. You need a partner retainer to keep it moving, which erodes the ownership pitch.
- Off-the-shelf SaaS fails when the vendor deprecates a module you depend on, when the annual price increase outpaces your growth, or when a compliance requirement forces on-prem and the vendor does not offer it.
What a partner-built ERP actually includes
The term "custom ERP" scares people because they imagine a bespoke tangle nobody can maintain. That is what full internal build sometimes becomes. A partner-built system your shop owns looks different:
The difference that matters most is who owns the result. Manufacturing data sovereignty scores each ERP category on residency, ownership, portability, and extensibility, and it is the clearest way to compare the 3 paths. If you are here from a renewal quote, the NetSuite alternatives worth considering cover the buy path in detail.
- Core modules built to your operation. Work orders, part masters, inventory, quality, purchasing, shift reporting, and BOMs, shaped by how your shop actually runs.
- Standard integrations. QuickBooks or your existing accounting, your shipping providers, your CAD files, your MES if you have one.
- You keep the code and the data. Both are handed over, documented, and yours to move. No vendor stands between you and your own production records at renewal time.
- Development environment for your ops team. Documented, version-controlled, with the tooling your VP of Ops needs to add a field, add a workflow, or spin up a new report themselves.
- Training and runbooks. Your ops leader can extend the system without calling us. Your users can operate it without a support ticket.
- KoldOps on call for the hard parts. Integrations, migrations, breaking changes. The parts a small internal team should not be doing alone.
The question that actually decides it
Every framework for picking an ERP asks about revenue, module fit, and integration count. Those matter. The question that decides whether you should build instead of buy is different:
How much of your operation is unique?
If your workflows look exactly like the SAP or NetSuite reference implementation, buy their reference implementation. You will fight it less than you would fight a custom system.
If your workflows are 20 to 40 percent unique, buy an ERP and pay for customization. Odoo, Acumatica, or Business Central. Expect the customization to break every upgrade cycle.
If your workflows are 40 percent or more unique, off-the-shelf is going to fight you forever. Build it. Either internal, framework-based, or partner-built. Which of those 3 depends on whether you want to own the engineering function or just own the software.
Questions we get
How do you select the right ERP system?
Start from what you cannot currently answer rather than from a feature list. Write down the 3 questions about your operation that take a person more than an hour to answer today, then make every vendor demonstrate those 3 on your data, not their sample set. Most evaluations invert this: they score 200 features nobody will use and never test the handful of questions that drove the project. Bring your weirdest job to the demo, not your most typical one.
What are the 5 ERP modules?
There is no fixed set of 5, and the number moves with whoever is selling. The functional blocks that matter to a manufacturer are order intake, engineering and planning, the shop floor, inventory and purchasing, and finance. Some vendors split those into a dozen priced modules, which is a packaging decision rather than an architectural one. Ask what the total looks like with every module you would actually need turned on.
How is ERP used in manufacturing?
In principle it is the single record of what was ordered, what it takes to make, what the floor did, and what it cost. In practice most mid-market shops use it as an order and invoicing system while the production reality lives in spreadsheets and on a whiteboard. That gap between the intended use and the actual use is the thing worth measuring before buying anything new.
What is replacing ERP?
Nothing, despite the headlines. What is changing is the shape: fewer monoliths, more of a spine that owns the record with focused systems around it, and enough shared data that a question can be asked across the whole thing. The pitch that ERP is dead usually comes from someone selling one of the surrounding pieces. The record still has to live somewhere.
Isn't custom software always more expensive over 10 years?
No. That was true when custom meant a bespoke tangle with $250/hour maintenance. It is not true when custom is built with modern tooling, git-tracked configuration, versioned migrations, and a development environment your ops team owns. The 10-year cost of a partner-built system can come in under the 10-year cost of a SaaS ERP, because the annual line item stops growing. Run that comparison on your own invoices before you trust anyone's version of it, including ours.
What happens if KoldOps goes out of business?
You still have the code and the data. Any competent developer can pick it up. The system does not run on anything proprietary to KoldOps. This is the specific opposite of the vendor lock-in problem.
Can we start small and grow?
Yes. The first build is scoped to the highest-friction modules (usually work orders, inventory and shift reporting). Additional modules ship over time. This works because your ops leader is the one deciding what to build next based on what the operation actually needs.
How is this different from Odoo customization?
Odoo customization is you paying a consultant to shape their framework to your operation. A partner-built system is you owning software written for your operation. Different starting point, different upgrade story, different long-term cost curve.
What's next?
If you are still deciding, start with a close look at what you run today. You will have real numbers on what your current systems cost against what a custom build would.
If you are ready to plan the move, write to Kol with what the shop runs on today and which part of it hurts most. The first conversation is about your shop, not a pitch. We will not sell you custom if a $30k Odoo implementation would fit better.