Custom ERP vs SAP: A Founder Perspective

I've watched this decision happen maybe fifteen times. A company gets to fifty million in revenue. They're outgrowing their internal systems. They have a choice: implement SAP (or NetSuite or Oracle), or build their own ERP.

This decision haunts me because I've seen both paths fail spectacularly. And I've seen both succeed. What determines the outcome isn't the choice itself. It's whether the company understands what they're really choosing.

The SAP Path

Let me start with the conventional wisdom. Every board member knows this one: implement a major ERP system. SAP, Oracle, NetSuite. These are battle-tested. They have decades of features. Thousands of customers. Proven implementations.

The sales pitch is: buy our system, follow our playbook, don't customize too much, and you'll have enterprise-grade financials, supply chain, and reporting in eighteen months.

The reality is more complicated.

First, implementing SAP costs more than anyone budgets for. The software license is the small part. Implementation is huge. You need to hire a Big Four consulting firm. They staff you with people who specialize in SAP. For a company your size, you're looking at five to ten million dollars in consulting fees. It's not optional. You can't just buy SAP and turn it on. You need to configure it, which means you need experts.

The timeline is also worse than the pitch. Eighteen months is optimistic for a company with a clean data environment and simple processes. Most companies have messy data. Most have weird custom processes that work but don't fit the SAP model. Now you're either fixing the business processes to fit SAP (which is hard and risky) or customizing SAP to fit your business (which is expensive and creates long-term technical debt).

I watched a manufacturing company implement SAP. They budgeted eight million. It ended up being fourteen million and took thirty months. By the time it went live, the business had changed so much that the system didn't solve their current problems. It just replaced their old problems with new, expensive ones.

But here's the thing: SAP also worked for them. After the nightmare, they had a system that scaled. They could add modules. They could integrate with suppliers. They had financial reporting that actually worked. Five years in, it was probably worth it.

The Build-Your-Own Path

The other path is building custom. A growing company says: our business is different. Off-the-shelf doesn't fit. Let's build our own system that's perfect for us.

I respect this instinct. And it's occasionally right. But it's right about thirty percent of the time.

Here's why building custom usually fails: it's not actually a one-time project. Building an ERP isn't like building a website. You don't build it and launch it. You build the core, launch it, and then spend the next decade maintaining and extending it.

Most companies don't understand this commitment. They think: we'll build it in two years, it'll cost two million, and we're done. The actual numbers are: you build the core in two years, it costs two million, and then you spend five hundred thousand a year for the next ten years maintaining it while you try to add features that your competitors have had the whole time.

I worked with a fintech company that decided to build a custom back office. They were right that they had specific needs. But they underestimated the scope. They built order management, GL, reconciliation—the basics. But then they realized they needed inventory management. They needed asset tracking. They needed depreciation modeling. They needed consolidated reporting. Every feature that SAP had out of the box, they had to build.

Five years in, they had spent fifteen million on development. They had a team of twelve engineers maintaining it. They weren't shipping new business features anymore. They were maintaining plumbing. And they were still behind on functionality compared to SAP.

When Each Path Actually Works

Building custom works when:

• Your business model is fundamentally different from what packaged systems support
• You have deep technical talent and you want to build this thing
• You're willing to accept that you're building infrastructure, not a business feature
• You can move fast enough that you're not playing catch-up forever

I've seen this work in companies that had really specific supply chain needs. A company that does made-to-order manufacturing with complex routing and planning. Off-the-shelf systems are built for batch processing. Custom made sense.

I've also seen it fail for companies in that exact category. The difference: the successful ones had a founder or CTO who understood that building an ERP is a multi-year commitment. They started the project knowing it would take ten years to get right. They staffed appropriately. They measured success differently.

SAP works when:

• Your business processes are reasonably close to the SAP model
• You're willing to fix your business to fit the system (or you accept some customization)
• You have the budget for implementation
• You view the system as strategic infrastructure, not a differentiator

SAP fails when you treat it like you can implement it quickly. SAP fails when you customize it too heavily. SAP fails when your business model is truly different and you're trying to force it into a round hole.

The Decision Framework

Here's how I think about it for a specific company:

First: how different are your business processes? If you're a manufacturer, can you live with SAP's manufacturing model? Most can. If you're a hedge fund, probably not. If you're somewhere in between, it's complicated.

Second: what's your tolerance for pain? SAP implementation is painful. Custom building is a different kind of pain—slower, more persistent, but you can control it better. Which pain can your organization absorb?

Third: what's your technical leadership situation? If you have strong engineering leadership and you want to own this infrastructure, custom might work. If you don't, SAP is safer. You're delegating the hard problems to experts.

Fourth: what's your timeline? If you need to be operational in eighteen months, SAP is your only realistic option. If you have three years, custom becomes more viable.

Fifth: do you have scale on your side? For small companies (under fifty million revenue), custom usually doesn't make sense. The burden of maintenance is too high. For large companies (over two billion), custom might make sense if you're truly unusual.

What I'd Choose

Full transparency: if I were starting a new company today, I'd use SAP or NetSuite. I'd accept that it's not perfect. I'd avoid heavy customization. I'd make my business fit the system rather than the system fit my business.

But I'd do this knowing that in five years, I might build custom infrastructure on top of it. Real-time analytics. Custom reporting. Custom workflows. I'd treat SAP as my financial backbone and build on top of it.

The companies that win aren't necessarily the ones that chose perfectly. They're the ones that chose consciously. They understood the cost of their choice. They staffed appropriately. They made trade-offs deliberately.

By 2022, I think the market will bifurcate further. The packaged ERP systems will get better at specific verticals. Custom ERPs will become more common for truly unusual businesses. And hybrid approaches—SAP for financials, custom for operations—will become the norm for midmarket.

The worst path is the one where you don't decide. You half-choose SAP and half-choose custom, customize it heavily, run out of money, and end up with something that serves nobody well. I've seen more of those than I've seen clear successes.

Choose. Then commit. That's what actually matters.