Turning a Dream ERP into a Year-Round Hobby: Lessons from the Trenches

From Daydream to Daily Hobby

For years, I had a fantasy: building my own ERP system. I studied computer science in college—operating systems, databases, software engineering—but after graduating, I rarely wrote a line of code. My brain held a blueprint, but my fingers froze at the keyboard. So the dream stayed a dream.

Work pulled me deeper into ERP anyway. I joined digital transformation projects at big companies, moved to a domestic ERP vendor, then landed at a Big Four accounting firm. Through all that, I absorbed how business processes flow, how accounting entries link, and how messy go-lives can get. Slowly, a full ERP model took shape in my head—I could picture the workflow, the journal entries, the final reports. But a picture isn't a product. Without coding skills, the model stayed theoretical.

Then AI came along. And that dream turned into a year-round hobby. Today, my system runs in internal testing. Purchase orders, production runs, and sales invoices automatically generate accounting entries. Those entries roll up into account balances, which spit out balance sheets and income statements. I've even wrapped core modules as MCPs—each with dozens of tools—so I can chat with the system to check inventory, create a purchase order, or pull a profit report.

I don't want to tell a smooth success story. I want to share the mess—the four big pitfalls I stumbled into, some so bad I nearly deleted everything and started over. If I can save you a few detours, this write-up is worth it.

Pitfall 1: Letting Every Module Do Its Own Accounting

In the beginning, I obsessed over the interface and workflow. Button placement, field dependencies—I thought that was the real craft. Turns out, it was secondary. The real heart of an ERP is turning business actions into accounting language.

Purchase receipts need to record inventory and accounts payable. Production issues move materials into work-in-progress. Sales confirmations trigger revenue and receivables. Each action has its own set of debit-credit logic. My first version had each module generate its own entries—purchasing did its thing, sales did theirs. It collapsed fast. Account balances didn't match. Purchasing said payables were one number; finance said another. Everyone thought they were right.

So I restructured. Modules no longer create entries; they emit business events. A centralized engine translates those events into accounting entries. Each document type has a mapping rule. A purchase receipt comes in, the engine debits inventory and credits payables. A sale confirms, and the engine pulls in revenue and receivables. All entries flow into one account balance table. The balance sheet and income statement are just projections of that table—read-only.

The lesson: true business-finance integration isn't bolting modules together. It's a translation pipeline from business actions to accounting language. Keep translation rules centralized and configurable, not scattered across modules. Once you do that, adding a new module is just hanging a new mapping on the engine. No more begging finance to reconcile.

Pitfall 2: Mixing AI Models Like a Cocktail

Code was written by AI, but I made a rookie mistake early on. I let different models handle different modules—model A for this, model B for that—thinking I'd get the best of each. Disaster. Model A's interface style clashed with B's. Naming, structure, error handling—they were speaking different dialects. Fixing A broke B, fixing B broke A again. Bugs multiplied faster than features.

Worse was letting different models take turns editing the same logic. One model wrote a section, the next model couldn't follow the context, so it rewrote it in its own way. The logic got tangled. Each piece looked fine alone, but together they wouldn't run. Debugging was a nightmare because every part seemed correct.

I tried a bunch of models and finally settled on GLM5.2. Sticking with one model for the entire project gave me consistent style. I could trace where things connected, and when something got messy, the same model's thinking could pick it up. That single choice saved me from deleting tens of thousands of lines of code.

Personal takeaway: when using AI solo, don't get greedy. One model that works well beats three that are 'smarter' combined. If I'd learned that six months earlier, I'd have saved a lot of heartache.

Pitfall 3: No Version Control, No Safety Net

For the first few weeks, I didn't use Git properly—or at all. Files piled up in folders with names like 'final', 'final2', 'real_final', 'real_final_no_more_edits'. Then a big refactor broke the core journal engine. I wanted to roll back, but there was no clean version. I had to rewrite.

This happened more than once. Each rewrite cost two or three days of work and, worse, my morale. By the second rewrite, I started doubting the whole project. Plus, every rewrite burned tokens.

Finally, I got serious with Git. I created a branch for each phase. The main branch only received tested code. Feature branches were wild—I could break them and switch back in ten minutes. I also made a habit: before quitting for the day, merge whatever was stable into main. Leave the unstable stuff on its branch overnight.

If you're building a personal project without version discipline, you're coding on a cliff edge. You think you're saving time, but you're one bad change away from zero. Solo developers especially need this—there's no teammate to catch you when you fall.

Pitfall 4: The MCP Trap—Frontend Math Disappears

Once the system ran, I hit the MCP phase. Traditional ERPs use menus and forms—click, click, click. I found that clunky. So I wrapped purchasing, production, sales, and finance into separate MCPs, each with dozens of tools. Every action—checking stock, creating a PO, pulling a profit report—became an independent tool. Plug them into WorkBuddy, and I could just say, 'Check how much of material X we have,' and the tool would fire. No UI needed.

Tool granularity took time. Too coarse, and one tool does ten things—the conversation can't tell what you want. Too fine, and you get dozens of similar-looking tools that confuse the caller. I settled on slicing by business action: one action, one tool, with names that make sense in conversation.

But the sneakiest pitfall was hiding in the architecture. Originally, I put some calculations outside the backend interfaces. Subtotal, tax, document totals—those ran in the frontend. That worked fine in the UI because the frontend executed them. But conversational calls only pass parameters and get results—they don't run frontend logic. So the numbers came out wrong. Journal entries didn't match, reports didn't tie out.

This was the hardest to debug. In the UI, everything looked perfect. Open a document, numbers were correct. Only when I called via chat did they differ. I stared at the same business, checking the UI, then the chat, getting two different numbers. It took me a long while to figure out what was happening.

The fix was a full interface upgrade. All business calculations—no matter how small—moved into backend interfaces. The frontend and chat layers only pass parameters and display results; they never touch math. I also added a double-check in the backend: compute the same number two different ways, and if they don't match, block it from creating a journal entry. Double insurance.

Now the data is stable. Numbers from chat, from the UI, and from reports all match. That's when I realized: MCP interfaces must be fully backend. Any frontend calculation disappears when called by conversation. The chat won't fill in missing logic. In a weird way, conversational operation forced me to make the interfaces cleaner—an unexpected bonus.

Why This Became a Year-Round Hobby

After this journey, I've concluded that AI loosens the reins on writing code, but not on thinking through the business. A lot of people think AI can design the system for them. Actually, AI only writes it. Understanding the problem is still your job. That gap is where the pitfalls live.

None of these four pitfalls were one-and-done. Each retry cost time, morale, and moments of staring at the screen doubting myself.

In the end, AI gives you the muscle, but the judgment is still yours. It didn't make development easier—it just made it possible for one person to handle the scale of enterprise software. The trade-off is that you make every call yourself. No one hits the brakes for you.

That dream I had for years is now running in internal testing. It's not perfect—modules need polish, reports need tuning, and the chat occasionally mishears me. But it really does generate a balance sheet on its own. And that's a hobby I'll keep tinkering with all year round.