I Built My Own ERP With AI, and Here Are the Potholes You'll Hit Too

It Started as a Pipe Dream

For years, I'd wanted my own ERP system. I studied computer science in college—databases, operating systems, software engineering—but after graduation, I barely wrote a line of code. The blueprint was always in my head: how orders flow, how vouchers post, how the balance sheet ties out. But without coding skills, that blueprint stayed a fantasy.

Then AI showed up. It didn't just hand me a finished product; it gave me the ability to build. A few months later, my system is in internal testing. Purchase orders, production runs, and sales invoices automatically generate accounting entries. Those entries roll into account balances, and those balances spit out a balance sheet and income statement. I even wrapped core modules into MCPs—each with dozens of tools—so I can chat with the system to check inventory or pull a profit report.

But this isn't a clean success story. I hit four major potholes, and each one cost me time, sanity, and sometimes entire weekends. Here's what I wish I'd known before I started.

Pothole #1: Business Events vs. Voucher Logic

My first mistake was obsessing over the user interface. I spent days arranging buttons and wiring up field dependencies, convinced that was the real work. It wasn't. The real heart of any ERP is how business documents turn into accounting language.

When a purchase receipt comes in, you need to debit inventory and credit accounts payable. When production picks materials, those move to work-in-progress. When you confirm a sale, revenue and receivables appear. Each action has its own debit-credit logic. In my first version, each module generated its own vouchers. That was a disaster. The account balances never matched—purchasing swore payables were one number, finance said another. Everyone was sure they were right.

So I restructured. Now, no module creates vouchers directly. They only emit business events. A central voucher engine translates those events into accounting entries based on configurable mapping rules. When a purchase receipt arrives, the engine debits inventory and credits payables automatically. Same for sales. All vouchers write to one account balance table, and the financial statements are just read-only projections of that table.

The lesson: don't scatter accounting logic across modules. Centralize it. Make it configurable. Then adding a new module is just a matter of plugging in a mapping rule, and the vouchers take care of themselves.

Pothole #2: Model Hopping Breaks Your Codebase

I'm not a coder, but AI writes the code for me. Early on, I got clever. I let model A write one module and model B write another, thinking I'd get the best of both worlds. It was a nightmare. The code styles clashed—naming conventions, structure, error handling all felt like two different people. Fixing something in module A would break module B, and vice versa. Bugs multiplied faster than features.

Even worse was letting different models take turns rewriting the same logic. Model B would look at model A's code, not understand the context, and rewrite it from scratch, scrambling the logic. Each individual piece looked fine, but the whole thing wouldn't run. Debugging was torture because every segment seemed correct on its own.

Finally, I settled on one model—GLM5.2—and used it for the entire project. The codebase became consistent. When I needed to change something, I knew how the model thought, and it could pick up where it left off. If I'd done this six months earlier, I'd have saved myself thousands of lines of deleted code.

Pothole #3: Version Control Is Non-Negotiable

In the beginning, I didn't use Git properly. I saved files with names like 'final', 'final2', 'real_final', and 'real_final_dont_touch'. Then one day, a big refactor broke the core voucher engine, and I had no clean version to roll back to. I had to rewrite the whole thing from scratch. That happened more than once. Each rewrite cost me days of work, and worse, it dented my confidence. I started wondering if I'd ever finish.

Eventually, I forced myself to use Git properly. I created a branch for each major feature, kept the main branch clean with only verified code, and allowed chaos in feature branches. If something broke, I could revert in ten minutes. I also made a habit of committing stable work to main at the end of each day, leaving experiments in branches overnight.

For a solo project, version control isn't optional. It's your safety net. Without it, you're coding on a cliff edge—one wrong move and everything you've built can vanish.

Pothole #4: The MCP Trap—Front-End Calculations Vanish

After the system was running, I got fancy. I wrapped my purchase, production, sales, and finance modules into MCPs—each with dozens of tools for every action, from checking stock to building a purchase order. Then I connected them to WorkBuddy, so I could just type 'check stock for SKU-123' and it would call the tool. No clicking through menus.

But here's the trap: I'd put some calculations—like line-item totals, tax amounts, and document summaries—in the front-end layer. That worked fine in the UI, because the front-end executed them. But when the conversation layer called the tool directly, it only passed parameters and got results. It didn't run the front-end code. So the numbers came back wrong. Vouchers didn't match, and the reports were off.

What made it worse was that everything looked fine in the interface. I'd open a document and see correct numbers. But when I asked the chat bot for the same data, it gave different figures. I stared at two conflicting numbers for ages before I figured it out.

The fix was to move all business calculations into the back-end, no matter how trivial. The front-end and conversation layer now only pass parameters and display results. I also added a double-check: every number is computed twice via two independent paths, and if they don't match, the system blocks it from posting. It's like a double safety net for your data.

The takeaway: if you're exposing your system to conversational interfaces, every calculation must live in the back-end. The conversation layer won't do your front-end work for you. Ironically, this forced me to design cleaner interfaces.

The Real Lesson: AI Gives You Muscle, Not Judgment

AI has made it possible for a non-coder like me to build enterprise-grade software. But it hasn't made development easy—it's just made it possible for one person to carry the weight. The catch is that you have to make all the decisions yourself. There's no one to hit the brakes when you're about to drive off a cliff.

People think AI can think through the business logic for you. It can't. It writes the code, but you have to know what the code should do. That gap between 'what you want' and 'what AI writes' is where all the potholes live.

My system isn't perfect. The modules need polish, the reports need tuning, and sometimes the chat mishears me. But it does one thing no one believed I could do on my own: it generates a balance sheet. That's worth every late night and every deleted line of code.