The Eye Makeup System That Almost Built Itself—Until It Didn't

It Started With a Dream—and a Tube of Mascara

I've had this fantasy for years: a system that tracks every shade of eyeshadow, every batch of eyeliner, and every order from my small indie makeup brand—without me having to touch a spreadsheet. I'm not a coder. I studied computer science in college, sure, but after graduation, I barely wrote a line. The dream stayed a dream.

Then AI came along. Suddenly, the thing I'd sketched on napkins and in my head started to take shape. Now it's in beta. My purchase orders, production runs, and sales receipts automatically generate accounting entries. Balances roll up into profit-and-loss statements. And I can just chat with it: "How much of the matte rose palette do we have left?" It checks. No menu clicking. No form filling.

But let me be clear: this isn't a victory lap. I hit four walls so hard I wanted to delete the whole project. Here's what I learned.

Wall #1: The Interface Was a Distraction

Early on, I obsessed over buttons and field layouts. How should the dropdown behave? Should the color swatch auto-populate? I thought that was the real craft. It wasn't.

The actual heart of the system is turning business actions into accounting language. When I receive a shipment of pigment, that's inventory and accounts payable. When I pull materials for a batch of cream shadows, that's work-in-progress. When I sell a lipstick, revenue and receivables follow. Three different moves, three different sets of debits and credits.

My first version let each module calculate its own entries. Big mistake. The ledger never balanced. Purchasing said we owed one number; finance said another. Everyone was sure they were right.

So I flipped the architecture. Modules no longer create entries. They just emit events. A single engine translates those events into accounting entries, using a set of mapping rules per document type. One purchase order in—the engine debits inventory, credits accounts payable. One sale confirmed—it books revenue and receivables. All entries land in one balance table, and the balance sheet is just a read-only projection of that table.

That's the real meaning of integrated business and finance: not stitching modules together, but building a pipeline that translates actions into accounting. The rules have to be centralized and configurable, not scattered around.

Now, when I add a new module, I just plug in a mapping. The entries appear. No more begging finance to reconcile.

Wall #2: Too Many AI Cooks in the Kitchen

The code was written by AI, but I made a rookie mistake early on. I let different models write different modules. Model A did purchasing, Model B did sales. I figured I'd get the best of each. What I got was a mess. Their coding styles clashed—different naming, different structures, different error handling. Fixing one broke the other. The bug count grew faster than the features.

Even worse was having different models take turns editing the same logic. One model's context didn't carry over. The next model rewrote things its own way, and the logic went haywire. Each snippet looked fine in isolation, but the whole thing didn't run. Debugging was a nightmare because every piece individually seemed correct.

Finally, I settled on one model—GLM5.2—for the entire project. One consistent style. When something breaks, I can trace it because the thinking is uniform. It's like having one author instead of a committee.

Lesson: with AI, don't get greedy. One model that works well beats three "smart" ones. I could have saved myself tens of thousands of lines of deletion.

Wall #3: Version Control (or Lack Thereof)

For the first few weeks, I didn't use Git properly. I named files with dates and suffixes: final_v2, final_v3_USE_THIS, final_v3_REALLY. Then a big refactor broke the core accounting engine. I tried to roll back—no clean version existed. I had to rewrite it from scratch.

That happened more than once. Each rewrite cost days, and worse, it drained my confidence. By the second rewrite, I started questioning if this project was even possible. And every rewrite burned tokens.

So I got serious about Git. Each phase gets a branch. The main branch only gets verified code. Feature branches are for experiments. If I break something, I switch back in ten minutes. And every night, I commit the stable work to main. Unstable stuff stays on its branch overnight.

Without version discipline, a solo project is like writing on a cliff edge. You think you're saving time, but one bad move wipes out everything. When you're alone, there's no one to catch you.

Wall #4: The Sneaky MCP Trap

Once the system ran, I wanted to make it conversational. Traditional ERP is all menus and forms—clunky and slow. So I wrapped my core modules (purchasing, production, sales, finance) into MCPs—each with dozens of tools, each tool a function call. "Check stock of X," "create purchase order," "get P&L"—all become chat commands.

Getting the tool granularity right took time. Too coarse, and the AI can't tell what you want. Too fine, and you've got fifty lookalike tools. I settled on one tool per business action, with plain names.

But here's the trap: I initially put some calculations—like line totals, tax, and summaries—in the frontend layer. The UI ran them fine. But when the conversation layer calls a tool, it only passes parameters and gets results. It doesn't execute frontend logic. So the numbers came out wrong. The entries didn't match, and the reports were off.

This was the hardest bug to find. The UI showed correct numbers. Only the chat was wrong. I ran the same transaction through both paths and got different figures. I stared at the screen, dumbfounded.

The fix: move every calculation into the backend. The frontend and chat layer just pass data and display results—they never touch the math. I also added a double-check: every number is computed two ways internally, and if they disagree, the system blocks it from becoming an entry. Belt and suspenders.

Now the numbers match everywhere—chat, UI, reports. And honestly, this forced me to make my interfaces cleaner. The chat layer doesn't forgive sloppy design.

What AI Actually Changed

AI loosened the coding reins, but it didn't loosen the thinking reins. A lot of people think AI can think through the system for you. It can't. It just writes what you tell it. The gap between "I have an idea" and "I know exactly what to build" is where all the pits are.

None of these walls were one-and-done. Every reset cost me time, focus, and a few nights of staring at my screen wondering if I was wasting my life.

But here's the thing: AI gave me the muscle, not the judgment. It didn't make development easier—it made it possible for one person to handle the scale of enterprise software. The catch is that you have to make every call yourself. No one's hitting the brakes for you.

That old dream is running in beta now. It's not perfect. Modules need polish, reports need tweaking, and sometimes the chat misunderstands me. But it really does generate a balance sheet on its own. And that's something I never thought I'd see.