Most custom ERP systems do not make it past the planning stages. The 2024 Panorama Consulting report on ERP outcomes approximates abandonment, delays, or cost overruns at between 50% and 75% of all implementations. When surveyed, practitioners tend to point to the same phenomena found when project failures are examined post-mortem. In most cases, the problem is not with the code. The workflow design was never completed and roles were never defined. A busy team may have actually thought they were making progress.
Custom ERP development may be justified when your team is wearing themselves out interpreting the business within the confines of the software. Development should be avoided when the workflow you are trying to implement is just process debt in a fancy wrapper. This guide is suitable for those within the business or as an operator who is considering building a custom ERP—what should be done first, who should build it, and the costs, time to build and what should be expected in the first year after release. If you want a broader view, our guide on custom enterprise software will give you the information you are after.
When a Custom ERP Actually Makes Sense
The problem with systems integration is not the size of the problem. The problem is when systems come into contradiction with one another. When two systems provide two different answers for the same or similar numbers, this should be a strong sign that standard systems have been stretched to their breaking point. One system registers orders while the other system shows a stock shortage. Finance personnel are stuck working in a spreadsheet that was patched at the last minute.
By that time, the CRM is incapable of modeling the sales motion. Invoicing does not line up with fulfillment. Each workaround has become a permanent shadow process. This is the operational tax that teams incur when they select the wrong system. It’s the hours of work spent to make the software work the way the business already does, not the cost of the license.
What you are actually buying
What you pay for is one place to stop the contradiction between operations, finance, inventory, and customer work. This is what you get. The features are how you get there.
The useful test is whether a workflow creates advantage or just mirrors process. If it improves margin, speed, or a specific customer promise, keep it and build around it. If it was done that way in 2016, standardize it and move on. Confuse the two and you will spend six figures automating the second kind.
The selection of an ERP system should reflect how the company makes money. So treating this as a business planning exercise vs. a software buying exercise changes the outcome. A good primer on how to align IT investment with revenue is an excellent complement to this stage, because the modules worth customizing are usually closest to how your customers get charged.
Build, Buy, or the Expensive Middle
The most expensive option is to buy a packaged ERP, only to discover that you must extend it to the breaking point. You end up having to customize it and, ultimately, deal with a failing project, not to mention pay the license. According to Panorama’s 2024 data, heavily customized implementations of NetSuite and Dynamics are the most likely to go over budget and exceed time allocations, as teams greatly underestimate the extent of the platform that they will end up rebuilding.
| Dimension | Buy (SaaS ERP) | Custom Build |
|---|---|---|
| Upfront cost | Lower | Higher |
| Time to first working module | Weeks to months | Months to a year |
| Fit to non-standard workflows | Limited | High |
| Long-term flexibility | Constrained by the vendor | Constrained by your engineering discipline |
| Lock-in risk | Contractual and data-format | Architectural and knowledge-based |
The more standard your workflows are, the more you should be inclined to buy. If two or three processes significantly differentiate you in the marketplace, then you should be inclined to build them and integrate. A common approach for growing mid-market firms is to purchase a reputable tool for compliance-heavy, standard processes (e.g., general ledger, payroll) and build a custom system for the processes that differentiate them.
Where different operators land
An ERP (enterprise resource planning) system purchase is almost always the route for a 30-person services firm, as the firm’s workflows are generally not that unique. However, for a 150-person manufacturing firm, a custom build becomes more necessary as the firm’s production and quality control processes are likely unique. A growing ecommerce firm is more likely in the middle, purchasing an ERP system for general finance and fulfillment processes, but building a custom system for order logic and merchandising.
Customizations should only occur when workflows alter the firm’s revenue or margin or dramatically speed up the firm’s processes. Preferences of individual managers should not be a reason to customize a system.
The First MVP Module Should Be the One People Complain About
The temptation is to start with the module that looks most impressive in a demo. That is the wrong instinct. Start with the one your team already builds workarounds for every week. It should touch cash, remove a recurring bottleneck, or replace a spreadsheet that has become load-bearing.
Score candidates by frequency, friction, and uniqueness
Judge the modules on three separate criteria. The first is frequency or how many iterations the process goes through. The second is how painful it is to deal with the process today, known as friction. Third is uniqueness or how novel this process is to the company’s standard operating procedures. Generally, the winner is the process that is high frequency and high friction that also has some competitive advantage.
For a 120-person specialty food distributor, this module is usually order to cash. It’s a frequent process, staff feel the pain from it because it directly impacts how long a business takes to collect money, and it’s not a data cleaning process that can be put off to a later time by operators.
The first module has to touch money within 30 days
The first module needs to have a noticeable impact for the end user or customer one month after implementation. If not, people will revert back to the old system, which in this case is a spreadsheet, even if it means they have to work around the system. The first module should eliminate a bottleneck, approval, or provide a number to finance that was previously unavailable.
This comparison applies to a custom CRM development project or a build of an internal portal. Begin with the most crucial process. Build the system around that. Everything else falls in line.
In-House, Agency, or a Studio With a Fractional CTO
The answer is not necessarily about who has programming skills. Many teams have those skills. The answer is about who is able to identify true differentiators rather than process debt and uphold this differentiation with great focus during the development effort as the pressure continues to build.
| Dimension | In-house team | Agency | Studio with fractional CTO |
|---|---|---|---|
| Control | Highest | Medium | High |
| Speed to start | Slowest | Fast | Fast |
| Upfront commitment | Highest | Medium | Flexible |
| Post-launch ownership | Cleanest if staffed | Often messy | Usually workable |
An internal team is warranted when an ERP system starts to integrate into core product offerings as compared to supporting product offerings. Engineer compensation usually falls between $80,000 and $140,000, and the first working release will still take six to twelve months when hiring and onboarding as well as the inevitable rework of the first data model are factored in. The reward is ultimate ownership. The risk is that you now have an operating engineering division, even if you didn’t want/need it.
An agency is appropriate when specifications are well defined and product offerings are mostly standard. The cost for a focused MVP is typically between $150,000 and $500,000. The risk is that agencies ship against the brief, not against your operating model. By the time your product is launched, you will have learned the code is adequate; however, the assumptions embedded in the code will have been found to be maladaptive to the operations of your business.
A fractional CTO for a studio typically costs between $8K–$20K per month. This option provides senior-level advice regarding scope and architecture for your project, without requiring a full-time executive hire. This often meets the needs of the first custom module as most of the initial value in the modules is in determining what scope remains standard, and what actually needs customization. Our article on outsourcing SaaS development has a more in-depth overview of how these engagements usually work.
Select your team model after you select your first module since the scope of your work should dictate who you select, rather than the other way around.
Integration and Data Migration Are Where Budgets Slip
Having a custom ERP system isn’t about the features, it’s about the connections. Payments, CRM, accounting, HR, and other connections you might have with your warehouse, as well as partners who send you random EDI data at 3 AM, will cost you the most. Each connection you have will have hidden requirements that will only surface when you go to test the system.
For a good outside reference, see this article on real data integration challenges which has the same challenges reported in ERP systems as reported by practitioners: quality, schema drift, cost of touching legacy pipelines, slippage in project timelines.
Roll out by department, not by company
Define the range of impacts. Launch one warehouse, one region, or one product line at a time. This will allow you to have a controlled launch. Big-bang system changes are where consulting nightmares begin.
Clean the data before you write the migration script
The final step is migration. Here are some things to do in advance.
- Deduplicate records. Customer and vendor duplicates cause the most silent damage post-launch.
- Standardize SKUs and account codes. Inconsistent naming across spreadsheets becomes inconsistent reporting in the new system.
- Retire what does not need to move. Archive transactions older than seven years unless there is a legal reason to keep them live.
- Map custom fields explicitly. Every legacy field either maps to a target field or gets retired. No maybes.
- Assign one owner per data domain. Committees do not make decisions during a migration. Individuals do.
A major part of the work will involve moving the data from one system to another. Our database migration overview is a starting point for planning the technical side of this; it outlines some of the steps involved to avoid underestimating the work.
If the new system inherits the old system’s mess, users will not call it a transformation. They will call it a nicer-looking spreadsheet.
Risk, Security, and Compliance Without the Jargon
Scope creep will begin after the first working demo. People will see something real and ask for one more field, one more rule, one more exception. Do not freeze the entire project. Freeze what is above a set threshold for the first module until the first module has made it through a full business cycle. That will protect more budgets than any Gantt chart.
The other slip is testing. The timing issues occur not during the coding, but with migration and integration testing. To catch issues that would cause a Monday morning payroll nightmare, we run the new system in shadow mode against the old system for a minimum of four weeks before a cutover.
Security and compliance should have actual owners from day one. SSO, RBAC, and encrypted backups, with an audit log, should be considered baseline, not extras. Then consider the compliance impact of the data the system actually processes: SOC 2 for B2B software, HIPAA for anything health related, GDPR for EU customers, and PCI-DSS if card data touches the ERP. The cleaner builds keep card data out of the ERP and instead route it through a tokenized payment processor. That decision reduces the compliance surface area by at least an order of magnitude.
Realistic Cost and Timeline Bands
The price range for “custom ERP” starts with a Frappe-based three-module build, and goes all the way to a multi-year rework of the company’s core systems. Below I outline what we’ve heard is the average cost for mid-market projects in 2026.
| Scope | Estimated cost | Timeline | Typical team |
|---|---|---|---|
| 3-module MVP | Around $180K | 4 to 6 months | Small studio or agency |
| Mid-market build | $150K to $750K in year one | 6 to 18 months | Hybrid team |
| Larger custom platform | $600K and up | 12 months or more | In-house or hybrid |
How to read a quote
When looking at the costs presented, separate the one-time build costs from the recurring costs. Hosting, licensing, and support costs show up whether or not the vendor labels them clearly. There are also costs for system stabilization. Many projects include hidden costs for training and change management. A proposal that leaves those costs out looks cheap, but it isn’t. In fact, it’s incomplete.
The middle row is where you need the most discipline. This row concerns interfaces, migration, training, and the amount of custom process you decide to keep. If a vendor cannot break a number into build, migration, and support into completely separate lines, then consider that a clear signal to walk away. Ambiguity in a quote equals ambiguity in a delivery.
What pushes the range higher
- More modules. Each one adds testing, training, and handoff work.
- Deeper integrations. Legacy connections take longer than any estimate assumes.
- Compliance requirements. Security review slows delivery and adds review cycles.
- Messy data. Every reconciliation issue found late is worth ten found early.
- In-house delivery. Ramp time is real and often invisible in the plan.
Writing down clear requirements before starting work pays dividends in weeks, not months. Our article on documenting software requirements outlines what a usable spec entails, and the checklist should take less than a day to complete.
What the AI-Native Angle Actually Changes
The most anticipated shifts in 2025 and 2026 are in the area of agentic ERP systems. These are ERP systems in which the business users interact with the system via a natural language interface while AI agents control the ERP process workflows. Several practitioners indicate that within a span of 2 to 3 months, they have built production versions of these types of systems using LangGraph for workflow orchestration, a small local model to avoid a cost blowout, FastAPI, and a React front end. One such example describes a complete agentic ERP built in 2.5 months after the development of a custom audit and observability layer in order to provide transparency for agent behavior.
Take these timeline estimates with a healthy dose of skepticism. A single practitioner build sets no enterprise benchmark. What is substantiated is the direction. AI is decreasing the cost of building custom software and changing the math as to whether builds should be considered. What is still to be determined is if agentic behavior does meet enterprise auditability and, in particular, financial and inventory workflows where absolute control is required.
The safe strategy for most operators at this point is to build agentic layers on top of a deterministic core, rather than swapping the core for agents. Have your agents process natural-language queries, draft, and route. Have your deterministic code post to the ledger and adjust inventory. This retains the audit trail while providing business users with the easier of the two interfaces.
What Happens After Launch Decides Whether It Was Worth It
During the first 90 days following implementation, a new Enterprise Resource Planning (ERP) system will either be adopted and considered integrated as trusted infrastructure, or it will be viewed as a tool that users will circumvent. Assess the ERP based on what people do once the initial excitement from the launch email has faded.
The ideal 30-60-90 plan for the new system is to address system instability and the most critical defects in the first 30 days, then look at usage patterns to find the gaps in system adoption over the next 30 days. The final 30 days can be used to prioritize new system features as documented in the system adoption data, as opposed to the most vocal system feature requests during daily standup sessions.
Simplify your standard operating procedures for high-volume recurring tasks. Spot your early adopters (power users) and let them help the rest of the organization. Schedule your backup verifications on your calendar. Schedule a review every three months with the system’s creator to prevent minor concerns from turning into a full-blown crisis. Building the new version of the SingularityHub platform was only part of the work. The rest was protecting the workflow the editorial team relied on and allowing them to control parts of the design after the launch and without having to code. In ERP, the tool needs to fit the work, and someone needs to make certain it does.
If you are pondering what to build, what to standardize, and who should own what, these early decisions are what our discovery process is designed to resolve. Our portal and dashboard development work targets the operational systems that are adjacent to ERP workflow, and during the strategy phase of our engagement, we offer a money-back guarantee, ensuring our clients start from a clear position and not from a guess.
Saeedreza Abbaspour is the CEO of Refact, where he works across product, engineering, and sales. He sets the studio’s direction while staying closely involved in the work itself, from shaping product strategy and UX architecture to helping define the technical systems behind Refact’s projects. His role connects business thinking with hands-on product execution, giving him a practical view of how software should be planned, built, launched, and improved. At Refact, Saeedreza focuses on building a studio that can move quickly, solve real client problems, and turn ideas into reliable digital products.
More from Saeedreza Abbaspour
