Today we went live

Production, bugs, and sixteen things I missed

Today I put a project into production. A system I've been building for a scrap metal and paper recycling yard in Berlin. It's now handling real operations — real employees, real customers, real money.

The business

The client buys scrap metal, copper, brass, zinc, paper, and other recyclable materials from walk-in customers. Someone shows up with a bag of copper wire, it gets weighed, priced based on current market rates, and paid out in cash. The operation runs six days a week, multiple employees on the floor, dozens of transactions a day.

Before this system, most of it ran on paper, Excel, and people remembering things. Prices lived in someone's head or a printed sheet. Purchase records were scattered. There was no reliable way to track what came in, at what price, and whether the payout matched.

What I built

Two things:

The backend — custom Odoo modules that manage the article catalog, pricing, purchase orders, and cashier operations. Market prices for metals update automatically from LME data. The cashier module handles the full flow: customer walks in, articles get weighed and categorized, system calculates the payout, cashier confirms.

The mobile app — built with Flet, it runs on a smartphone strapped to the employee's forearm. The person receiving materials uses it to scan, weigh, categorize, and confirm articles without going back and forth to a desktop. We tested this form factor back in February and after a couple hours, the tester said it felt "like it wasn't even there."

What happened today

I went on-site for the production launch. The system was processing actual purchases within the first hour.

And then the bugs came, as they always do when software meets reality.

One showed up fast: six metal products had their unit of measure set to "Days" instead of "kg". A data migration artifact. Purchase orders failed because Odoo rightfully refused to mix time units with weight units. I fixed it on the spot, correcting the product records directly in the database. Problem gone, transactions flowing again within minutes.

But the real feedback came from the client, who sat with his team and watched them work. He sent me a detailed list — sixteen items in total. The critical ones:

  • The cashier screen throws an "invalid action" error during validation. Blocks the payment flow entirely.
  • Prices don't show up in parts of the interface. Employees can't see what they're paying.
  • Parked purchases (when a customer leaves and comes back) are nearly impossible to find again.

Then the UX issues that slow everything down:

  • Copy-pasting values includes extra whitespace. The team wants dedicated copy buttons.
  • The edit button on articles sometimes doesn't respond. Multiple clicks needed.
  • After editing a price, the color changes and you can't edit it again.
  • A confirmation button at the bottom of the screen is half-cut by the viewport.

And the operational questions that reveal what documentation I still owe:

  • How do cashiers correct a mistake mid-process?
  • What's the session timeout policy?
  • Where's the German translation?
  • How does the client create employee accounts and fix typos without calling me?

What happens next

The three critical bugs go straight to my software factory — an automated task pipeline that dispatches work to AI sub-agents. They'll be the next tasks executed.

The UX issues become the week's backlog. The operational questions become documentation tasks — SOPs, a training session, access control setup.

This is the part of software work that I find most honest. You can test for months in staging and still, the first hour with real users on a real floor produces a list of sixteen things you missed. Not because testing was bad, but because production is a different animal. The employee with the phone on their arm, the customer waiting with copper wire, the cashier who needs to correct a mistake NOW — that pressure reveals everything that lab conditions hide.

The system is live. It works. And now the real work begins.


Omar Díaz — software engineer building AI-powered operations for small businesses. OpenClaw-based automation.

← Back to Blog