Chasing the ERP Dream: How AI Built It and Free Living Made It Real

For years, I wanted to build my own ERP system. I studied computer science in college—operating systems, databases, software engineering—but after graduation, I never really wrote code. The blueprint was in my head, but I couldn't type a single line. The dream stayed a dream.

Work pulled me deeper into the ERP world anyway. I joined digital transformation projects at large enterprises, then worked at a domestic ERP company, then moved to a Big Four accounting firm. Through those years, I absorbed how business processes flow, how accounting entries are generated, and what a mess go-live can be. Slowly, a complete ERP model took shape in my mind—how transactions should move, how vouchers should be created. I had the picture. But without coding ability, the picture was just a picture.

Then AI arrived, and the dream became real. Now that system is in internal testing. Purchase, production, and sales documents automatically generate accounting vouchers, which roll into account balances, which produce a balance sheet and income statement. Even better, I abstracted the core modules into MCPs—each with dozens of tools that map to ERP functions. Hook them into WorkBuddy, and I can ask in plain language: “Check inventory for this material,” or “Create a purchase order,” or “Pull the profit statement.”

This isn't a smooth-sailing story. I hit four major pitfalls, and each one cost me time, sanity, and sometimes the urge to delete everything and start over. Here's what I learned, so maybe you can skip a few bruises.

Pitfall One: The Interface Trap

When I started, I poured most of my energy into the UI—button placement, field interactions, that kind of thing. I thought that was the real craft. Turns out, it's secondary.

The real heart of an ERP is turning business documents into accounting language. A purchase receipt means inventory and accounts payable. A production issue moves materials to work-in-progress. A sale confirms revenue and accounts receivable. Three business actions, three sets of debit-credit logic.

My first version had each module generating its own vouchers. Each module did its own math. It collapsed fast. Account balances didn't match. Purchasing said payables were one number; finance said another. Everyone was sure they were right.

So I restructured. No module generates vouchers anymore. Instead, they emit business events, and a central voucher engine translates them. Each document type has a mapping rule set. When a purchase receipt comes in, the engine debits inventory and credits accounts payable. When a sale is confirmed, it books revenue and receivables. All vouchers write to the same account balance table, and 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. Centralize those rules, make them configurable, and don't let modules invent their own.

Once I had that, adding new modules became easy: just hang a new mapping on the engine, and vouchers appear without begging finance to reconcile.

Pitfall Two: The Temptation of Multiple AI Models

The code was written by AI, but I made a classic mistake early on: I used different models for different modules, thinking I'd get the best of each. Model A for one module, Model B for another. It was a disaster.

The interfaces didn't match. Naming conventions, structure, error handling—all different. Fixing A broke B; fixing B brought back A's errors. The codebase became a patchwork of bugs.

Worse was having different models take turns editing the same logic. The second model didn't have the context from the first, so it rewrote things its own way, and the logic got tangled. Each snippet looked fine in isolation, but the whole thing wouldn't run. Debugging was a nightmare because every piece seemed correct on its own.

After experimenting, I settled on one model—GLM5.2—for the entire project. One model, consistent style, predictable behavior. When something breaks, I can trace the logic because it's the same thinking pattern throughout.

My advice: when you're building something solo with AI, resist the urge to mix models. One good model is worth more than three clever ones. If I'd learned that six months earlier, I'd have saved tens of thousands of lines of code.

Pitfall Three: Version Control Chaos

In the beginning, I didn't use Git properly. I saved files with names like final_v2, real_final, real_final_no_edit. Then a big refactor broke the core voucher engine logic, and I couldn't roll back. No clean version existed. I had to rewrite it from scratch.

That happened more than once. Each rewrite cost days of work, but worse, it drained my motivation. By the second rewrite, I started doubting whether this project was even possible.

Finally, I committed to Git. I created a branch for each phase, kept the main branch clean with only verified code, and used feature branches for experiments. If something broke, I could revert in ten minutes. I also made a habit: before ending the day, merge the stable work into main; leave unstable stuff on the branch overnight.

Working without version control on a personal project is like coding on a cliff edge. You think you're saving time, but one wrong move can wipe out everything. Solo developers need discipline even more—there's no one to save you.

Pitfall Four: The MCP Trap

Once the system ran, I wanted to make it conversational. Traditional ERP is all menus and forms—click, click, click. I abstracted purchasing, production, sales, and finance into MCPs, each with dozens of tools. Every action—check stock, create a purchase order, pull a profit statement—became an independent tool. Connected to WorkBuddy, I could just say, “Check how much of this material is left,” and the tool would fire.

Getting the tool granularity right took time. Too coarse, and a tool doing ten things confuses the dialogue. Too fine, and you have fifty similar-looking tools. I settled on one action per tool, named clearly, so the conversation layer could understand intent.

But the sneakiest bug was hidden in the API design. I had put some calculations—subtotals, tax amounts, document summaries—in the front-end layer, thinking it was convenient. In the UI, it worked fine. But when the dialogue layer called the same function, it only passed parameters and returned results—it didn't execute the front-end calculations. So the numbers came back wrong. Voucher amounts didn't match, and reports disagreed with business data.

This was the hardest bug to find. The UI showed correct numbers; only the dialogue showed wrong ones. I stared at the same transaction, checked the UI, then the dialogue, and they differed. I was baffled.

I upgraded the API: all business calculations, no matter how small, moved into the backend. Front-end and dialogue only pass parameters and display results. I also added a double-check: the same figure calculated through two separate paths in the backend must match, or the system rejects it and doesn't let it enter a voucher. That gave me a safety net.

After that, data finally became consistent. The numbers in dialogue, in the UI, and in reports were the same. The lesson: MCP interfaces must be fully backend-driven. Any calculation done in the front-end will evaporate when called through dialogue. Conversational design forced me to keep the API clean—an unexpected bonus.

What AI Really Gives You

Through this journey, I've realized: AI loosens the reins on writing code, but not on thinking through the business. Many people expect AI to design the system for them. It doesn't. AI writes the code, but the thinking—the architecture, the logic, the decisions—is still yours. That gap is where the pitfalls live.

None of these four traps were one-time lessons. Each cost me time, confidence, and nights staring at the screen wondering if I could do this.

In the end, AI provides the muscle, but the judgment is still human. It didn't make development easier—it just made it possible for one person to build something enterprise-grade. The burden is that you have to make every call yourself, with no one to hit the brakes.

That decade-old dream is now running in internal testing. It's not perfect—modules need polish, reports need tweaking, and the dialogue sometimes mishears me. But it's genuinely producing a balance sheet on its own. And that's more than I ever could have done alone.