From ERP Dream to AI Reality: Four Time-Saving Lessons Learned

The Dream That Wouldn't Compile

For years, I'd carried the same thought around like a half-read book: I wanted to build my own ERP. I'd studied computer science, knew databases and software engineering cold. But after graduation, I never really wrote code. The blueprint lived in my head—how orders flow, how vouchers get created, how the numbers finally tie out. Yet my fingers froze at the keyboard. The model was clear, but it was just a model.

Then AI showed up, and the dream became a downloadable project. Now that system is in internal testing. Purchase, production, and sales documents auto-generate accounting entries. Those entries roll into account balances, and the balances spit out a balance sheet and income statement. Best of all, I've wrapped core modules into MCPs—dozens of tools each—and plugged them into WorkBuddy. Ask in chat to check inventory or open a purchase order, and it just happens.

But this isn't a smooth-sailing story. I hit four major time sinks that nearly made me delete everything and start over. If you're building something similar, learn from my bruises.

Pitfall One: Designing UI Before Data Flow

My first instinct was to obsess over interfaces. Button placements, field linkages—I thought that was the real craft. Turns out, it's the last thing that matters.

The real core is how business documents become accounting language. A purchase receipt needs to record inventory and accounts payable. Production material issues transfer raw materials to work-in-progress. Sales recognition brings in revenue and receivables. Three actions, three sets of debits and credits.

In my early version, each module generated its own vouchers. Each business unit did its own math. It collapsed fast. Account balances disagreed. Purchasing said payables were one number; finance said another. Everyone was sure they were right.

So I redrew the architecture. Modules no longer create vouchers—they just emit business events. A central voucher engine translates them. Each document type carries a mapping rule: a purchase receipt triggers debit inventory, credit payables. A sales confirmation pulls revenue and receivables. All vouchers write to one account balance table, and the balance sheet and income statement are just read-only projections of that table.

The lesson? Business-accounting integration isn't about gluing modules together. It's a translation pipeline from action to accounting language. Keep that pipeline centralized and configurable. Later, when you add a new module, just attach a mapping—no more begging finance to reconcile.

Pitfall Two: Letting AI Models Fight Each Other

The code was AI-written, but I made a rookie mistake early on. I used different models for different modules, thinking each would shine where it was strong. Model A wrote the purchase module, Model B wrote sales. The result? Inconsistent interfaces, mismatched naming, and error handling that spoke two dialects. Fixing A broke B; fixing B broke A. Bugs multiplied faster than features.

Even sneakier was having multiple models rewrite the same logic. One model's context didn't carry over. The next model reimagined the code from scratch, and logic got tangled. Each snippet looked fine alone, but together they ran like a car with two steering wheels.

After testing several, I settled on GLM5.2. One model, from start to finish. Now the style is consistent, and when I need to trace a bug, I know the thought process behind every line. If something's off, the same model's logic can pick up where it left off.

My takeaway: when you're solo with AI, resist the temptation to mix models. One model that's "good enough" beats three that can't agree. I could have saved myself tens of thousands of lines of rewrites if I'd learned this six months earlier.

Pitfall Three: Version Control? What Version Control?

In the first chaotic weeks, I didn't use Git properly—or at all. My files lived in folders named "final," "final2," "true_final," "true_final_dont_touch." Then one big refactor broke the voucher engine's core logic. I tried to roll back. There was no clean version. I had to rewrite it from scratch.

That happened more than once. Each rewrite burned two or three days of progress, plus more tokens than I want to admit. And it wasn't just the time; it was the morale. By the second rewrite, I started doubting the whole project was even possible.

Finally, I set up Git properly. A main branch for verified code only. Feature branches where I could break anything and revert in ten minutes. And a nightly habit: commit the day's stable work to main, leave the shaky stuff on a branch overnight.

If you're building alone, version discipline isn't optional. It's your safety net. Without it, you're coding on a cliff edge—one wrong keystroke and your entire history vanishes.

Pitfall Four: The MCP Trap Nobody Warned You About

Once the system ran, I got ambitious. Traditional ERPs are all menus and forms—slow and clunky. I wrapped purchase, production, sales, and finance into MCPs, each with dozens of tools. Want inventory? Ask chat. It calls the tool. No interface needed.

But I learned the hard way that tool granularity matters. Too coarse, and one tool does ten things, confusing the conversation parser. Too fine, and you get fifty nearly identical tools. I settled on one action per tool, with plain names that make the intent obvious.

The real trap, though, was hidden in the calculations. In the early version, I left some logic at the interface layer—subtotals, tax, invoice summaries—computed in the front-end. It worked fine in the UI, because the front-end always ran those calculations. But conversational calls don't. They just pass parameters and return results. So the numbers came out wrong. Vouchers didn't match. The report didn't tie to the business.

This was the hardest bug to find. In the UI, everything looked perfect. Click a document, the numbers were right. Only when I queried via chat did the numbers diverge. I stared at the same transaction—UI said one thing, chat said another—and felt my brain short-circuit.

So I refactored. Every calculation, no matter how tiny, moved into the back-end. Both the UI and the chat layer only pass parameters and display results. I added a double-check: the same number gets computed via two separate paths, and if they disagree, the system blocks it from entering the voucher pool. That's my insurance policy.

Now the numbers match everywhere—chat, UI, reports. The MCP interface is fully back-end, and the chat layer can't skip any logic. Ironically, conversational access forced me to make the interfaces cleaner than they ever were.

What I'd Tell My Past Self

AI loosened the reins on coding, but it didn't loosen the reins on thinking. A lot of people assume AI can design the system for them. It can't. It writes the code; you still have to think through the business. That gap is where all the pitfalls live.

None of these four traps cost me just one attempt. Each one hit me with time, frustration, and those 2 a.m. sessions questioning my own judgment. But here's the thing: AI gives you the muscle, not the brain. It doesn't make development easier—it makes it possible for one person to carry a project that used to need a team. The price is that you make every call yourself. No one's there to hit the brakes.

The system is still in testing. It's not perfect. Modules need polish, reports need tuning, and sometimes chat misunderstands me. But it actually generates a balance sheet on its own. And that dream I carried for years? It's running.

The Time-Saving Checklist

• Design the data flow and accounting logic before touching the UI.
• Stick to one AI model for the whole project—consistency beats variety.
• Use Git from day one. Commit daily. Branch liberally.
• Keep all business calculations server-side. The chat layer can't be trusted with math.
• Expect to redo things. The second attempt is always better.