What I Built Inside a Live Company

Damian Kao — Wed, 24 Jun 2026 00:00:00 +0000

I wrote a separate, more personal essay about what it feels like to build software inside a company that's already running: the live wires, the no-staging discipline, the bug that's someone's morning instead of a ticket. You can read that one here: Building Inside a Live Company. This piece is its counterpart, and it is the one to read if you are going to build something similar yourself, because feelings do not transfer but decisions do. So here is the substance: what the constraint actually produced, and which of the choices behind it are worth stealing.

What you are actually building

Start by being clear about what kind of thing this is, because it changes how you build it. It is not an app. An app is a screen with some logic behind it. What a real operation needs is a connected platform: something that takes the business from a customer's first question all the way to a costed, production-ready order, and then learns from how that order actually went. The "and then learns" is the part that turns a tool into a system, and it is the part you have to design for from the start, not bolt on later.

Underneath everything sits one product-and-cost engine. Parametric templates turn a product's dimensions into a real parts list. A cutting-layout optimizer packs those parts onto material sheets. From there the engine derives cost and price, with an audit trail on every change so you can always answer "why is this the number." Built on that same engine are the things a business actually runs on: quoting and estimates, a sales funnel, factory costing, an agentic layer that can read the system to make recommendations, and a self-service customer portal. The full map of the pieces lives on the project page.

That is the what. If you are taking notes, though, copy the decisions, not the parts list. The parts will be different for your business. The decisions are the part that travels.

The decisions that mattered, and the ones that will matter for you

Build one engine, not many. The most consequential choice was refusing to let pricing live in more than one place. Every surface, the internal quote builder, the customer portal, the reports, runs through the same costing logic. That is the entire reason a customer can build their own quote without anyone on the team ever fearing it will disagree with what they would have charged. The temptation you will feel is to write a second, simpler version of the logic for the new surface, because it is faster today. Do not. A second implementation of your core is a second source of truth, and it will drift until the gap shows up in front of a customer. I wrote that specific problem up in detail in one engine, two audiences. The deeper version of the idea, that pricing, scheduling, and sales all become functions of product data once you decompose the product, is the whole thesis the framework is built on.

Do the data before the intelligence. If you are anything like me, you will want to build the impressive AI part first, because it is the part you can show people. The work will teach you the order is backwards. The intelligence is only ever as good as the decomposed data underneath it, so months of unglamorous decomposition have to come before anything that looks clever. I learned this the slow way and gave it its own note. The short version for your purposes: if you find yourself reaching for the model before the data is real, you are about to automate your guesses. Stop and do the boring part.

Ship in small, reversible pieces. This one was forced on me by the live constraint, and it turned out to be a gift in disguise. There is no version where the new system appears one Monday. Every change is to a running machine, so it has to go out small enough to take back. That rules out the heroic rewrite, and it quietly produces a more honest architecture, because you only get to build the piece you can actually prove. Even if you are not working under a live constraint, impose this one on yourself. The rewrite that ships all at once is the rewrite that fails all at once.

The lesson that stuck

If I could hand you only one thing from all of this, it would be this. Early on, I found a labor-time estimate I had quietly trusted for years was off by roughly threefold. Nobody had been careless. The number had simply never been made to meet reality. And it surfaced for exactly one reason: actual production data was flowing back and contradicting the estimate, out loud, where I could not ignore it.

Here is the lesson, and it is the one I would give anyone running a custom shop: your estimates are wrong in ways you cannot see until reality writes them down. Which means the most valuable thing you can build is not a smarter guess. It is the loop that records what actually happened and feeds it back into the next quote. This is why the framework treats phases 5 to 7 as a feedback triangle instead of a pipeline: production truth, quote accuracy, and sales promises are supposed to keep correcting each other. If you build only the forward path, you get a system that quotes confidently and never learns. Wire the loop, and treat the end of every project as the start of the next estimate.

If you are building something similar

If you are putting software inside a small operation rather than a greenfield, here is the short list, in the order it matters:

Reuse one engine. A second implementation of your core logic is a second source of truth, and it will drift. If a new surface tempts you to fork the logic, give it a new shape instead, not new logic.
Do the boring data work first. It is the part nobody demos and the part everything else depends on. If you cannot price your product from your own notes, you are not ready to build on top of them.
Ship small and reversible. The constraint that feels like it is slowing you down is also the thing keeping you honest. If a change cannot be taken back easily, cut it smaller until it can.
Build the feedback loop early. Let the system correct you, instead of trusting yourself to notice you were wrong. You will not notice. That is the whole point of the loop.

None of this is exotic. It is just what holds up when the thing you are building has to keep working for real people while you are still changing it. None of it is meant to stay locked to one company, either. The reason I write the decisions down rather than just the code is that they should travel to any small manufacturer trying to build the same thing, which is the larger aim behind all of this. If you want to see what all of these decisions add up to once they are in place, I wrote about the shape of the system the work produced.

DEV Community: Damian Kao

What I Built Inside a Live Company

What you are actually building

The decisions that mattered, and the ones that will matter for you

The lesson that stuck

If you are building something similar