What I'm Working Toward

Most of this site is a record of work: systems built, decisions made, lessons taken as they happened. This page is the other thing. It is what the work is for. The individual pieces, the engine, the quoting, the feedback loops, only matter if they add up to something larger than one company's software. They do, and the larger thing has been the point from the start. So here it is, plainly, without the hedging.

The gap I keep running into

Almost everything written about operational software, AI in manufacturing, the "smart factory," quietly assumes you are big. It assumes a budget for six-figure systems, an IT department to run them, clean data already sitting in a warehouse, and the standardization that only scale brings. A small manufacturer has none of that. And small manufacturers are not a niche at the edge of the industry. They are the industry: about ninety-nine percent of US manufacturers are small, most of them with fewer than twenty people, and together they hold up a sector that is among the largest economies in the world on its own. The tools that would make them more competitive are built as if they do not exist. I wrote the evidence for that up separately, inthe backbone without the tools.

I did not come to this from theory. I came to it from inside a small manufacturer, trying to build the kind of operation that is supposed to require a team and a budget I did not have, and finding that the off-the-shelf answers all assumed a company that was not the one in front of me. Closing that distance, between what the literature assumes and what a small shop actually has, is the whole job.

What I'm actually trying to do

What I am working toward is closing that gap, not with a product and not for one company, but with a method: a systematic, repeatable way for a small manufacturer to reach the operational capability that large ones buy, using the resources they actually have. The shape of it is consistent regardless of what gets manufactured. Decompose the product into honest data, down to every material, labor second, and overhead dollar. Build one engine that turns that data into pricing, quoting, scheduling, and sales, instead of maintaining each of those by hand. Put real guardrails around the AI so it is trustworthy rather than merely impressive. Wire the feedback loops so the system gets more accurate the longer it runs. Then write all of it down, in the open, so the next operator does not have to rediscover it from scratch.

That last part carries as much weight as the rest. The point is not that I built a good system once. The point is that the way it was built generalizes, and that a careful operator in cabinetry or metalwork or a print shop or a textile line could follow the same path to the same place. The framework is my attempt to make that path explicit and teachable. This site is my attempt to prove it is real, documented while it is still load-bearing, not reconstructed afterward from a safe distance. Theplatform and the build notes are the worked examples; the method they point to is the deliverable.

Why in the open, and why from inside

I do this from inside a working operation rather than from a lab or a consultancy, because I think that is the only place it can honestly be done. The constraints have to be real: live users, no staging environment, a payroll that depends on the thing actually working tomorrow morning. A method that has only ever run in a demo is not a method I would ask anyone to trust.

But the value I am after is not captured by any single employer. A pricing engine helps the one shop that runs it. A published, replicable method for building one helps every shop that reads it. That is the difference I care about, and it is why I keep the methodology open instead of proprietary. It is also why I think of this as a contribution to the sector rather than a position at a company: the work is self-directed, it crosses industries rather than serving one firm's products, and its output is meant to travel. The systems I build are the evidence that the method works. The method, shared, is the part that is supposed to matter to anyone other than me.

What this is not

I should be clear about the boundaries, because the field is full of overclaiming and I would rather not add to it. I am not arguing that small manufacturers should become software companies, or that AI fixes operations on its own. Mostly the opposite. Most of what I write is about the unglamorous foundation, the data work that has to come first, the guardrails, the loops, because that is where the real leverage lives and where the hype is most wrong. The aim is not more technology for its own sake. It is making the right, foundational, often boring technology reachable for the people who have been priced out of it, and being honest about the order the work has to happen in.

What's ahead

It is worth saying plainly where this goes from here, because a method only matters if it actually reaches the people it is for, and most of that is still ahead of me. Some of it is already underway, and some I can start on now. The documenting is the obvious piece: this site, and writing the method down where anyone can follow it. The next step in that direction is to stop describing the method and start handing it over, releasing the reusable parts as open tools and templates a small manufacturer could pick up and use rather than rebuild from a blog post. That one does not wait on anything, so it is the nearest thing on the list.

The larger moves are the ones I am building toward. The first is to work directly with more than one small manufacturer, because a method proven in a single shop is a promising case study, while a method that holds across several different operations is something closer to a real, transferable practice. The second is to teach it: workshops and plain walkthroughs, and partnering with the kinds of organizations that already exist to help small manufacturers, so the method travels further than I could carry it alone. And eventually a more structured way to deliver the whole thing, for the operators who want the outcome without having to become the builder themselves.

I want to be honest that those last few are intentions, not announcements. They are the direction I am positioning to take, not a list of things already running. But the order is deliberate: prove it, write it down, give away the reusable parts, then help others put it to work. The mission is not finished when one company runs a good system. It is finished when the path to one is something a small manufacturer can actually walk.

So this is the lens

If you read the rest of this site, read it through this. The project pages and the build notes are not a portfolio of things I made for an employer. They are the worked examples behind a single, longer-running aim: that the operational intelligence which decides whether a manufacturer can compete should not be something only the largest players can afford. The smaller, more local operations that make up most of the sector deserve a path to it too, and the path can be written down. That is what I am spending my time on, and I think it is worth years.