I Built the ERP I Always Wanted — Then Realized the Real Fight Was Elsewhere

Some Dreams Take Decades

For years, I carried a blueprint in my head — a complete ERP system, every module mapped, every ledger balanced. But I couldn't code. Not really. I'd studied computer science, sat through operating systems and database classes, but after graduation, I never wrote a line in anger. The model stayed a model.

Then AI showed up. It didn't just write the code; it made the dream possible. Today, that system is in closed beta. Purchase orders, production runs, sales invoices — they flow through a central engine that turns business events into accounting entries. Balances roll up into a balance sheet and income statement. And I wrapped the core modules as MCP tools, so I can chat with WorkBuddy and ask, "How much inventory do we have on item X?" — and it answers.

But I don't want to tell you it was a smooth ride. It wasn't. I hit four pits that nearly made me delete everything. Here's what I learned — and why it reminds me of training for a fight.

Pit One: Letting Each Module Do Its Own Accounting

My first version let each module generate its own vouchers. Purchasing created its own entries, sales created theirs. It was a mess. The balances never matched. Purchasing would say payables were one number; finance would say another. Everyone was sure they were right.

The fix was brutal but simple: stop letting modules think. They only emit business events. A centralized voucher engine translates those events into accounting language. Purchase receipt comes in — the engine debits inventory and credits payables. Sales confirmed — the engine books revenue and receivables. All vouchers land in one balance table. The balance sheet and income statement are just read-only projections of that table.

That's the essence of integrated business and finance — not bolting modules together, but building a translation pipeline from business action to accounting language. And the rules must be centralized and configurable. Once I did that, adding a new module meant just hanging a mapping set on the engine. No more begging finance to reconcile.

Pit Two: Mixing AI Models Like a Bad Game Plan

I got greedy. I thought, "Let this model write purchasing, that one write finance — each is strong at something." It was a disaster. The interface styles clashed — naming, structure, error handling — two different personalities. Fixing one broke the other. Bugs outnumbered features.

Worse, I let different models take turns rewriting the same logic. The second model didn't understand the first one's context, so it rewrote from scratch. The code looked fine in pieces but fell apart when integrated. Debugging was a nightmare because every segment looked correct on its own.

I finally settled on GLM5.2 and stuck with it for the whole project. One model, one style. Now I know how it thinks. When something breaks, I can trace it because the logic flows the same way. If I'd learned that six months earlier, I'd have saved thousands of lines of rewrites.

Pit Three: Version Control — Or the Lack of It

I didn't use Git properly at first. I saved files with names like "final_v2", "real_final", "final_do_not_touch". Then a big refactor broke the voucher engine's core. I wanted to roll back — but 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 work and, worse, my spirit. By the second rewrite, I started doubting the whole project. Plus, it cost tokens.

So I got serious with Git. Each phase gets a branch. The main branch only holds tested code. Feature branches can be as messy as they need to be — if I break something, I switch back in ten minutes. And I end each day by merging what's stable into main, leaving the messy stuff on its branch overnight.

If you're building alone, version discipline isn't optional. There's no teammate to catch your fall. You are the safety net, and if you don't have one, you're coding on a cliff.

Pit Four: MCP Tools That Hid Frontend Calculations

When the system ran, I wrapped core modules as MCP tools — dozens of tools per module, each mapping to an API function. You can query inventory, create a purchase order, pull a profit statement — all through conversation. No clicking through menus.

But I made a subtle mistake. I put some calculations — subtotals, taxes, document summaries — in the frontend. That worked when the UI called the API, because the frontend executed those calculations. But conversational calls skip the frontend entirely. They just pass parameters and get results. So the numbers came back wrong. Voucher amounts didn't match. Reports disagreed with reality.

The worst part? It only showed up in conversation. The UI looked perfect — open a document, and the numbers were right. Ask the same thing in chat, and it was different. I stared at two different numbers for the same transaction, baffled.

I fixed it by moving every calculation, no matter how small, into the backend. The frontend and conversation layer only pass parameters and display results. Then I added a double-check: the backend computes the same number two ways and blocks it if they don't match. That's my version of a referee checking the scorecard.

Now the data is solid. What I see in chat matches what I see in the UI, and what rolls into reports. The MCP interface must be fully backend — anything the frontend computes evaporates when called from chat. In a way, conversational access forced me to make the interfaces cleaner. That was a bonus.

The Real Lesson: AI Gives Muscle, Not Judgment

Here's what this whole journey taught me, and it mirrors every fight I've ever been in. AI loosens the reins on writing code, but it doesn't loosen the reins on thinking clearly about the business. A lot of people think AI will figure out the system for them. It won't. It just writes what you tell it to. The thinking is still yours.

That gap — between what you understand and what you ask for — is where the pits are. None of these four were one-and-done. Each cost me time, spirit, and those moments of staring at the screen, wondering if I'd lost it.

But here's the thing. AI gives you the muscle. It doesn't make development easier — it makes it possible for one person to carry the weight of an enterprise system. The trade-off is that you have to make every call yourself. There's no one to hit the brakes for you.

My dream ERP is running in beta now. It's not perfect — modules need polishing, reports need tuning, and sometimes the conversation mishears me. But it does something real: it produces a balance sheet on its own. And that's more than I ever thought I'd see.