Building My Own ERP with AI: Lessons from a Distance Learner's Journey

The Dream That Wouldn't Die

For years, I'd wanted to build my own ERP system. Not just any ERP—one tailored to my understanding of business processes, one that would finally make sense of the tangled web of procurement, production, and sales. But there was a catch: I couldn't code. I'd studied computer science in college, but after graduation, I'd never really written a line of production code.

My career had taken me deep into the ERP world—first as a consultant on large enterprise digitalization projects, then at a domestic ERP vendor, and later at a Big Four accounting firm. Along the way, I absorbed how business flows, how financial vouchers are generated, and the chaos that precedes any go-live. In my head, a complete ERP model took shape. I could see the data flow, the journal entries, the balance sheet. But without coding skills, it was all just a mental blueprint.

Then AI arrived. Suddenly, the dream was within reach. I could describe what I wanted, and the AI would write the code. It felt like a miracle. But as with any miracle, there were strings attached—and pitfalls.

Pitfall #1: Diving into UI Before the Core Logic

My first mistake was spending too much time on the interface. I obsessed over button placement and field dependencies, thinking that was the real craftsmanship. It wasn't until I started writing the actual logic that I realized the true core: translating business transactions into accounting entries.

Procurement receipts need to record inventory and accounts payable. Production material issues move costs into work-in-progress. Sales confirmations trigger revenue and receivables. Each action has its own debit-credit logic. In my first version, each module generated its own vouchers. It was a disaster. Balances didn't match. Procurement said payables were one number, finance said another—and everyone was sure they were right.

I restructured. Now, modules don't generate vouchers at all. They emit business events, and a centralized voucher engine translates those events into accounting entries. Each document type has a mapping rule. When a purchase receipt comes in, the engine debits inventory and credits payables. When a sale is confirmed, it credits revenue and debits receivables. All vouchers flow into a single ledger 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 pipeline from business action to accounting language—and the translation rules must be centralized and configurable, not scattered across modules.

Pitfall #2: Mixing AI Models

Once the architecture was solid, I hit the next wall: model selection. In the beginning, I used different AI models for different modules—Model A for one, Model B for another—thinking I'd get the best of each. It was a nightmare. Their coding styles clashed: different naming conventions, different error handling, different structural choices. Fixing something in Module A would break Module B, and vice versa. Bugs multiplied faster than features.

Even worse was having different models take turns editing the same logic. The second model didn't understand the first one's context, so it rewrote things its own way, creating logical inconsistencies. Each snippet looked fine in isolation, but together they wouldn't run. Debugging was a special kind of hell.

I eventually settled on a single model—GLM5.2—and used it for the entire project. Code style became consistent. I could predict how it would handle a new function. When things got tangled, it was still the same model's thinking, so I could follow the thread. My advice: when working solo with AI, resist the urge to mix models. One good model is better than three clever ones.

Pitfall #3: Neglecting Version Control

In those early days, I didn't use Git properly. I saved files with names like 'final', 'final2', 'real_final', 'real_final_no_really'. Then came a major refactor that broke the core voucher engine. I wanted to roll back, but there was no clean version. I had to rewrite everything from scratch.

That happened more than once. Each rewrite cost me two or three days of progress—and more importantly, my morale. By the second rewrite, I was questioning whether the project was even possible. Plus, it burned through tokens.

Eventually, I got serious about Git. I created a branch for each phase, kept the main branch for tested code, and used feature branches for experiments. If something broke, I could revert in ten minutes. I also made it a habit to merge stable work into main before quitting for the day, leaving unstable stuff on a branch overnight.

Version control isn't optional, even for a solo project. Without it, you're coding on a cliff edge. One wrong move and everything collapses.

Pitfall #4: MCP-ing Without Backend Discipline

Once the system could actually run, I hit the most insidious trap: MCP integration. Traditional ERPs rely on menus and forms—click, click, click. I found that slow and clunky. So I wrapped core modules—procurement, production, sales, finance—into MCPs, each with dozens of tools that map to backend functions. Integrated with WorkBuddy, I could just say, 'Check stock for material X,' and the tool would fire, no UI needed.

Tool granularity was a learning curve. Too coarse, and a tool does ten things, confusing the intent. Too fine, and dozens of tools look alike, confusing the caller. I settled on one tool per business action, with clear names.

But the real trap was this: I'd put some calculation logic on the frontend—amount subtotals, tax calculations, document summaries. In the UI, it worked fine. But when called via conversation, the frontend layer never executed. The conversation layer just passed parameters and got results. So the data came out wrong. Voucher amounts didn't match. Reports disagreed with the business.

This bug was the hardest to find. The UI looked perfect. The numbers were right when I clicked through. Only the conversation-path data was off. I stared at the same transaction, comparing UI and chat, and they showed different numbers. I was baffled.

The fix was a full API upgrade. All business calculations—no matter how trivial—moved into the backend. The frontend and conversation layer only pass parameters and display results; they don't do math. I also added a double-check: the same number is calculated twice via two different paths in the backend, and if they disagree, the transaction is blocked from entering the ledger. It's a safety net for the data.

After that, the numbers finally stabilized. What you see in the chat, in the UI, and in the reports—they're all the same.

What AI Does and Doesn't Do

Going through this, I've realized something: AI loosens the reins on coding, but it doesn't loosen the reins on thinking clearly about the business. A lot of people think AI can figure out the system for them. It can't. It only writes the code. The thinking—the architecture, the rules, the edge cases—that's still yours.

That gap is where the pitfalls live. Every one of the four I hit came with a cost: time, morale, and those moments of staring at the screen, doubting myself. But I'd do it again. AI gave me the muscle; I had to supply the judgment. It didn't make development easier. It just made it possible for one person to handle enterprise-scale software. The price is that you have to make every decision yourself, with no one to hit the brakes.

That dream I'd carried for years is now running in internal testing. It's not perfect—modules need polish, reports need tuning, and the conversation layer occasionally mishears me. But it actually generates its own balance sheet. And that feels like magic.