Most ERP projects don’t fail during development. They fail before a single line of code is written – because the scoping was vague, the pricing was a guess, and no one had a real decision-making process in place.
If you’re an operations leader at a scaling company, you’ve probably already hit the wall. Spreadsheets are breaking down. Your SaaS tools don’t talk to each other. A key hire left and took half the institutional knowledge with them. You know a custom ERP system is the answer – but the path from “we need this” to “it’s built and live” feels murky.
This article gives you a practical 90-day framework to scope the project properly, arrive at a real price, and make a confident go/no-go decision – without spending six months stuck in discovery limbo.
Why 90 Days Is the Right Horizon for Greenlighting an ERP Build
Ninety days is long enough to do this seriously and short enough to keep momentum. Stretch it to six months and the project loses urgency. Compress it to 30 days and you’ll skip steps that actually matter.
The goal of this period isn’t to build the system. It’s to reach a clear, defensible decision: build it, delay it, or descope it. By day 90, you should have a defined scope document, a realistic budget range, a shortlist of two or three development partners, and either a signed agreement or a documented reason for waiting.
Month One: Diagnose Before You Design
Map the Pain, Not the Features
The most common mistake at this stage is jumping straight to a feature list. Don’t. Start by documenting what’s actually broken.
Walk through your current operations and write down every place where a person is doing something a system should handle. Manual data entry. Reports that require pulling from three different sources. Approvals sitting in someone’s inbox instead of moving through a workflow.
This is your pain map. It’s more valuable than any feature list because it tells a development team what the system actually needs to solve – not what you think you want.
Define the Core Module Set
Once you have the pain map, group the problems into functional areas. Most custom ERP builds for growth-stage companies center on four to six core modules:
- Inventory and order management – stock tracking, purchase orders, fulfillment
- Finance and billing – invoicing, accounts payable/receivable, reporting
- Operations and workflow – job tracking, task assignment, status visibility
- HR and resource management – headcount, scheduling, onboarding
- Reporting and dashboards – real-time visibility for leadership
You won’t need all of these on day one. Prioritize by impact: which two or three modules, if they worked well, would change the most about how your business operates?
Identify Your Integrations Early
Integration complexity is the single biggest variable in ERP pricing. A system that needs to connect to Shopify, QuickBooks, a third-party logistics provider, and a legacy database from 2014 is a fundamentally different project than a standalone build.
List every external system the ERP needs to communicate with. Note whether each one has a documented API. That list will directly shape your budget estimate in month two.
Month Two: Build a Realistic Budget Range
Understand the Pricing Drivers
Custom ERP development is project-based, not subscription-based. You’re paying for design, engineering, testing, and deployment – and the price reflects the complexity of what you’re building.
The main factors that move the number:
- Module count and complexity – more modules mean more cost; complex workflow logic costs more than simple data display
- Integration requirements – each external system adds design, development, and testing time
- Data migration – moving historical data from legacy systems is consistently underestimated
- UI/UX requirements – a system your team will actually use needs thoughtful interface design, not just functional screens
- Timeline – compressing a build into three months costs more than spreading it across six
For a growth-stage company with 20 to 200 employees, a well-scoped custom ERP typically falls between $30,000 and $150,000 depending on these variables. A focused two-module build with minimal integrations sits at the lower end. A full-featured system with multiple integrations, data migration, and custom reporting sits higher.
Build Your Internal Business Case
Before you take a budget to leadership, build the business case. What does the current broken state actually cost you?
Quantify it. If your team spends 15 hours a week on manual data reconciliation, that’s real labor cost. If you’re losing orders because your inventory system doesn’t update in real time, that’s lost revenue. If your reporting takes three days to produce and is still inaccurate, that’s a decision-making problem with a financial consequence.
A custom ERP that costs $80,000 and eliminates $120,000 in annual operational waste pays for itself in under a year. That’s the conversation to have with your CFO or board – not “we want to build software,” but “here’s what it costs us not to.”
Get a Rough Estimate Before You Shortlist
Before you spend time evaluating development partners, get a ballpark. Share your pain map, module list, and integration requirements with one or two agencies and ask for a rough range – not a full proposal, just a number to pressure-test your assumptions.
This tells you whether your internal budget expectations are realistic. If you’ve budgeted $40,000 and every agency comes back at $90,000 minimum, you need to descope or adjust before going further.
Month Three: Evaluate Partners and Make the Call
What to Look for in an ERP Development Partner
Not every agency that builds software should build your ERP. The right partner has three things:
1. A structured delivery process. Ask how they move from scoping to build to launch. Vague answers are a signal. A clear process – like an Analyze, Implement, Optimize framework – tells you the agency has done this before and knows where projects go wrong.
2. Direct access to the people building the product. Large outsourcing firms often put an account manager between you and the engineering team. That layer adds time, miscommunication, and cost. You want to talk directly to the people writing the code and making design decisions.
3. Relevant case studies. Has the agency built systems for businesses with operational complexity similar to yours? A wellness app and an industrial system for a company like Emerson are very different builds. Look for evidence the team understands operations-heavy environments, not just consumer-facing products. You can review relevant case studies to see the kind of work a partner has actually shipped.
Red Flags to Watch For
- No clear timeline or milestone structure in the proposal
- Pricing that seems unusually low – often a sign of scope misunderstanding or offshore handoffs without proper oversight
- Vague answers about who specifically will work on your project
- No post-launch support plan
- Proposals that don’t reflect what you actually told them in the brief
The Shortlist and Decision Process
By week 10, you should have two or three proposals in hand. Evaluate them across four dimensions:
| Dimension | What to Assess |
|---|---|
| Scope alignment | Does the proposal reflect your actual requirements? |
| Timeline | Is the delivery date realistic and clearly structured? |
| Process clarity | Do you understand exactly how the work will happen? |
| Team access | Will you work directly with the builders? |
Price matters, but it shouldn’t be the deciding factor. A $60,000 project that ships on time and works is worth more than a $45,000 project that runs six months over and needs a rewrite.
Greenlight Criteria
Before you sign, make sure you can answer yes to all of these:
- The scope document reflects our actual operational needs, not a generic ERP template
- The timeline has clear milestones and a real launch date
- We know exactly who will work on this project
- The budget is approved internally and the business case is documented
- We have a change management plan – our team knows this is coming and understands why
If any of those answers is no, don’t sign yet. Resolve the gap first.
What Happens After Greenlight
Signing the agreement isn’t the end of the 90-day process – it’s the output. Once you greenlight, the real work begins.
A well-run custom ERP build moves through three phases: a deep analysis of your workflows and data architecture, implementation of the system module by module, and an optimization phase after launch where the system is refined based on real usage. That’s not a marketing framework – it’s how good software actually gets built and improved.
The teams that struggle post-greenlight are the ones who treated scoping as a formality. The ones that succeed did the work in months one and two: mapped the pain, built the business case, and chose a partner with a clear process and direct accountability.
If you’re at the point where you know a custom ERP is the right move but aren’t sure where to start, TechYouKnow works with operations leaders to scope, price, and build custom ERP systems through a structured process with clear timelines and direct team access. The free 15-minute consultation is a good first step to pressure-test your scope before you commit to anything.
Frequently Asked Questions
What is a custom ERP system?
A custom ERP system is software built specifically for your business’s operational workflows – not an off-the-shelf product like SAP or NetSuite that requires your team to adapt to its structure. A custom build is designed around how your business actually works: your processes, your integrations, your reporting needs.
How long does it take to build a custom ERP system?
A well-scoped custom ERP for a growth-stage company typically takes three to six months to build and deploy. The timeline depends on module count, integration complexity, and data migration requirements. Compressing the timeline is possible but increases cost.
How much does a custom ERP system cost?
For a company with 20 to 200 employees, a custom ERP build generally falls between $30,000 and $150,000. A focused build with two or three core modules and minimal integrations sits at the lower end. A full-featured system with multiple integrations, custom reporting, and data migration from legacy systems sits higher.
Should I build a custom ERP or buy an off-the-shelf solution?
Off-the-shelf ERP tools work well when your operations are fairly standard and your team can adapt to the software’s structure. When your workflows are specific to your industry, when you’ve already tried SaaS tools and they don’t fit, or when integration complexity is high, a custom build is usually the more practical long-term investment.
What’s the biggest risk in a custom ERP project?
Poor scoping. Projects that start without a clear pain map, a defined module set, and documented integration requirements tend to expand in scope, run over budget, and miss deadlines. Doing the scoping work properly in month one is the highest-return investment in the entire project.
How do I know if my company is ready for a custom ERP build?
You’re ready when the cost of your current broken state – in labor, lost revenue, or delayed decisions – clearly exceeds the cost of building a solution. If your team is spending significant time on manual processes that a system should handle, or your existing tools can’t keep up with your growth, the business case is usually already there.
What should I ask a development agency before signing?
Ask how they structure the scoping and discovery phase, who specifically will work on your project, what the milestone and delivery timeline looks like, how they handle scope changes, and what post-launch support includes. Clear, specific answers are a strong signal that the agency has a real process and has done this before.
Make the Decision With Confidence
Ninety days is enough time to go from “we need this” to a signed agreement with a clear plan. The real work is in the scoping and the business case – not in vendor selection. Get those two things right and the rest of the process follows.
Don’t wait for the perfect moment. The cost of staying on broken systems compounds every month you delay.
