From ERP Dreams to Bathroom Sanitization: A Builder's Guide to Clean Code

The Dream That Wouldn't Flush

For years, I'd wanted to build my own bathroom sanitization system. Not the kind you buy at the store—the kind that tracks every wipe, spray, and scrub, turning chaos into a clean routine. I studied computer science, knew databases and software engineering, but after graduation, I rarely wrote a line of code. The blueprint was in my head, but my fingers froze at the keyboard. The idea stayed an idea.

Then I got deeper into the world of facility management, working on large-scale cleaning projects and eventually joining a company that made commercial cleaning software. I saw how janitorial teams tracked supplies, how they logged tasks, and how the numbers had to tie out at the end of the month. Slowly, that mental model of a cleaning operation grew into a full system in my head.

But a model without code is just a daydream. AI changed that.

From Blueprint to Working System

Now that system is in beta. It automatically generates cleaning schedules from supply usage, tracks chemical dilutions, and turns every spray and wipe into a line item that rolls up into a daily hygiene report. I even wrapped the core modules into MCPs—each with dozens of tools—so I can just chat with my system to check if the restroom has enough paper towels or to order a new batch of disinfectant.

I don't want to make this sound like a smooth ride. I hit four walls that made me want to delete everything and start over. Here's what I learned, so you don't have to bleed on the same nails.

The Trap of Pretty Interfaces

At first, I obsessed over the front-end. Button placement, field animations—I thought that was the real craft. But as I dug in, I realized the core wasn't the UI; it was how cleaning actions translated into accounting language. A restroom refill means a decrease in inventory and an increase in expense. A deep-cleaning task means labor hours and chemical costs. Every action has a double-entry logic.

My first version let each module do its own bookkeeping. The supply module logged its own numbers, the cleaning team logged theirs. It collapsed. Chemical usage said one thing, the expense report said another. Nobody was wrong, but everyone disagreed.

So I restructured. No module creates its own entries anymore. They emit events, and a central engine translates those events into journal entries. Each event type maps to a rule: a restroom refill triggers a debit to supplies expense and a credit to inventory. All entries go into one ledger table, and the daily report is just a read-only projection of that table.

The lesson? A sanitization system isn't about making modules talk to each other; it's about a single pipeline that turns every action into consistent records. Keep the rules centralized and configurable, or you'll drown in reconciliation.

Let One Model Drive, Not a Committee

AI wrote the code, but I made a rookie mistake early on. I thought I'd be clever: let model A handle the inventory module, model B handle the scheduling logic. Each model has strengths, right? Wrong. Model A's code style clashed with Model B's. Naming conventions, error handling—they were two different personalities. Fixing A broke B, and debugging was a nightmare because every piece looked fine on its own but wouldn't fit together.

Even worse was letting different models take turns editing the same function. One model's context got lost, so the next rewrote it from scratch, creating logic that didn't connect. I finally settled on one model for everything. Consistency beat cleverness. If you're solo-building, pick a model and stick with it. It's like using the same brand of disinfectant throughout the building—you know what to expect.

Version Control: The Safety Net You Can't Skip

For the first few weeks, I didn't use Git properly. I saved files with names like 'final', 'final2', 'real_final', 'real_final_NO_TOUCH'. Then a big refactor broke the core sanitization logic, and I couldn't roll back because there was no clean version. I had to rewrite days of work. That happened more than once, and it drained my motivation—and my token budget.

I finally set up Git properly. Now I keep a main branch with only verified code, and I do all experiments in feature branches. If something breaks, I can revert in ten minutes. I also make it a habit to merge stable code into main at the end of each day. If you're working alone, version control isn't optional. It's your safety net when there's no one else to catch you.

When Chatting Becomes the Interface

Traditional sanitization systems rely on menus and forms. I found that clunky, so I wrapped each core module—supply tracking, cleaning schedules, chemical dosing, reporting—into an MCP. Each MCP has dozens of tools that map to specific functions. Want to know how much bleach is left? Just ask. Need to schedule a deep clean? Say the word.

But I tripped on the tool granularity. Too coarse, and the chat can't understand what you want. Too fine, and you have fifty tools that look identical. I settled on one tool per business action, with clear names.

The sneakiest bug came from putting calculations in the front-end. I had small sums and tax amounts computed in the UI, which worked fine when I clicked through the interface. But when I called the same feature via chat, the chat layer only passed parameters and returned results—it didn't run the front-end code. So the numbers came out wrong. The report didn't match the actual inventory.

It took me ages to find that bug because the interface looked perfect. Only the chat output was off. I finally moved all calculations into the back-end, and now both the UI and the chat layer just pass arguments and display results. I also added a double-check: two independent calculation paths must agree before a number gets recorded. That was my insurance policy.

Chat-driven systems force you to make your APIs clean. The chat won't do any thinking for you—it just calls the endpoint and trusts the result.

AI Gives Muscle, Not Judgment

After all this, I've concluded that AI loosens the reins on coding, but not on thinking. A lot of people expect AI to design the system for them. It won't. It writes the code, but the architecture, the rules, the debugging—that's still on you. The gap between 'I can write this' and 'I know what to write' is where the pitfalls live.

Every one of these four traps cost me time and confidence. But they also taught me that AI doesn't make development easier; it just makes it possible for one person to build something that used to require a team. The trade-off is that you have to make every decision yourself, with no one to hit the brakes.

My sanitization system is still in beta. The modules need polish, the reports need tuning, and sometimes the chat mishears me. But it actually generates a daily hygiene report on its own. That's more than a dream—it's a clean start.