From ERP Dream to AI Reality: Lessons from Building with WorkBuddy

The Dream That Wouldn't Code

For years, I carried a vision of building my own ERP system. I studied computer science—operating systems, databases, software engineering—but after graduation, I never really wrote code. The blueprint was in my head, but my fingers froze at the keyboard. The dream stayed a dream.

Then I got tangled up with ERPs professionally. I worked on digitalization projects for large companies, joined a domestic ERP vendor, and later moved to a Big Four accounting firm. Through those years, I absorbed how business processes flow, how vouchers are generated, and the chaos that precedes a go-live. Slowly, a complete ERP model took shape in my mind. I knew how transactions should move and how accounting entries should be born. But knowing isn't doing. Without coding skills, a model is just a model.

AI changed that. Now my system is in internal testing. Purchase, production, and sales documents automatically generate accounting vouchers, which roll up into account balances, which produce balance sheets and income statements. I've even abstracted core modules into MCPs—each with dozens of tools—so I can chat with WorkBuddy to check inventory, create purchase orders, or pull a profit report.

This isn't a smooth-sailing story. I hit four major pitfalls, each demanding a rewrite. Here's what I learned, so you can avoid the same detours.

Pitfall 1: Building the UI Before the Logic

Early on, I obsessed over interfaces. Button placement, field linkages—I thought that was the real craft. But as I dug deeper, I realized it was secondary. The true core is how business documents become accounting language. A purchase receipt must record inventory and accounts payable; production material issues transfer costs to work-in-progress; sales confirmations trigger revenue and receivables. Three business actions, three sets of debits and credits.

My first version had each module generate its own vouchers. Each business unit computed its own numbers. It collapsed quickly. Account balances didn't match. Purchasing said payables were one figure, finance said another, and everyone was sure they were right.

So I restructured. Modules stopped generating vouchers and instead emitted business events. A centralized voucher engine translated those events. Each document type got a mapping rule: purchase receipt in, the engine debits inventory and credits payables. Sales confirmation, it creates revenue and receivables. All vouchers feed one ledger 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 stitching modules together; it's a translation pipeline from business actions to accounting entries. The rules must be centralized and configurable, not scattered across modules. Once I had that, adding new modules was just a matter of hanging a new mapping onto the engine—no more begging finance to reconcile.

Pitfall 2: Model Hopscotch

The code was written by AI, but I made a rookie mistake: I used different AI models for different modules, thinking each would play to its strengths. The result was chaos. Model A's interfaces didn't match Model B's style—naming, structure, error handling—all different. Fixing A broke B, and fixing B broke A. Bugs multiplied faster than features.

Even worse was having different models rewrite the same logic sequentially. The second model couldn't grasp the first's context, so it rewrote everything its own way, mangling the logic. Each snippet looked fine in isolation, but the whole didn't run. Debugging was torture because every piece seemed correct.

After testing several, I settled on GLM5.2. From then on, one model generated the entire project. Style unified, and changes felt predictable. When something got tangled, the same model could pick up the thread. Looking back, the biggest lesson: don't be greedy. One model that works beats three clever ones. If I'd learned that six months earlier, I'd have saved tens of thousands of lines of code.

Pitfall 3: Version Control Neglect

For the first few weeks, I didn't use Git properly—or at all. I named files by date and dumped them in folders: final, final2, real_final, real_final_NO_EDIT. Then a major refactor broke the voucher engine's core logic, and I had no clean version to roll back to. I had to rewrite everything from scratch.

That happened more than once. Each rewrite cost days of work and, worse, my morale. By the second rewrite, I started doubting whether the project was even possible. And the token costs added up.

Finally, I adopted Git religiously. Each phase got its own branch; the master branch only held tested code. Feature branches were for experimentation, and if something broke, I could switch back in ten minutes. I also made it a habit to merge stable work into master before ending the day, leaving unfinished bits on branches overnight.

Version discipline isn't optional for solo projects. Without it, you're coding on a cliff edge—you think you're saving time, but you're one step from losing everything. When you're alone, there's no one to back you up.

Pitfall 4: The MCP Integration Trap

Once the system ran, I moved to MCP-izing it. Traditional ERPs rely on menus and forms—click, click, click. I found that clunky and slow. So I wrapped my purchase, production, sales, and finance modules into MCPs, each exposing dozens of tools that map to backend functions. From checking stock to creating a purchase order to generating a profit report, every action became a discrete tool. In WorkBuddy, I could just say, "Check how much of material X is left," and the tool would fire—no UI needed.

Tool granularity took trial and error. Too coarse, and one tool does ten things, making intent ambiguous. Too fine, and dozens of similar tools confuse the caller. I settled on business actions: one action, one tool, with direct names.

But here's the sneaky part. Initially, I put some calculations outside the backend—like subtotals, taxes, and document summaries—in the frontend, thinking it was convenient. It worked fine in the UI because the frontend executed the logic. But with conversational calls, the dialogue layer only passes parameters and fetches results—it doesn't run frontend calculations. So data got miscomputed, vouchers didn't match, and reports disagreed with transactions.

This was the hardest bug to find. Everything looked fine in the UI; numbers were correct when I clicked through. Only the conversational output was wrong. I'd pull up the same transaction, check it in the UI, then ask the chat, and get two different figures. I stared at the screen in disbelief.

The fix was a full API upgrade. Every calculation, no matter how trivial, moved into the backend. Both the frontend and the dialogue layer only passed parameters and displayed results—nothing more. I also added a double-check: the same number is computed twice via two paths, and if they don't match, it's blocked from entering the vouchers. That's my safety net.

After that, data finally stabilized. The numbers you get from chat, the numbers you see in the UI, and the numbers in the reports are all the same. MCP interfaces must be fully backend-driven. If the frontend does the math, a conversational call will silently drop it. Every calculation in an interface must survive being called directly by a dialogue, because the dialogue won't compensate for missing frontend logic. Ironically, this forced me to design cleaner APIs—a welcome side effect.

The Real Lesson

After this journey, I've concluded: AI loosens the reins on coding, not on business thinking. Many people think AI can think through the system for them. But AI only writes the system; the thinking is still yours. That gap is where the pitfalls live.

None of these four pitfalls did I overcome in one try. Each reset cost time, morale, and hours staring at the screen doubting myself. AI gives you raw muscle, but judgment is still on you. It doesn't make development easier; it just lets one person handle the scale of enterprise software. The price is that you make every call alone, with no one to hit the brakes.

My multi-year dream is now running in internal testing. It's not perfect—modules need polish, reports need tuning, and the chat occasionally mishears me. But it actually generates a balance sheet on its own. And that's more than a dream; it's a system that works.