Turning a Dream ERP into a Handcrafted Work of Art

The Dream That Wouldn't Die

For years, I carried a quiet obsession: building my own ERP system. Not because I needed one—plenty exist. But because I wanted to make something that was mine. I studied computer science in college, learned about operating systems, databases, and software engineering. Then I graduated and barely wrote a line of code again.

That’s the thing about dreams. They sit in your head, fully formed, glowing with potential. But without hands to shape them, they stay just that—dreams.

The Blueprint in My Head

Work pulled me deeper into the ERP world anyway. I joined digital transformation projects at big companies, then moved to a domestic ERP vendor, then landed at one of the Big Four accounting firms. Through it all, I watched business processes and financial reconciliations unfold. I saw the chaos before go-live, the frantic weekends, the spreadsheet wars.

Slowly, a model of how an ERP should work crystallized in my mind. I knew how goods flowed, how documents became accounting entries, how the balance sheet finally balanced. But knowing and building are different verbs. Without coding skills, my blueprint stayed abstract.

AI Finally Turned the Key

Then AI arrived. Not as a magic wand, but as a pair of hands. I started building. Now, months later, my system is in internal testing. Purchase orders, production runs, and sales invoices automatically generate journal entries. Those entries roll into account balances, which roll into a balance sheet and income statement. It works. It’s not perfect, but it works.

The First Pitfall: Thinking UI Was the Hard Part

Early on, I poured hours into the interface. Button placement. Field cascades. I thought that’s where the real craftsmanship lay. I was wrong.

The real heart of an ERP isn’t the screen—it’s how business actions become accounting language. A purchase receipt should debit inventory and credit accounts payable. Production material issues move costs into work-in-progress. A sale triggers revenue and receivables. Three actions, three sets of double-entry logic.

My first version let each module create its own journal entries. Each business unit did its own math. It collapsed quickly. Balances didn’t match. Purchasing said payables were one number; finance swore it was another. Everyone was sure they were right.

So I restructured. Modules stopped generating entries. They only emit business events. A central translation engine—what I call a voucher engine—handles all conversions. 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 creates revenue and receivables. All entries land in one account balance table. The balance sheet and income statement are just read-only projections of that table.

The lesson: true business-finance integration isn’t about gluing modules together. It’s a translation pipeline from action to accounting language. Keep the rules centralized and configurable. Otherwise, every module speaks its own dialect.

The Second Pitfall: Model Hopping

AI wrote all the code. But I made a rookie mistake early on. I let different AI models handle different modules, thinking I’d get the best of each. Model A wrote the purchase module. Model B wrote production. They had completely different coding styles—naming conventions, structures, error handling. Changing one broke the other. Bugs multiplied faster than features.

Even worse was letting different models edit the same logic sequentially. The second model didn’t understand the first one’s context, so it rewrote things to its own liking. The result was a patchwork that looked fine in isolation but fell apart when integrated. Debugging was a nightmare because every piece seemed correct on its own.

I settled on one model—GLM5.2—and stuck with it for the whole project. Consistency became my friend. When something broke, I could trace it because the thought process was uniform. If I’d figured this out six months earlier, I’d have saved tens of thousands of lines of deleted code.

The Third Pitfall: Version Control Chaos

In the beginning, I didn’t use Git properly. I named files like final_v2, final_v3_actually, real_final_no_really. Then one big refactor broke the voucher engine’s core logic. I wanted to roll back, but there was no clean version. I rewrote it from scratch.

That happened more than once. Each rewrite cost days and, worse, morale. The second time you’re rewriting, you start doubting whether the project is even possible. And you’re burning tokens the whole way.

Finally, I embraced Git. Each stage gets a branch. The main branch only gets tested, stable code. Feature branches are for experiments—if they break, I switch back in ten minutes. I also made a habit: before ending the day, merge whatever’s stable into main. Leave the risky stuff on the branch overnight.

Without version discipline, a solo project is like writing code on a cliff’s edge. You think you’re saving time, but you’re one misstep from losing everything. When you’re alone, there’s no safety net.

The Fourth Pitfall: MCP and the Invisible Calculation Trap

Once the system ran, I decided to wrap core modules—purchasing, production, sales, finance—into MCPs (Model Context Protocol). Each MCP contains dozens of tools, each mapping to a function interface. I configured them into WorkBuddy, so I could just ask: "Check inventory for material X" or "Pull the profit statement." No clicking through menus.

Tool granularity took time to tune. Too coarse, and one tool does ten things—conversation gets confused. Too fine, and you have dozens of similar-looking tools. I settled on one tool per business action, with plain names.

But the hidden trap was in the interface design. I’d put some calculations—line totals, tax amounts, document summaries—in the frontend layer, thinking it was fine for a UI. It worked in the interface. But when called via conversation, the dialog layer only passes parameters and returns results. It never runs frontend calculations. So the numbers came out wrong. Voucher amounts didn’t match. Reports disagreed with reality.

This was the hardest bug to find. The UI showed correct totals; the dialog showed different ones. I stared at the same transaction twice, confused.

The fix: move all business calculations into the backend interface. Frontend and dialog only pass parameters and display results. I also added a double-check: each figure is computed twice via independent paths, and if they mismatch, the system blocks it from becoming a voucher. Belt and suspenders.

Now the data is steady. Dialog results match interface results match report totals. The MCP interface must be fully backend. Anything calculated in frontend evaporates when called by a conversation. In a way, conversational access forced me to design cleaner interfaces—an unexpected bonus.

What I Learned About Craft

This journey taught me that AI loosens the reins on writing code, but it doesn’t loosen the reins on thinking clearly about the business. Many people assume AI will think the system through for them. It won’t. It writes the code, but you still have to understand the problem. That gap is where the pitfalls live.

None of these four pitfalls were one-shot fixes. Each required a do-over, with costs in time, morale, and late-night doubt. But that’s what craft is—iterating through the messy middle until the thing holds together.

AI gives you the muscle, but you still have to steer. It didn’t make development easier; it just made it possible for one person to take on something that used to require a team. The trade-off is that you’re the only one making decisions, and there’s no one to hit the brakes.

That decades-old dream is now running in internal testing. It’s not perfect—modules need polish, reports need tuning, and sometimes the conversation mishears me. But it really does generate a balance sheet on its own. And that feels like a small work of art.