Why I deleted what I built

Context

By mid-July the system had grown to 13 database tables. It handled orders, shipping, inventory and collections. It had just passed the full ten-step test. Of the whole summer, that was the best day.

The problem

The CEO asked for something reasonable: one master record of everything that happened in the business. Every sale, shipment, delivery from the plants, use of raw materials, payment and bill, in one place.

I started designing it as another table in my system. Then, to check my design, I mapped our whole supply chain step by step, 21 steps from buying raw materials to collecting payment, and compared it against standard ERP software.¹

Twenty of the 21 steps were already supported, out of the box. The one that wasn’t, reading purchase orders from PDFs, was the part I had already built.

And our manufacturing setup turned out to have a name. We own the raw materials, and the plant processes them for a fee. That’s called subcontracting, and standard ERP software has supported it for years.

My system worked. But it was mine. It ran on my knowledge. Anyone else would find it unfamiliar. If I left, it would slowly break, and nobody would know how to fix it.

So, the same week the system passed every test, I decided to replace it.

What I did

Rebuilding on Odoo

I rebuilt everything on Odoo, a standard ERP platform, in about three weeks. I moved the master data first: ten finished products with barcodes and weights, around forty raw materials split by plant, customers with their payment terms, a price list for each customer and the recipe for every product. Then the sales cycle, then manufacturing through the plants.

The second version was much faster and cleaner than the first. Building it once had taught me the design.

Fewer tools

The old system ran across four separate tools. The new one runs on one, with a single small automation left to turn order emails into draft quotes. Every tool I removed was one less place for something to break.

Seeing margin on every order

I set up costing so that every order showed its gross margin: what we sold it for, minus what it cost us to make. The company couldn’t see that before. Even on test data, the first time the margin screen loaded, it raised questions about pricing that nobody had been able to ask before.

Checking the settings

I audited the configuration and found three problems that would have quietly caused trouble: raw materials were set up as products that could be sold, invoices were being created when orders were placed instead of when they shipped, and partial shipments were handled inconsistently. None of these showed up as errors. They would have shown up months later as wrong numbers.

I also learned not to trust a green checkmark. The ERP sometimes reported success even when a step had failed, so I started reading the raw responses.

Getting the purpose right

I built payment reminders that went out on a schedule after an invoice was due. The CEO pointed out that he didn’t want an automated system chasing our customers. He wanted an internal reminder to check on payments. He was right. I had been building features and had lost sight of what the system was for.

One rule

I kept one rule from the first build: automation only creates the draft quote. Everything after confirmation is done by a person, in the system, on purpose.

I wrote a handoff document for the CEO at the end of the summer. Getting him fully independent on the system was the next step.

What I learned

The hardest part wasn’t building it. It was deleting it.

I had to separate “this is mine” from “this is right for the company,” and judge the work by what the company would run on for the next five years, not by how much effort I had put into it. The effort wasn’t wasted. It was how I learned what the company actually needed.

ERP stands for enterprise resource planning: software that runs a company’s orders, inventory, manufacturing and accounting in one system. ↩