What We Learned Building Our First Custom ERP

Three months after launching our first custom ERP system for a mid-market manufacturer, I sat in their conference room listening to the production manager detail all the ways our system wasn't quite right. We had built exactly what they asked for. And it was still wrong.

Not dangerously wrong. The system worked. They could process orders, manage inventory, track costs. But there was friction everywhere. Screens required six clicks to accomplish what used to take two. Reports exported to PDF instead of the Excel format they'd been using for seven years. The data model didn't quite match how they actually thought about their business.

The honest realization was this: we had listened too well to their current process instead of actually challenging it.

The Gap Between Stated and Actual Requirements

When we started, the CTO gave us a 60-page requirements document. It was detailed and professional and completely missed the point. The document described the process as they thought it worked, not as it actually worked. The warehouse manager cut corners we didn't know about. The accounting team had workarounds for scenarios the old system couldn't handle. The sales team tracked customer commitments in a separate spreadsheet because the official system didn't let them.

We implemented the 60-page document to the letter. That was our first mistake.

What we should have done—and do now—is spend two weeks embedded in their actual workflows. Watch how people actually work. Find the shortcuts they've invented. Understand why they exist. Most process inefficiency exists because the system forced someone into an unnatural path, and they solved it with a workaround. A good ERP doesn't eliminate workarounds; it understands them and rebuilds the system around the reality.

The second mistake was thinking we could build something that matched 90% of their workflow and they'd be happy. You can't be 90% right in ERP work. Mismatches accumulate. A slightly wrong workflow creates data inconsistency, which breaks reporting, which means nobody trusts the dashboards. Within six months, people are printing reports and re-entering data into spreadsheets.

What Actually Went Right

For all the friction points, the project taught me what makes custom ERP worth doing. There were three areas where we absolutely crushed it relative to what they'd been doing:

First, the cost allocation system. We designed it specifically around their manufacturing process—multiple factories, different overhead structures, custom allocation rules. Their previous system couldn't even model this. That one feature alone gave them visibility into profitability they'd never had before.

Second, the API layer. We built the system to expose everything through clean APIs, so connecting it to other systems—their warehouse management system, their customer portal, third-party analytics tools—was straightforward. That flexibility prevented the "locked into one system" feeling.

Third, the mobile ordering interface. This seemed minor until we realized the sales team spent 40% of their time creating orders in the office and another 40% going back and forth with customers on changes. A simple mobile interface cut that cycle time dramatically.

What we'd do differently next time: less emphasis on matching legacy process exactly, more on understanding the underlying business problem each process solves. Spend more time in what we now call "discovery friction," where we deliberately challenge assumptions and watch how people actually work. And build incrementally with their real data instead of test data, so mismatches surface fast.

By May, after adjustments, the system was genuinely excellent. By July, they'd eliminated two part-time people whose entire job was workarounds. It was worth doing right, but the path to right is messier than any requirements document suggests.