Brewing Better Coffee: How I Automated My Roastery with AI

The Dream of a Custom Roastery System

For years, I wanted a system that could run my coffee roastery—tracking green bean inventory, managing roast schedules, handling sales orders, and keeping the books straight. I'd studied computer science in college, but after graduation, I barely wrote a line of code. The vision was clear in my head, but my fingers froze at the keyboard. So the dream stayed a dream.

Then I spent years working on enterprise software projects for big companies, and later at an ERP vendor and a Big Four accounting firm. I saw how businesses flow, how documents become journal entries, and how messy go-lives can get. Slowly, a complete ERP model took shape in my mind—every process, every accounting linkage. But a model in your head is useless if you can't build it. Without coding skills, it was just a pretty mental diagram.

When AI came along, the dream finally became real. Now my DIY system is in beta, and it works. Purchase orders, roast logs, and sales invoices automatically generate accounting entries. Those entries roll up into balances, which become my profit and loss statement and balance sheet. I even wrapped core modules as MCP servers—each with dozens of tools—so I can chat with WorkBuddy to check inventory, create a purchase order, or pull a P&L. It feels like magic, but it wasn't easy.

I'm not going to pretend it was a smooth ride. I hit four major pitfalls, each one made me want to delete everything and start over. Here's what I learned, so you don't have to make the same mistakes.

Pitfall #1: UI First, Logic Later

When I started, I obsessed over the interface. Buttons, field dependencies, dropdown menus—I thought that was the hard part. It wasn't. The real challenge was turning business actions into accounting language. A coffee bean purchase adds to inventory and creates an accounts payable. A roast batch transfers green beans to work-in-process. A sale recognizes revenue and accounts receivable. Each action has its own set of debits and credits.

My first version let each module generate its own journal entries. It was a disaster. Balances never matched. Procurement swore the payable was one number, finance said another. Everyone thought they were right.

So I redesigned the architecture. Now, modules don't create entries at all—they just emit business events. A central engine translates those events into journal entries using configurable mapping rules. When a purchase receipt comes in, the engine debits inventory and credits accounts payable. When a sale is confirmed, it recognizes revenue and receivable. All entries flow into a single balance table, and my financial statements are just projections of that table—read-only.

The lesson: integration isn't about gluing modules together. It's a translation pipeline from business actions to accounting language. Centralize the rules, make them configurable, and don't let each module speak its own dialect.

Pitfall #2: Mixing AI Models

The code was written by AI, but I made a rookie mistake early on. I thought, "Why not use the best model for each module?" So I let one model write the purchasing module, another the production module, and a third the finance module. Big mistake.

The code styles clashed. Naming conventions, structure, error handling—all different. Fixing one module broke another. Bugs multiplied faster than features. Even worse, when I had one model hand off code to another to modify the same logic, the new model couldn't follow the old context. It rewrote things its own way, and the logic got scrambled. Each piece looked fine in isolation, but together they fell apart.

After testing a bunch, I settled on GLM5.2 and used it for the entire project. One model, one style. When I need to change something, I know how it's structured. When something breaks, I can trace the same thought process. It just works.

If you're building with AI, resist the temptation to mix models. One consistent model beats three "smart" ones every time. I wish I'd learned that six months earlier—I'd have saved thousands of lines of code.

Pitfall #3: No Version Control

For the first few weeks, I didn't use Git properly. I saved files with names like "final", "final2", "real_final", "real_final_REALLY". Then one big refactor broke the core journal engine, and I couldn't roll back. No clean version existed. I had to rewrite everything.

That happened more than once. Each rewrite cost me two or three days of work, not to mention the morale hit. After the second rewrite, I started doubting I'd ever finish. And it burned tokens.

Finally, I got serious with Git. I create a branch for each phase, keep the main branch clean, and let feature branches be messy. If something breaks, I can revert in ten minutes. I also made a habit: at the end of each day, I merge whatever is stable into main. Anything risky stays in a branch overnight.

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

Pitfall #4: MCP and the Invisible Front-End Trap

Once the system ran, I wanted to make it conversational. Traditional ERP menus felt clunky. So I wrapped each core module—purchasing, production, sales, finance—as an MCP server. Each MCP exposes dozens of tools, each backed by an API function. Now I can say, "Hey WorkBuddy, check how much Yirgacheffe we have left," and it calls the tool. No menus.

Tool granularity took some tuning. Too coarse, and the AI can't tell what you mean. Too fine, and you have hundreds of similar-looking tools. I settled on one tool per business action, with descriptive names.

But the sneakiest trap was this: I'd put some calculations in the front-end code—subtotals, taxes, order summaries. In a normal UI, that works because the frontend runs the logic. But in a conversational interface, the chat layer just passes parameters and gets results. It doesn't run front-end code. So numbers came out wrong. Journal entries didn't match, and reports were off.

This was the hardest bug to find. In the UI, everything looked perfect. But when I queried via chat, the numbers differed. I stared at the same transaction, comparing UI and chat, and couldn't figure out why.

The fix was a major refactor: move all business calculations—no matter how trivial—into the backend. The frontend and chat layers only pass parameters and display results. Then I added a double-check: the backend calculates every number twice using two separate paths, and if they don't match, the entry is blocked. That's my data safety net.

Now the numbers are consistent everywhere—UI, chat, reports. The moral: MCP interfaces must be fully backend-based. Any calculation done in the frontend will vanish when called via chat. Architecting for conversational access forced me to make my APIs cleaner, which was a silver lining.

The Real Lesson: AI Doesn't Think for You

People think AI can design your system. It can't. It can write the code, but you have to know what you want. The gap between "I have a vague idea" and "I know exactly how the accounting flow works" is where all the pitfalls live.

AI gives you muscle, not judgment. It didn't make development easier—it made it possible for one person to build enterprise-grade software. But you're the one making every decision, and there's no one to hit the brakes for you.

My roastery system is still in beta. It's not perfect—modules need polish, reports need tweaking, and sometimes the chat mishears me. But it really does generate its own balance sheet now. And that's a dream I never thought I'd see come true.