ERP Vendor Selection: What I Tell Every Client

Every year, a few dozen clients ask me: "Should we buy an ERP or build our own?"

The default answer is "buy." Building ERP is incredibly expensive and nobody's better at it than the vendors. But the default isn't always right.

Here's the framework I actually use.

Question One: What's Broken?

I don't ask "what do you need in an ERP?" That's too abstract.

I ask "what's broken about how you operate right now that an ERP would fix?"

If the answer is "we don't have visibility into our inventory" or "we can't close the books in less than five days," those are problems ERP solves. Buy one.

If the answer is "our growth has outpaced our systems," probably buy. You need a system designed for scale.

But if the answer is "our business model is completely different from standard businesses and we need something that models our exact workflow," you might need custom software.

The key thing I'm listening for: is this a standard problem or a unique problem?

Standard problems: buy. Unique problems: maybe build.

Question Two: How Strategic Is This?

Is the ERP a cost center or a competitive advantage?

Most companies: cost center. You want it to work well and get out of your way. Buy something that works.

Some companies: competitive advantage. The way you manage your supply chain or your customer relationships is how you beat competitors. If an off-the-shelf ERP forces you into their workflow, you lose your advantage.

I have one client in custom manufacturing. Their production workflow is insanely complex and it's why they win. A standard ERP would flatten that into a generic process and they'd lose their edge. Custom software was the right choice.

I have another client in wholesale distribution. Their business is basically standard. A cheap cloud ERP was the right choice. Why build?

Listen to how the client talks about their business. If they say "we're special, we need special software," and they can articulate why specifically, build. If they say "we're special" but can't articulate why, buy standard and adapt.

Question Three: What's Your Timeline?

Build vs. buy has a huge time dimension.

Buy: You're live in 6-12 months (if you're disciplined) or 18-24 months (if you're not).

Build: You're live in 18-36 months. Minimum. Probably longer.

If you need cash flow visibility by Q4, buy. You don't have time to build.

If you can absorb two years of development, building is possible.

But this also interacts with Question Two. If it's strategic, you might be willing to wait. If it's a cost center, waiting two years is just expensive.

Question Four: What's Your Depth?

How deep do you need the system to work?

By "depth" I mean: how many dimensions does your business operate in?

A simple B2B SaaS might only need financials and very basic customer tracking. Depth is low. Any ERP works. Might even be overkill.

A manufacturing company with complex supply chains, lot tracking, multi-location inventory, custom pricing, and regulatory requirements. Depth is high. You need a system that handles all those dimensions well.

The weird thing: standard ERPs are weirdly good at depth for standard industries. SAP has deep pharma capabilities because pharma is standard (and expensive, so they invest). NetSuite has deep e-commerce capabilities.

But if your industry is non-standard, or you operate across multiple industries, depth is a problem. Standard systems handle one standard scenario well. They handle custom scenarios poorly.

This is where I often see the build decision happen. "We're in three different industries and we need depth in all three." Standard ERP can't do it. Custom software can.

Question Five: Do You Have the Engineering?

This one's practical. Can you actually build this?

Building an ERP requires specific expertise: data modeling, financial systems, workflow engines, audit trails. It's not web app engineering. It's not mobile app engineering.

A company full of web developers can hire expertise or partner with someone who has it. But that's an additional cost and dependency.

If you're considering building, you need to be honest: do we have the engineering bandwidth and expertise? Or are we going to hire for it?

The companies that successfully built custom ERPs had either:

• A strong internal engineering team that already understood domain-specific software
• A partnership with an experienced consulting firm
• Both

Companies that tried to build ERPs with web app engineers and no domain expertise failed. Every time.

Question Six: What's Your Risk Tolerance?

Building is riskier. You could get it wrong. You could spend two years and launch something that doesn't solve the problem.

Buying is lower risk. The vendor's already built ERPs. There are reference customers. But you have adoption risk—your people have to adapt to the system's workflow, not the system adapting to yours.

Some companies are comfortable with build risk. They're startup-like. Failure is acceptable.

Some companies need stability. They can't tolerate build risk.

This is where I tell people: if you need a working ERP and you're risk-averse, buy. If you're comfortable with risk and you're willing to invest, building is possible.

The Framework In Practice

Let me map this to some examples.

Fast-growing B2B SaaS with standard ops: Standard problem, not strategic, short timeline needed, low depth, good engineering team, low risk tolerance. Buy. Use NetSuite or Stripe Billing. Move on.

Complex manufacturer with unique workflows: Unique problem, strategic, longer timeline acceptable, high depth, might have engineering depth, medium risk tolerance. Probably build. Or build a custom module on top of a standard system.

Mid-market retailer: Standard problem, not strategic, normal timeline, medium depth, probably no deep engineering, risk-averse. Buy. Shopify, Salesforce, whatever fits your industry.

Biotech with complex regulatory needs: Standard problem (pharma is standard), somewhat strategic (compliance is an edge), urgent timeline, high depth. Buy a specialized pharma ERP. Don't build. The vendors have invested.

Private equity firm with unique portfolio management needs: Unique problem, strategic, timeline negotiable, high depth, probably have smart people, some risk tolerance. This is a build case. No standard system models this.

The Real Question

The real question underneath all of this: are you solving a problem or implementing a system?

If you're solving a problem—"we can't track our inventory"—buy an ERP that solves it. The system is a means to an end.

If you're implementing a system because it's the thing you're supposed to do, you'll be unhappy either way. You'll buy an ERP and hate it. Or build one and hate it because you didn't actually need it.

The winners are clear on what problem they're solving. Then they pick the vehicle (buy or build) that solves it.

In 2025, I'm seeing companies get smarter about this decision. Less "we need to implement an ERP because it's enterprise software" and more "we need to solve X problem and here's how we'll do it."

That clarity is what actually matters. The build vs. buy decision flows from that.

What I Predict

I think the build-your-own-ERP era is narrowing. The software is mature. The cost is clear. Most companies are better off buying.

But I think the "buy and customize" era is expanding. Buying a core system, then adding custom modules or integrations for the 20% of your operations that are truly unique. That's where I see the growth.

Neither pure build nor pure buy. Hybrid.

That's where your decision should land. Not "we'll build everything" or "we'll buy everything." We'll buy the 80% and build or integrate the 20%.

That's realistic. That works.