Operations Blueprint: a plan and a starter repo for the small manufacturers software forgot

Damian Kao — Thu, 02 Jul 2026 02:59:13 +0000

Most writing about operational software, the smart factory, AI in manufacturing, quietly assumes you are big. It assumes a budget for six-figure systems, an IT team to run them, and clean data already sitting in a warehouse. A small manufacturer has none of that. And small manufacturers are not a niche: about 99% of US manufacturers are small, most with fewer than twenty people.

I came to this from inside one, trying to build the kind of operation that is supposed to require a team and a budget I did not have. What came out of it is a method, and now an open tool.

What it does

Operations Blueprint is a small, deterministic engine (no LLM, no network) that takes ten answers about a shop and produces two things.

A foundation-first plan: the relational data model, the process and SOPs, an ordered build list, and a self-hostable tooling list.
A runnable starter repo: a tailored project you can hand to a coding agent, with a real Postgres schema, a FastAPI skeleton where the cost engine and quote endpoint are stubbed, AGENTS.md, TASKS.md, and a compose file.

Both are tailored to the answers. A configurable metal-fab shop gets a different schema and build order than a catalog sign shop. You can try it in the browser at damiankao.com/blueprint.

The idea

Once you decompose a shop's product into honest, relational data, down to every material, labor second, and overhead dollar, the things above it (pricing, quoting, scheduling, sales) become functions of that data instead of work you do by hand. Lean, Six Sigma, and continuous improvement made large-scale manufacturing reliable, but they rest on a measurement foundation small shops have never had. This is an attempt to supply that foundation, and to close the estimate-versus-actual loop automatically.

A worked example

The repo includes a full one: a fictional seven-person steel fabrication shop, run end to end from its (synthetic, deliberately messy) spreadsheets to a working slice. Loaded with its own data, it surfaced two problems that were invisible in the spreadsheets: a quote priced by hand that was quietly under the real cost, and a job whose welding ran over, dropping the real margin well below the quote. Neither needed new data; it was all already there, just not joinable. Full write-up: Running the Blueprint on a Shop That Doesn't Exist.

It is early

Scoped to custom and made-to-order manufacturing, MIT-licensed, and honestly still finding its edges. The repo ships with a CLI, tests behind CI, and a folder of pre-generated blueprints for four invented shops if you would rather read plans than answer questions. If you have run a small shop, I would like to hear where it is wrong.

Repo: github.com/DamianFKao/operations-blueprint
Try it: damiankao.com/blueprint

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