Build or Buy Your ERP? You're Asking the Wrong Question

The question isn't really "build or buy."

The question is: What would it be worth to operate 10% faster than your competition?

Not 10% cheaper. Not 10% more features. Just 10% less time to deliver the same work, at the same quality, for the same price.

That gap compounds. Every project you finish faster frees capacity for the next one. Every quote you turn around in hours instead of days closes before the competitor's email arrives. Every process that runs without manual intervention is a process that scales without adding headcount.

Your competition has two choices: drop their prices (reducing profit and their ability to invest in improvement) or watch you pull ahead. Meanwhile, you're compounding that advantage every quarter.

This is what software is actually for. Not to check a box. Not to look professional. To create an operational edge that compounds over time.

The build-vs-buy question only matters once you understand what that edge looks like for your business—and whether the software you're considering will create it or destroy it.

---

The Hidden Cost of "Buying" Your Way to Average

Most off-the-shelf software is designed for the average company in your industry.

That's the point. Vendors need to sell to thousands of businesses, so they build for the middle of the bell curve. The features reflect what most companies need, configured the way most companies work.

If your competitive advantage comes from operating like everyone else, that's fine.

But if how you work is why customers choose you—if your process, your responsiveness, your specific way of handling edge cases is the thing that wins deals—then "industry standard" software is a trap. You're not buying efficiency. You're buying conformity.

I learned this the hard way, running a service organization years ago.

Our first customer service platform was "industry-specific," which sounds like a selling point until you live with it. The software was so painful that techs wouldn't enter their time. They wouldn't document their work. They definitely wouldn't record solutions for the next tech. Basic operational hygiene had become a chore nobody wanted to do.

We switched to a generic platform. Nothing fancy—just software that didn't fight us. Productivity jumped 30%. (That number is easy to measure in a service org: tickets per tech.) We adjusted it to fit our style, people actually used it, and we moved on.

Then we made a mistake.

The logic seemed airtight: if generic software gave us 30%, imagine what real industry-specific software could do. The leading platform had all the features. It would teach us best practices. We'd become better at our jobs just by using it.

Productivity dropped 10%.

The software didn't match how we worked. The "best practices" it enforced weren't better than what we'd already figured out. Features we didn't need cluttered every screen. People found workarounds—which meant we were back to undocumented processes and tribal knowledge, just with a fancier logo on the login page.

We didn't learn anything from the software. What we did learn—painfully, expensively—was what we actually needed. That discovery process turned out to be more valuable than any feature list.

The company eventually built what it should have built from the start. It's still running, opening new offices. But we took the long way around.

---

The Formula Is Simple (The Execution Isn't)

Here's the entire build-vs-buy decision in one sentence:

You build if the return is worth the cost.

Same math you'd use for any business decision. Same logic you'd apply to a new hire, a piece of equipment, or a marketing campaign. Will the result generate more value than the investment?

The problem is that people dramatically underestimate the costs on both sides.

The hidden cost of "buy" is forcing your business to adapt to software instead of software adapting to your business. You lose the workflows that differentiate you. You inherit someone else's assumptions. You spend years fighting the tool instead of using it—and your "competitive advantage" slowly erodes toward the industry average.

The hidden cost of "build" is the human work: explaining what you actually need to developers, and then getting your own employees to adopt the change. This part is daunting. Most people underestimate it by a factor of three or four.

But here's what tips the math toward "build" more often than people expect:

Even a few percentage points of operational efficiency, applied consistently, creates security and adaptability. The businesses that survive disruption aren't the ones with the most features. They're the ones whose operations actually fit how they work—and can change when the market changes.

Software that forces you into a fixed mold is a liability when conditions shift. Software that matches your reality is an asset you can evolve.

---

Buy First, Build Second (How It Actually Happens)

Most companies that end up building custom software didn't start there. They started by buying—and the buying process taught them what they actually needed.

A 50-year-old precision manufacturer came to us running software from the 1980s. Only a couple of people in the country still understood how it worked. Training new staff felt like teaching a dead language.

They'd tried buying replacements. The off-the-shelf options either couldn't handle their specific workflows or came with so much enterprise overhead that a 15-person shop would drown in configuration. The speed and precision that made them competitive—their edge—couldn't survive the transition to "industry standard."

What they learned from trying to buy was exactly what they needed to build: a system designed around how they actually worked, not a digital recreation of someone else's assumptions. The new system cut admin time, made remote work possible for the first time, and let them onboard new people without a months-long apprenticeship in legacy quirks.

A 100+ person case management company went even further down the "buy" path. They did everything the consultants recommend: enterprise CRM, custom development on top, the whole stack.

For a while, it worked. Then the bill came due. Licensing fees in the mid-six figures annually. Plugins and integrations adding tens of thousands more. And invoicing—the core of getting paid—took their finance team 120 hours every month. Nothing else got done during billing week.

They didn't rip out the enterprise system entirely. But they built a custom invoicing engine that took 120 hours down to about 15 minutes. They kept what the big platform was good at and took back control of the part that was strangling them.

Now they can handle 10–20% annual growth without adding headcount or burning out the finance team. That's not a software upgrade. That's a structural advantage.

The pattern is consistent: buying teaches you what you actually need. The discovery process—mapping real workflows, surfacing hidden costs, understanding where the friction lives—is valuable whether you end up building or not.

The mistake is skipping that discovery and assuming a product demo will answer questions only your own people can answer.

---

What "Build" Actually Looks Like

When people hear "custom software," they imagine a two-year death march with unclear requirements, blown budgets, and a coin-flip chance of getting something usable.

That's not how it has to work.

The core of a good build process is a weekly steering meeting—same time every week, all key stakeholders present. Decisions happen in real time. Issues get resolved before they metastasize. Nobody waits three weeks for an answer to a blocking question.

Start with data, not mockups. Migrate existing data into the new system first. Prototyping and testing happen with real information—your actual customers, orders, and problems—from day one. You're not evaluating an abstract concept; you're evaluating something that already contains your business.

The first month is intensive: initial data migration, identifying required screens and workflows, database design, and a working prototype with minimal features but real data. This requires the most time from the customer—several deep working sessions, often including a site visit.

After that, the weekly rhythm takes over. Development typically runs six to nine months. The transition date emerges as the system matures rather than being fixed upfront. Plan for three months post-release to handle the edge cases nobody anticipated until real users hit them.

At launch, daily Q&A calls—open to any employee—resolve issues quickly. Usually the calls die out after a few days because people don't need them anymore. If they don't die out, that's a signal something was missed, and you keep iterating.

By the end of the second week, the system should feel like furniture. Just how work happens now.

---

When "Buy" Actually Makes Sense

Not everything should be custom.

If you need accounting software, buy accounting software. If you need email, buy email. If there's a commodity tool that does exactly what you need without bending your business around it, buying is the obvious move.

Build when the process is your competitive advantage. Build when how you work is different from how competitors work—and that difference is why customers choose you. Build when forcing your workflows into someone else's template would cost you the thing that makes you win.

Buy when the process is a commodity. Buy when you don't care how it works, only that it works. Buy when "industry standard" is genuinely what you want to be.

The trap is assuming that "industry-specific" software will teach you to be better at your industry. In my experience, it almost never does. What changes behavior is the messy work of understanding how you operate today and deciding, consciously, what to keep and what to fix.

Software doesn't do that work. People do.

---

The Exercise That Makes the Decision Obvious

If you're genuinely weighing build vs. buy, here's something concrete you can do this week—no vendors, no consultants, no budget required.

Step 1: Pick your most important repeated process. Not the most complex. The most important. The one that directly touches revenue: quoting, fulfillment, invoicing, customer onboarding, whatever yours is.

Step 2: Shadow it end-to-end. Watch someone actually do it. Not the documented version—the real version. Note every system they touch, every copy-paste, every "I just check with Sarah on this part," every workaround they've invented.

Step 3: Time the human glue. Add up the minutes spent not on the work itself, but on moving information between systems, re-keying data, checking for errors introduced by manual steps, or waiting for answers from someone else.

Step 4: Multiply. How many times does this process run per week? Per month? What's the fully loaded cost of the people doing the glue work? What's the error rate, and what does a typical error cost to fix?

You'll end up with a number. Maybe it's $2,000 a month in hidden friction. Maybe it's $20,000. Maybe it's more.

Now ask: If software eliminated 80% of that, what would it be worth? And more importantly: Can any off-the-shelf product actually do that, or would it just move the friction somewhere else?

That question—grounded in your actual numbers, your actual process—is worth more than any feature comparison or vendor pitch. It's the difference between buying software because it seems like you should, and investing in a system because you know exactly what it needs to do.

The technology comes after. The clarity comes first.