Building Your Own ERP with AI: Four Pitfalls That Nearly Sank My Project

The Dream That Wouldn't Die

I've wanted to build my own ERP for years. I studied computer science in college—operating systems, databases, software engineering—but after graduation, I barely wrote a line of code. The blueprint was all in my head, but my fingers froze at the keyboard. The idea stayed an idea.

Work pulled me deeper into the ERP world anyway. I joined digital transformation projects at large enterprises, then moved to a domestic ERP vendor, then to one of the Big Four accounting firms. I soaked up business processes, financial reconciliations, and the chaos of go-live. Slowly, a full ERP model crystallized in my mind: how transactions flow, how vouchers are generated, how the balance sheet ties out. I had the picture, but I couldn't make it real.

AI Finally Made It Possible

Then AI showed up. It handed me the ability to write code without being a coder. Now that system is in internal testing. Purchase, production, and sales documents automatically generate accounting entries. Those entries roll up into account balances, which then spit out a balance sheet and an income statement.

I abstracted the core modules into MCPs—each containing dozens of tools that map to ERP functions. Configure them into WorkBuddy, and I can just ask: "Check inventory for material X," or "Pull the latest P&L." No menus, no forms.

But this isn't a smooth-sailing success story. I hit four massive potholes, and each one nearly made me delete everything and start over. Here's what I learned, so you don't have to bleed the same way.

Pitfall #1: The Accounting Translation Layer

Early on, I obsessed over the UI—button placement, field dependencies. I thought that was the real craft. I was wrong. The real crux is how business documents become accounting language. A purchase receipt must record inventory and accounts payable. A production issue moves materials to work-in-progress. A sale confirms revenue and accounts receivable. Three actions, three sets of debit-credit logic.

My first version let each module generate its own vouchers. Each department did its own math. It collapsed fast. Account balances didn't tie out. Purchasing said payables were X; finance said they were Y. Everyone was sure they were right.

I restructured: modules no longer generate vouchers. They emit business events. A single, centralized voucher engine translates those events. Each document type has a mapping rule. Purchase receipt comes in, the engine credits inventory and debits payables. Sale confirmed, it generates revenue and receivables. All vouchers write to one account balance table. The balance sheet and income statement are just read-only projections of that table.

The essence of integrated business and finance isn't bolting modules together. It's a translation pipeline from business actions to accounting language. The rules must be centralized and configurable, not scattered across modules. Once that's in place, adding a new module is just plugging in a mapping. No more begging finance to reconcile for you.

Pitfall #2: Model Hopping Chaos

The code was AI-written, but I made a rookie mistake early on. I let different models handle different modules, thinking I'd get the best of each. Model A wrote the purchasing module, Model B wrote production. The interface styles clashed—naming, structure, error handling were all different. Fixing A broke B; fixing B broke A. Bugs outnumbered features.

Worse was letting different models take turns editing the same logic. The context from the previous model was lost, so the next one rewrote things its own way, and the logic got mangled. Each snippet looked fine in isolation, but together they fell apart. Debugging was torture because nothing was obviously wrong.

After testing several, I settled on GLM5.2 for the entire project. One model from start to finish. Style stayed consistent. I could predict where things connected. When something was messy, it was the same model's thinking, so I could pick up the thread.

Lesson: when you're solo with AI, don't get greedy. One model that works beats three "smart" ones combined. If I'd learned this six months earlier, I'd have saved tens of thousands of lines of deleted code.

Pitfall #3: Version Control Discipline

In the beginning, I didn't use Git properly. I saved files with dates and names like "final," "final2," "real_final," "real_final_do_not_touch." Then a big refactor broke the core voucher engine, and I tried to roll back. No clean version existed. I had to rewrite everything.

That happened more than once. Each rewrite wiped out days of work and crushed my motivation. By the second rewrite, I was questioning whether this project was even possible. Plus, it burned tokens.

Finally, I got serious with Git. Each phase got a branch. The main branch only received tested code. Feature branches were for experimentation—if I broke something, I could switch back in ten minutes. I also made a habit: before quitting for the day, push stable work to main. Leave unstable stuff on the branch overnight.

Without version discipline, a solo project is like coding on a cliff edge. You think you're saving time, but you're one misstep away from losing everything. When you're alone, there's no one to catch you. A crash is a real crash.

Pitfall #4: The MCP Trap

Once the system ran, I hit the MCP conversion. Traditional ERP is menu-and-form heavy. I found that clunky, so I wrapped purchase, production, sales, and finance into MCPs. Each MCP has dozens of tools, each tool maps to a function. Query inventory, create a PO, pull a P&L—each action is a separate tool. Connect them to WorkBuddy, and you just say "check stock for material X," and it runs.

Tool granularity was a balancing act. Too coarse, and a single tool does ten things, confusing the intent. Too fine, and you get dozens of look-alike tools that confuse the caller. I settled on one tool per business action, with plain names.

But the sneaky trap was elsewhere. I'd put some calculation logic in the frontend—subtotals, taxes, document summaries. It worked fine in the UI because the frontend executed it. But conversational calls don't run frontend code. They just pass parameters and get results. So the numbers came out wrong. Vouchers didn't match. Reports didn't tie.

That bug was the hardest to find. The UI looked perfect. Clicking a document showed correct numbers. Only the conversational path was off. I stared at the same transaction, compared the UI and the chat output, and they disagreed. I was baffled.

I did a full interface upgrade. All business calculations, no matter how small, moved into the backend. Both the frontend and the conversation layer only pass parameters and display results—they never touch math. I also added a double-check: the same number gets computed two ways in the backend, and if they differ, it's blocked from entering the voucher. A double safety net.

After that, data finally stabilized. The numbers from chat, from the UI, and from the reports finally matched.

The MCP interface must be fully backend-driven. Any calculation done in the frontend evaporates when called conversationally. Every computation in the interface has to survive being called directly, because a conversation won't fill in missing frontend logic. Ironically, this forced me to make the interfaces cleaner—an unexpected bonus.

The Real Lesson

AI loosens the coding reins, but it doesn't loosen the reins on thinking through the business. A lot of people expect AI to design the system for them. It only writes the code. The thinking part is still yours. That gap is where the potholes live.

None of these four pitfalls was a one-time fix. Every redo cost time, morale, and moments of staring at the screen wondering if I was an idiot.

AI gives you muscle, not judgment. It didn't make development easier—it made it possible for one person to carry the weight of enterprise software. But you have to make every call yourself, and there's no one to hit the brakes for you.

The dream I'd carried for years is now running in internal tests. It's not perfect. Modules need polish, reports need tuning, and the chat sometimes mishears me. But it actually generates a balance sheet on its own. That's enough.