Damian Kao · Writing & Notes

Build the Expertise Into Each Folder

Sun, 28 Jun 2026 00:00:00 GMT

Open a new session with a coding agent and it begins from nothing. That is not a flaw, it is just how a fresh context works: no memory of yesterday, no idea which corner of which project you are in, no sense of the conventions you have already settled. So you re-explain. You paste the same background, restate the same rules, correct the same small mistakes you corrected last week. For a while I treated that re-explaining as the price of working this way. Then it occurred to me that the price was avoidable, and that the place to avoid it was the filesystem.

I have written before about what an agent actually changes for a solo builder: mostly, it lowers the cost of acting on understanding you already have. The build methodology has its own page; this is the day-to-day around it, the running and more specific version, and it lives in the practice thread. The single idea is this: a folder is not just where files sit. A folder is a context. If you treat each working directory as a small, self-contained workspace, with its own memory, its own skills, and its own conventions, then any agent you start inside it is briefed by the folder rather than by you.

The reason this works is that a folder is already a category. You do not throw every kind of work into one directory. You separate the site from the research notes from the scripts because they are different kinds of work with different rules. Once you accept that a directory is a category of work, the next step is small but it changes everything: give the category its own brain. Each folder accumulates the memory, the procedures, and the standards for one kind of work, and the agent that opens it inherits a specialist, not a generalist starting cold.

What a folder carries

Here is what "briefed by the folder" means in practice, concretely.

Memory, as one fact per file. Each folder carries a small set of memory notes: short, standalone facts about the work done there, each in its own file, each with a one-line description of what it covers. There is an index that lists them. When an agent starts in the folder, it reads the index and pulls in the specific notes whose descriptions look relevant to the task in front of it. The exact format matters less than the discipline: one fact, one file, recall by description. A memory that tries to hold everything gets ignored. A memory that holds one clear thing gets used.

Documentation that says what the work is. At the top of each folder sits a short conventions file, the thing an agent reads first. It is not vague mission text. It says what this directory is for, what categories of task belong here, how the code or content is organized, and the rules that are not negotiable in this folder. It is the orientation a new teammate would get on their first day, except the teammate is a fresh agent and the first day is every session. An agent that reads it knows where it is and what is expected before it touches a single file.

Skills, as the procedures that repeat. A skill is a written procedure the agent follows: the steps for a recurring job, the order to do them in, the checks at the end. The ones that earn their place are the jobs I would otherwise re-describe every single time. Turning a rough draft into this site's diagram format. Generating a batch of files the same way each time. Building and checking a release before it ships. The skill is not magic. It is the thing I would have said out loud, written down once so I never have to say it again.

Git, and a session you can resume. Two things keep the folder from forgetting between sittings. The first is version control: the work is in git, but so, increasingly, is the configuration around it, the memory and the conventions, which means the folder's expertise has a history you can read and roll back like any other code. The second is the session itself. When I open the editor back up in a folder, the agent does not just see the files. It can pick up the thread of the last conversation we had there: what we were doing, what we decided, what was left unfinished. A cold start in a folder is rarely cold. It resumes.

The write-back loop. This is the part that makes the whole thing compound. When the agent gets something wrong, the fix is not only the edit in front of me. The correction goes back into the folder: a new memory note, a tightened rule in a skill, a guard in the code so the mistake cannot recur. The principle I hold to is that a correction should only happen once. Done consistently, the folder gets a little smarter every time I work in it, and the next agent inherits all of it.

Scoped, but not bound

It would be easy to hear all of this as "lock each agent in its folder," and that is the opposite of what happens. The folder is a base of operations, not a cage. Skills in particular live at a level above any one directory: they are globally available, and globally buildable, so a procedure I wrote while working in one folder is there for me in all of them. An agent based in the site folder can still reach into the research folder when a task crosses over. What the folder gives is a center of gravity, a place where one kind of work is most at home and most practiced, without walling that work off from everything else. You get local expertise and global reach at the same time, which is exactly the combination a single global config never manages.

That is the decision underneath all of this: scope context to the filesystem instead of to one global configuration. I could put everything in a single place that every session loads. I tried versions of that, and it does not hold up. A global config grows into a pile that is mostly irrelevant to whatever I am doing right now, and irrelevant context is not neutral. It is noise, and noise makes the agent worse. Scoping by folder keeps each context small and local. The rules for the site do not leak into the research notes; one project's conventions do not bleed into a throwaway script. And because the context travels with the directory, a fresh agent that opens the folder is competent there right away, not after a paragraph of setup, but on the first message.

You are the orchestrator

Once each folder is a competent base, you are no longer limited to one agent at a time. This is where working in the editor, on the files, pulls ahead of the chat-app version of the same tools. You can run several agents in succession, handing each a piece. You can run more than one in the same folder at once, on different items. You can run them across folders at the same time. You can even point two at the same problem, let them try it different ways, and keep the better result.

But it is worth being exact about what makes that work, because it is easy to picture it wrongly. These agents are not off running themselves while I watch a dashboard. I steer every one of them, on every task, and correct them as they go. They are extensions of me, which means the cohesion does not come from some clever arrangement that makes them cooperate on their own. It comes from me. Whether they run one at a time or several at once, at what pace, on what, and in what order, is a function of how much direction I can give and how much work I have to hand them. I am the orchestrator, and that is not a role I can pass off, because the thing being distributed is my intent, and I am the only one who has it.

So where does the work log fit? Not as the thing that coordinates them. The agents do not report to it the way employees file status to a manager who then runs the floor. The log is a record. Every finished piece of work leaves one line in it: which folder, which machine, what kind of work, what changed, what is still open. I keep it because at the end of a stretch I can read one log and see the whole shape of what has been done, across every folder, which is what lets me plan the next stretch and decide what the business actually needs. It is also how the folders get better: the patterns I notice in the log become new skills, tighter conventions, a sharper sense of what belongs where. The log informs the system. It does not drive it.

There is a lot more to say about that log, about recording the work itself and staying honest about what actually shipped. That is its own piece, and I will write it. Here it is enough that the record exists, and that I am the one who reads it.

So the leverage is not in automating the work away. It is in lowering the cost of moving what I want into a form an agent can act on. I can build skills, shortcuts, and small programs that make that handoff faster and more reliable, and I do. But it never collapses into a task list I set running and walk away from. The bottleneck, and the skill actually worth getting good at, is me: how clearly and how efficiently I can direct a group of capable agents that are only ever as coordinated as I make them.

It travels

Here is the part that surprised me most. Because a folder's context is just files, memory notes and a conventions file and the rest, it is portable. Put those folders on a shared drive, a Google Drive or anything like it, and the expertise stops living in one person's head or on one person's laptop.

Someone else on the team who wants to set up their own agents does not start from zero. They open the same folder and inherit its memory and its conventions, the accumulated understanding of how that kind of work gets done here. Maybe the heavier custom skills stay mine, at least at first. But the memory and the configuration, the part that is hardest to reconstruct and easiest to lose, is right there for them, and they carry on from where the folder is rather than from where a blank agent would be. A folder that began as my way of not re-explaining things to an agent turns out to be a way of not re-explaining things to a colleague either.

The editor and the app

None of this is an argument that the editor is the only place to use an agent. The desktop and web apps are genuinely good at something different: quick, uniform, research-and-documentation work, where you want a clean conversation, a consistent set of built-in tools, and a tidy artifact at the end. When I want to think something through or produce a one-off document, that is often the better room to be in.

But for day-to-day work where the work is files, where the output is code and content that has to live somewhere, get committed, and be picked up again tomorrow, the folder-and-editor approach is far more practical. The context is the directory, the history is in git, the results land in the registry, and tomorrow's session resumes today's. The two are not rivals so much as different tools for different shapes of work. The trick is knowing which shape you are holding.

What this asks of you

What this asks of you in return is discipline, and it is the unglamorous kind. The setup only learns if you actually feed it: write the correction back instead of just fixing the line, prune the memory that has gone stale, and notice when a skill has drifted away from how you really work now. Skip that and you get the worst of both worlds, a folder full of confident, outdated instructions that an agent will follow straight off a cliff. The structure does not maintain itself. It is closer to a garden than a machine.

And the more agents you run, the more a second discipline matters: coordination. It is genuinely possible to start more work than you can review, to let the registry fill with results you have not actually checked, to mistake motion for progress. Running many agents well is not the same as running many agents. The whole approach rewards the person who can hold the system in their head and direct it, and it quietly punishes the person who just turns everything loose.

If you want to try it

Do not build the whole thing at once. Start with one folder, the one you work in most. Give it a single memory file for the fact you are tired of repeating, and one skill for the job you are tired of explaining. Then let it grow the way mine did, from real corrections: every time you catch yourself saying the same thing twice, that is the signal to write it down where the folder can keep it. Only once one folder is clearly paying you back is it worth adding a second agent, a registry, a shared drive. The order matters. The expertise comes first; the orchestration is what you build on top of it once there is expertise worth orchestrating.

This is the quiet shift the practice is really about. The agent is not just a tool you reach for. The configuration around it, the folders and what they carry, the record you keep of them, the drive they live on, is itself something you build, with the same care you would give the software it helps you build. And like that software, the value is not in any one session. It is in what each session leaves behind for the next, and increasingly, for the next person.

The Backbone Without the Tools

Sun, 28 Jun 2026 00:00:00 GMT

There is a fact about American manufacturing that almost everyone gets backwards, and once you see it, the way AI is arriving in the sector starts to look like a problem rather than a triumph. Here it is: manufacturing is enormous, and it is overwhelmingly small. Both things are true at once, and the tension between them is where this piece lives.

Start with the size, because it sets the stakes. US manufacturing adds on the order of two-point-nine trillion dollars of value a year, about ten percent of GDP, and employs roughly thirteen million people. Taken on its own it would rank among the largest economies in the world. And it pulls more than its own weight: every dollar of manufacturing activity generates an estimated two dollars and sixty-nine cents in total economic output, one of the highest multipliers of any sector. When people say manufacturing is load-bearing for the economy, this is what they mean. It is not nostalgia. It is arithmetic.

Now the part that gets forgotten. That enormous sector is not mostly made of giants. Of the roughly 239,000 manufacturing firms in the United States, only about 4,000 have 500 or more employees. The other ninety-nine percent are small. Around three-quarters of all manufacturers have fewer than twenty people. These are the machine shops, the cabinet makers, the metal fabricators, the print and textile and ceramics operations in every county in the country. They are the backbone in the most literal sense: take them out and there is no sector left to talk about. Small businesses broadly tell the same story, having generated fifty-five percent of net new jobs over the decade to 2023. The economy runs on small operations far more than the headlines about a handful of large firms suggest.

So here is the question this piece is about. If small manufacturers are most of the sector, and the sector is this important, what happens when the technology that increasingly decides who stays competitive arrives mostly for the large ones?

The gap is real, and it is widest at the bottom

The technology in question is operational AI: not chatbots, but the systems that price work accurately, schedule a floor, catch an estimate before it loses money, keep a catalog current, and turn production data into better decisions. This is the capability that has quietly separated efficient manufacturers from struggling ones, and AI is now the lever that widens the difference.

Adoption is sorted by size, and sharply. The Census Bureau, which has been tracking AI use across hundreds of thousands of firms, found that by early 2026 about thirty-seven percent of firms with 250 or more employees were using AI in their operations, compared with under twenty percent of the smallest firms. Earlier in the cycle the gap was even wider: in early 2024 large firms were adopting AI at roughly one and a half to two times the rate of small ones. The encouraging reading is that the overall gap has narrowed as cheap tools spread. The honest reading is that the narrowing is happening fastest among firms that already have some scale, and that the very smallest operations, the ones that are most of manufacturing, are still the furthest behind.

It is worth being precise about why, because the reason is not that small manufacturers are slow or unwilling. The reason is structural, and I have written about it at length in why small manufacturers can't just use enterprise AI. The short version: the tools that deliver this capability are built for the conditions large companies have and small ones do not. They assume clean, standardized data already exists. They assume a budget that runs to five and six figures a year. They assume an IT team to run them and a process discipline that only scale tends to produce. A thirty-person shop has none of those, so the enterprise tool does not fail loudly, it simply never fits, and the capability stays out of reach. The gap is not a preference. It is a mismatch between how the tools are built and how most of the sector actually operates.

Why this is a national problem, not a private one

It would be easy to file this under "some businesses modernize faster than others" and move on. That would be a mistake, because the consequences do not stay inside the firms that fall behind. They add up to problems the whole country has a stake in.

Competitiveness. Small US manufacturers do not only compete with each other. They compete with large domestic firms and, more pointedly, with overseas producers who are adopting automation aggressively. A small manufacturer that cannot price accurately, cannot keep its catalog current, and cannot learn from its own production data is not on a level field. Multiply that disadvantage across the ninety-nine percent of the sector that is small, and you are looking at a slow erosion of the country's industrial base, one shop at a time, in a way that no single closure makes dramatic but the sum of which is exactly the kind of decline that is hard to reverse once it sets in.

The workforce cliff. Manufacturing is staring at a labor shortage that is already arriving. Deloitte and the Manufacturing Institute estimate that as many as 2.1 million manufacturing jobs could go unfilled by 2030, at a potential cost of one trillion dollars in that year alone, with most manufacturers already reporting ongoing difficulty attracting and keeping workers. This is precisely the problem that accessible automation addresses: not by replacing people, but by letting a small shop do more with the people it can actually hire, automating the repetitive estimating, cataloging, and back-office work that currently eats skilled time. The firms that get that capability will absorb the shortage. The firms that do not will feel it as a ceiling on everything they try to do.

Supply-chain resilience. The last few years taught the country, expensively, that concentrated and distant supply chains are fragile, and that bringing production closer to home reduces risk. Small and medium manufacturers are the natural backbone of a more resilient, more domestic supply chain, which is why supporting them is a long-standing federal priority rather than a private concern. The Commerce Department runs the Manufacturing Extension Partnership specifically to strengthen smaller manufacturers, through a network of roughly 1,400 advisors at more than 450 locations, with supply-chain resilience and reshoring as explicit goals. The public interest in small manufacturers being capable and competitive is already on the record. What is missing is the operational tooling reaching them at the same level the policy attention does.

This is also where the scope of the problem resolves cleanly under the way national importance actually works. The impact does not have to be uniform across the whole country to count. A single small manufacturer is a local story: a few dozen jobs, a regional supplier, one town. But the pattern repeats in every region, and the patterns add up. Help one shop reach operational capability and you have helped a town. Make the method by which any shop can reach it, and you have touched the part of the economy that most of the country actually works in. Local impact, repeated at the scale of ninety-nine percent of a sector, is national impact.

What closing the gap actually requires

If the problem were just price, the market would have solved it already, because cheap AI tools are everywhere now. The reason the gap persists is that the missing piece is not a cheaper tool. It is a method.

The capability large manufacturers buy as a stack of expensive systems is not, at its core, about the software. It is about a sequence: decompose the product into honest data, build one engine that turns that data into pricing and quoting and scheduling, put guardrails around the automation so it can be trusted, and wire feedback loops so the system corrects itself over time. A small manufacturer cannot buy that sequence. But they can follow it, with the modest, self-hostable tools they can actually afford, if someone has mapped the path and shown that it holds up in a real operation rather than a slide deck.

That is the entire reason I do the rest of the work on this site the way I do it. The framework is an attempt to make that path explicit and teachable, industry-agnostic on purpose, because the underlying move, turning a decomposed product into the foundation everything else runs on, is the same whether you make cabinets or circuit boards. And the path is not theoretical. Two concrete results from running it: a product catalog that took the better part of a month to maintain by hand now regenerates from live data in about a day, and a cutting-layout optimizer that lifted material utilization from roughly 31% to around 79%, which is the kind of efficiency gain that decides whether a small shop's price is competitive. Those are not enterprise budgets at work. They are the method at work.

The point

So the situation, stated plainly, is this. The largest part of one of the country's most important sectors is being left on the wrong side of the biggest operational shift in a generation, not because those manufacturers are unwilling, but because the tools were never built for them. The cost of leaving that gap open is not abstract: it is competitiveness lost to overseas producers, a workforce shortage met with a ceiling instead of leverage, and a supply chain that stays more fragile than it needs to be.

The cost of closing it is mostly a matter of making the method reachable, which is a problem of documentation and proof more than of invention. That is the part I think is worth working on, and it is what this whole site is ultimately for. The backbone of American manufacturing should not be the part of it that cannot afford to keep up. The tools exist. The method exists. What is missing is the bridge between them and the ninety-nine percent, and that bridge can be built.

Sources

Facts About Manufacturing · National Association of Manufacturers (sector GDP, employment, multiplier, firm-size distribution; drawing on US Census Statistics of US Businesses).
AI Use in Businesses · US Census Bureau (AI adoption by firm size, Business Trends and Outlook Survey).
Monitoring AI Adoption in the US Economy · Federal Reserve (large-vs-small adoption rates over time).
2.1 Million Manufacturing Jobs Could Go Unfilled by 2030 · Deloitte & The Manufacturing Institute (workforce gap and cost).
Small businesses contributed 55% of net job creation, 2013–2023 · US Bureau of Labor Statistics.
Manufacturing Extension Partnership and MEP Supply Chain · NIST (federal support for small manufacturers; reshoring and supply-chain resilience).

Catalog Automation: From Weeks to One Day Across Ten Product Lines

Fri, 26 Jun 2026 00:00:00 GMT

If your business sells across more than a handful of product lines, you almost certainly keep a catalog of some kind: a big reference document, or a set of them, that lists every product, its specs, its dimensions, its options, and what it costs. And if you are honest about it, that catalog is probably out of date right now. Not because anyone is lazy. Because keeping it current by hand is a genuinely large job, and the moment you finish, a price moves or an item goes out of stock and it starts drifting again.

This is the unglamorous bottleneck I want to walk you through, because it is more expensive than it looks and because the fix is a good example of a pattern you can use far beyond catalogs. The manufacturer I build for maintains a product reference across about ten product lines. Keeping it accurate by hand was costing roughly three to four days of careful work per product line. Across the whole set, that is the better part of a month of analyst time for one refresh, and it had to happen again every time the underlying products changed. After the work I am about to describe, a full refresh takes about a day, and it is current by construction rather than by effort. Here is how, and more importantly, how you would do the same thing.

Why the hand-kept catalog quietly costs so much

Start with what maintaining a catalog by hand actually involves, because the cost is hidden in the details. You are not just typing. For each product line you are reconciling several sources at once: the current spec for each item, the current price, what is actually in stock, the dimension drawings, the option lists, the finishes. Each of those lives somewhere else, and a person has to go find the latest version of each, decide which is right, and transcribe it into the catalog. Do that across ten product lines and you have a multi-sheet workbook with thousands of cells, every one of which is a small opportunity to be wrong or out of date.

Then notice the second cost, the one that does not show up on a timesheet. A catalog that takes weeks to refresh does not get refreshed often. So it is stale most of the time, which means the people who rely on it, sales, customers, whoever, are working from numbers that quietly stopped being true. For a small manufacturer this is a real competitive problem. The large e-commerce sellers you are up against keep their catalogs fresh automatically, because their catalog is just a view of their live data. Yours is a document someone maintains. That gap, days of analyst time versus none, is exactly the kind of thing that keeps smaller operations a step behind, and it is worth closing. It is also a small instance of a much larger pattern, the one where the smaller manufacturers who make up most of the sector keep getting left behind the tools, which I wrote about in the backbone without the tools.

The decision: stop maintaining the catalog, start generating it

Here is the reframe, and it is the whole piece in one sentence. A catalog is not a document you should be editing. It is a view of data you already have. Your products already exist as records. Your inventory already exists as live data. The catalog is just those facts, arranged and formatted. So the move is not to find a faster way to hand-edit the catalog. It is to stop hand-editing it at all, and generate it from the live source every time you need it.

If you have read the framework I work from, this is the same thesis applied to one artifact: once your product is decomposed into real data, the things above it, pricing, quoting, and yes, the catalog, become functions of that data rather than things you maintain separately. The catalog was the most visible place that promise had not yet been kept, so it was a good place to keep it.

How it actually works

The build has three parts, and the order matters, because the third part is what makes the first two trustworthy enough to rely on.

First, generate from the live source. Instead of a person curating each product line, a generator pulls the current product data and the newest inventory snapshot directly from where they already live, merges in the specs and naming that genuinely do need human curation, and emits the catalog, both the working reference and the print-ready version. The pricing and stock are never transcribed; they are read from the source at generation time. Run it, and you get a catalog that matches reality as of a minute ago instead of as of whenever someone last had a free afternoon.

Second, separate the two kinds of catalog content. This is the subtle part, and it is why "just automate it" is not enough on its own. Some of a catalog is derived (price, stock, dimensions, the parts that come straight from data) and some of it is curated (the carefully written description, a cleaned-up product name, the things a human decides). If you regenerate everything, you blow away the curation every time. So the generator keeps the curated layer separate and merges it in, which means a regeneration refreshes all the derived facts without touching the human judgment. You get freshness and craft, not one at the expense of the other.

Third, and most important, make it auditable. A generated catalog is only useful if you trust it, and trust comes from being able to answer "where did this number come from, and when was it last true." So every field carries its own provenance: which source it came from, when it was first seen, when it was last verified, and when it last changed. There is a sources list, and an append-only changelog that records every field-level change over time. This is the part that turns automation from a black box into something you can actually stand behind. When a customer asks why a spec is what it is, you are not guessing. The catalog can tell you.

That third piece is the one most people skip, and it is the one I would tell you not to skip. The same discipline shows up everywhere I build: a result you cannot trace is a result you cannot defend, which is the entire argument of why you cannot just ask an AI for a quote. A generated catalog without provenance is just a faster way to publish numbers you cannot vouch for.

The part that was actually hard

If you take this on, the hard part is not the part that sounds hard. Pulling live data and formatting it into a catalog is routine work. The genuinely tricky piece is the boundary between the derived facts and the curated ones, and what to do when they disagree.

Here is the situation that forces the issue. The live source says a product's dimension is one thing; the curated spec a person wrote last quarter says something slightly different. Which one wins? You cannot just always take the live value, because sometimes the person caught something the source data has wrong. And you cannot always keep the curated value, because then you are right back to a stale snapshot. The answer is not a clever rule that decides automatically. It is to make the disagreement visible. The changelog records that a field changed and what it changed from, so a person can glance at the diff and make the call, instead of the system either silently overwriting good judgment or silently preserving bad data.

That is the real lesson hiding inside a catalog automation, and it is worth more than the time saving. Automating the easy ninety percent is worth doing, but the value lives in how you handle the contested ten percent. A system that hides its conflicts is one you stop trusting the first time it is confidently wrong. A system that surfaces them is one you can actually hand the work to and walk away.

The result

A refresh that took roughly three to four days of hand-work per product line now takes about a day for the whole catalog, across all ten lines. But the time saving is honestly the smaller half of the win. The larger half is that the catalog is now current by default. It is no longer a document that decays between heroic manual updates; it is a view that reflects the live product and inventory data whenever it is generated, with a full audit trail of how every value got there. The analyst days that used to go into transcription go into the work that actually needs a human instead.

And notice what this is an instance of. The catalog stopped being a thing the business maintains and became a thing the business produces, on demand, from data it already has. That is the same move as turning a hand-built quote into a calculated one, or a hand-kept report into a generated one. It is the document-generation layer of the platform doing what it is for: assembling what reaches the outside world from the system, instead of having someone rebuild it by hand each time.

What this means for you

If you maintain any document by hand that is really derived from data you already have, a catalog, a price list, a spec sheet, a capabilities deck, you are sitting on the same opportunity. The instinct is to make the editing faster: a better template, a cleaner spreadsheet, a part-time hire. Resist it. The faster editing still leaves you with a document that is stale the moment you stop typing.

Do this instead. First, find where the real data already lives, and accept that the document should be a view of it, not a copy. (If the data does not exist in clean form yet, that is your actual first job, and I wrote about why the boring data work comes before everything.) Second, split the derived parts from the curated parts so regenerating never destroys the human work. Third, give every value provenance, so the output is something you can trust and trace, not just something you can produce quickly. Get those three right and the document stops being a chore you fall behind on and becomes a button you press.

The weeks-to-a-day number is the headline, and it is real. But the thing worth taking away is quieter: most of the documents you maintain by hand are snapshots of data you already have. You do not need a faster way to keep the snapshot current. You need to stop keeping a snapshot at all.

Why SME Manufacturers Can't Just Use Enterprise AI Tools

Fri, 26 Jun 2026 00:00:00 GMT

There is a comfortable story going around about AI and small manufacturing. It goes like this: the tools exist now, they are getting cheaper and better every month, so a small manufacturer who wants to modernize just has to adopt them. Buy the platform, connect it up, catch up to the big players. The gap closes on its own.

If you run or build for a small or mid-sized manufacturer, you already suspect this is not how it goes, and you are right. The tools mostly do not fit, and the reason they do not fit is structural, not temporary. It will not be fixed by the next model release. I want to walk through why, because the mismatch is worth understanding clearly, and because it matters well beyond any single shop. Small and mid-sized manufacturers employ a large share of the people who make things in this country. When the operational tooling that makes a manufacturer efficient is available to the largest players and out of reach for everyone else, the gap that opens up is not a local inconvenience. It is a slow erosion of who can compete.

What "enterprise AI" quietly assumes

The first thing to understand is that enterprise manufacturing software, AI or otherwise, is not really a product you buy. It is a project you staff. And it is built on a stack of assumptions that are true for a large manufacturer and false for a small one. Walk through them and you will recognize your own situation in the gaps.

It assumes clean, structured data already exists. Enterprise tools are designed to sit on top of an ERP that already holds your products, your bills of materials, your costs, your inventory, in clean, structured form. That is the input they need to do anything useful. A large manufacturer has spent years and a lot of money building that foundation. A small one usually has its real product knowledge spread across spreadsheets, file names, a few key people's memory, and a pricing sheet someone updates by hand. The tool assumes the hardest and most expensive part of the work is already done. For you, it is the part that has not been started.

It assumes a team to run it. Enterprise software comes with an implicit org chart: an IT department to integrate it, analysts to operate it, a project manager to drive adoption, and budget for the consultants who do the configuration. The software is the small part. The people around it are the real cost. A small manufacturer does not have that team. Often the person evaluating the tool is also the person who would have to implement it, operate it, and still do their actual job. A tool that needs a department to run it is not a tool for a company that does not have one.

It assumes standardization, and you are custom. This is the deepest mismatch. Enterprise tooling is built to optimize scale: the same product, made the same way, thousands of times, where a one percent efficiency gain is worth millions. A lot of small manufacturing is the opposite. It is custom, configured, low-volume, every job a little different. The enterprise tool wants you to have a fixed catalog of standardized products; your business is that no two kitchens, or jobs, or runs are quite the same. You can sometimes force your operation to look like what the tool expects, but you are deforming the business to fit the software, which is exactly backwards.

And it assumes a budget that prices you out anyway. Even if all of the above were solved, the pricing is built for enterprise procurement. Per-seat licenses, annual contracts, implementation fees. The tools that large manufacturers use for the knowledge layer, the analytics, the configure-price-quote engines, run from thousands to tens of thousands of dollars a year each, before the people. That math works when you are large. It does not when you are not.

Why this is a sector problem, not just yours

Put those four together and you get a quiet, structural exclusion. The operational intelligence that makes a manufacturer faster, more accurate, and more responsive, the ability to quote in minutes instead of days, to keep a catalog current automatically, to learn from every completed job, is increasingly available to the manufacturers who were already large enough to afford the foundation it sits on. Everyone else is told to wait, or to buy a tool that does not fit, or to keep doing it by hand.

That is not a fair fight, and it is not only the individual shop's problem. The manufacturers being left out are not a rounding error; collectively they are a huge share of domestic industrial output and the workforce it sustains. They are also the ones competing against large overseas operations that do have the tooling. When the efficiency gap between a small domestic manufacturer and its larger competitors widens because of access to software, the thing being slowly lost is not one company's margin. It is the viability of small-scale, domestic, custom manufacturing as a place to build a business and a career. Closing that gap is worth doing for reasons that go well past any one factory.

But aren't the tools getting cheaper?

The obvious objection is that this is just a timing problem. The tools are getting cheaper and easier every month, no-code is lowering the bar, so even if enterprise AI does not fit a small manufacturer today, surely it will soon. Just wait a year or two.

It will not solve itself, and it is worth being precise about why, because the reasoning is the whole point. Cheaper models and friendlier interfaces lower the cost of the tool. They do nothing about the assumptions underneath it. A cheaper AI still needs clean, structured product data to reason over, and a small manufacturer still does not have it. A friendlier interface still assumes someone has modeled the business, and nobody has. No-code still expects standardized processes to point it at, and the work is custom. The price of the software was never the binding constraint. The missing foundation was. Drop the tool's price to zero and you have a free tool sitting on top of nothing, which is worth about nothing.

So "just wait for the tools to get cheap" is quietly bad advice. The waiting does not build the thing that was actually missing. Every month you spend waiting for the tool is a month you could have spent decomposing your product into real data, which is the part no tool will ever do for you, and the part that makes every future tool actually work. The cheap, capable tools that exist now are a reason to build the foundation today, not a reason to keep postponing it.

The mismatch is the clue to the fix

Here is the useful part, because diagnosing the problem also points at the answer. Every one of those four assumptions fails in the same direction: enterprise tools assume the foundation is already built, and a small manufacturer's reality is that it is not. So the move is not to find a cheaper enterprise tool, or to wait for one. It is to build the foundation in a way that fits how a small operation actually works, and then let the AI sit on top of that.

Concretely, that means three reversals of the enterprise approach. Instead of assuming clean data, you do the unglamorous work of decomposing your product into real data first, because the intelligence is only ever as good as the data underneath it. Instead of buying a monolithic platform that needs a team, you build up in small, owned pieces, using AI agents wrapped in the right harnesses, so the system can be run by the people who are already there. And instead of forcing your custom work to look standardized, you model the customization directly, because once the product is decomposed, everything above it becomes a function of that data whether the product is standard or one-of-a-kind.

That is the entire idea behind the methodology I build and write about: not a product to sell you, but a replicable, accessible path that a small manufacturer can actually walk, with the tools that are genuinely cheap now (capable AI models, open-source infrastructure) instead of the enterprise stack that is not. It is the same operational intelligence the big players buy, built up from the ground a small operation actually stands on.

What to do if this is you

If you are a small manufacturer looking at the AI wave and feeling like you are supposed to buy something, here is the more useful instruction. Do not start by shopping for tools. Start by asking whether you could hand your product to a stranger and have them arrive at a correct price from your documentation alone. If the answer is no, no tool will save you, because every tool is going to assume that foundation exists. Build it. Decompose one product line until the data is real. Then add the cheap, capable AI layer on top, and you will have, for very little money, the thing the enterprise tool was quoting you tens of thousands of dollars to pretend to give you.

The gap between small manufacturers and the tooling that would make them competitive is real, and it is widening. But it does not close by buying the enterprise tool. It closes by refusing the premise that you have to, and building the foundation the right way for the operation you actually run. That path is open to far more manufacturers than the expensive one ever will be, and that is exactly why it is worth documenting in the open.

Why You Can't Just Ask AI for a Quote

Thu, 25 Jun 2026 00:00:00 GMT

Here is something that looks completely reasonable and is not. You have a spreadsheet of your prices, a few notes on what materials tend to cost, and a takeoff list for a project, say the interior build of a house. You paste all of it into a capable AI model and ask it to research the rest and give you a quote. A short while later you have a beautiful document: itemized, formatted, confident, the kind of thing you would be happy to send a client. And you have almost no way to know whether the number at the bottom of it is anywhere near right.

That is the part worth sitting with. It is not that the quote is obviously bad. It is that it is quietly, possibly badly wrong, and it does not look wrong at all. If you are going to use AI for anything where the answer has to be correct, not just plausible, this is the trap to understand first, because almost everyone walks into it.

Why the pretty quote is lying to you

Think about what the model would actually have to know to produce that quote correctly. The real labor for every component, not the average but the specific. The contingencies. The things that routinely go wrong on a build and the cost of absorbing them. How the hardware fits together, what goes with what, what cannot. Inventory pricing that already accounts for shipping. The order of operations, and what each step depends on. That is an enormous, specific, interconnected body of knowledge about your operation, and the model does not have it. It has a general sense of how things like this tend to go.

And some of what it is missing is not just specific, it is structurally invisible to a spreadsheet of averages. Take inventory pricing. The real cost of a material is rarely its list price. It is the list price plus shipping, and shipping depends on the quantity you order, the supplier you order it from, and when. Or take contingencies: the offcut you will waste, the panel that arrives damaged, the step that has to be redone because the one before it was done wrong. An experienced estimator carries all of that quietly in their head and pads the number to match. The model has no idea any of it exists, so it quotes the clean, frictionless version of the job, the one that never actually happens.

So when you ask it for a number, it does the only thing it can. It fills every gap with a plausible average and hands you the result with total confidence. The quote is not a calculation. It is a very articulate interpolation between things the model has seen before, dressed in the format of a calculation. And the dressing is the dangerous part, because a confident, well-formatted document reads as authoritative whether or not anything underneath it is true.

You might think you can fix this by being more careful with the prompt. Break the job into steps. Feed it more context each turn. Chain the prompts together so each one handles a piece. It helps a little, and it does not solve the problem, because every handoff between steps loses information and every step adds a little noise, and by the end you have compounded a dozen small distortions into one clean-looking total. The failure mode here is not the gibberish you can catch and laugh at. It is a professional document that is over- or underpriced by a margin you cannot see. Sometimes, by luck, it even lands close, which is the worst outcome of all, because it teaches you to trust the machine that produced it.

If you have worked with these models for a while, you already know the texture of this. The failure is not that the model breaks. It is that it is confident and plausible and sometimes simply wrong, and you cannot tell which from the surface.

A model is only as good as what you give it to work with

Here is the thing people keep getting wrong, and it gets more wrong, not less, as the models improve. A more sophisticated model does not fix this. No matter how good the model is, no matter what it was trained on, it is only ever as good as the harnesses, context, knowledge bases, tools, and data it can actually reach, plus how well it knows how and when to use them. A frontier model with a bare prompt is a brilliant guesser. The same model wired into real tools is a different thing entirely, and the difference is not the model. It is everything you built around it.

The leverage, in other words, was never in the prompt. It is in the harness. This is the same point I make about the systems themselves: the intelligence is only as good as everything underneath it, which is exactly why you build the intelligence last and the foundation first.

Put it bluntly: the model's job is to be smart about the things that genuinely need judgment. It is not the place your facts should live. The moment you ask it to recall a labor rate or a material cost, you have handed a lookup to a thing that does not look anything up. It predicts. Prediction is wonderful for language, and it is exactly the wrong instrument for a number that has a single right answer sitting in a database you already own.

What a real quote actually requires

So what does the other path look like? Let me walk you through it with cabinetry, because that is what I build, but the shape of it transfers to anything that has to be priced for real.

Start with the rule that everything else follows from: you do not let the model estimate the things you can measure. You build the parts that measure them.

Labor. You do not ask the model how long the work takes. You build components that track and measure labor directly, so the number in the quote comes from something that recorded it, not from something that guessed at it. The model can reason about the result. It does not get to invent it.

Materials. You do not let the model imagine the bill of materials. You build the parts that track materials properly: which materials go into a given item and in what ratios, how much of each is actually used, how the items are organized and sorted, which ones belong to which room. The bill of materials is computed from the product, not narrated from a vibe. That distinction is the whole game.

Installation, build, and hardware. You account for what the install actually involves, what pieces go together and what pieces do not, the compatibility rules between components. These are constraints, and constraints are precisely the thing a free-form model is worst at respecting and a small piece of deterministic code is best at. A model will happily quote two parts that cannot physically coexist. A check will not.

The things that quietly eat the margin. The parts that are easiest to forget get encoded too, because those are the ones that turn a profitable job into a loss. The waste built into how material is cut and nested. The rework when a step depends on one that changed. The cost of an order that has to ship in two batches instead of one. You do not ask the model to remember these, because it will not. You build them into the system that produces the number, so they are accounted for every single time instead of whenever someone happens to think of them.

Once those pieces exist, the agent's job changes completely. It is no longer the thing that knows the answer. It is the thing with the context to use each of these tools and databases to arrive at the answer. The reasoning is genuinely the model's. The facts are looked up and computed. That division of labor is the entire point, and it is why the systems I build are so heavily agentic and, at the same time, wrapped in so much programmatic search, structured data, and calculation.

And even then you are not done, because a system that produces money figures for real customers cannot be allowed to be creative about it. You document what it produced. You build templates and blueprints so the same kind of quote comes out the same way every time, instead of being re-derived from scratch and drifting. And you wrap the whole thing in safety procedures and guardrails, the checks that catch a number before it reaches a customer rather than after. None of that is glamorous. All of it is the difference between a number you can defend and a number you are hoping is right.

Stop trying to make the model smarter

If you take one practical thing from this, take this: when you need AI to be correct rather than merely convincing, stop pouring your effort into better prompts. You cannot out-prompt a fact the model does not have. Spend that effort instead on giving it real tools, real data, and real calculations, and on teaching it how and when to reach for each one. The model is the reasoning glue. The harness is where the truth lives.

That is the whole reason the systems I build look the way they do. Very agentic, yes, but the agent is surrounded by programmatic searches, structured databases, deterministic math, documented procedures, and guardrails. The agent decides what to do. The harness makes sure what it does is grounded. None of this is exotic, and all of it sits downstream of two earlier disciplines: decomposing the product until it can explain itself, and doing the boring data work before the intelligence layer. Get those right and the agent has something solid to stand on. Skip them, and no amount of model quality will save the quote. If you want to see what the harnessed version actually produced, I wrote about what I built and the platform it became.

The test to carry

So here is how you tell the two apart, and it takes about ten seconds. Pick any number in the quote and ask where it came from. If the answer is "a tool that measured it or computed it," you have a quote. If the answer is "the model decided it seemed about right," you have a confident guess in a nice font, and you are one unlucky job away from finding out which.

The pretty document was never the proof. It is the easiest thing in the world for a model to generate and the most expensive thing for you to trust. The work is not getting a better-looking answer. The work is making sure that when the answer looks right, it is right, because something underneath it actually did the math.

What I Built Inside a Live Company

Wed, 24 Jun 2026 00:00:00 GMT

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.

Teaching It Once

Wed, 24 Jun 2026 00:00:00 GMT

The first time your agent makes a mistake, you fix it. The second time it makes the same one, that is on you.

If you work with an AI agent every day, you already know the honest texture of it: it is confident, and occasionally confidently wrong. More often it just makes a perfectly reasonable call that is not how you would have done it. Early on you will treat each of those as a one-off. Spot it, correct it, move on. Then you will hit the same thing a week later and correct it again, and you will be paying full price every time for something you could have bought once.

The change that matters is not a cleverer way of asking. It is deciding that every correction has to leave something behind. A preference becomes a saved memory the agent reads next time. A rule about how you want things done becomes a standing instruction in its configuration. A mistake worth never repeating becomes a guard sitting right next to the code that invited it. A chunk of recurring production, the same kind of document built the same way again and again, becomes a small skill, so you describe it once and reuse it instead of re-explaining. At some point even the daily work log stops being something you keep by hand and becomes a routine that runs when a session ends and writes itself.

So treat the agent's configuration the way you treat your codebase: something you version and improve, not a black box you re-explain to every morning. Corrections are not interruptions to the work. They are how the tool gets sharpened.

The leverage, it turns out, was never in the prompt. It is that corrections compound. A generic assistant slowly becomes one shaped to how you actually work, and almost all of that shaping is just a refusal to solve the same problem twice.

So if you are using one of these and you catch yourself re-explaining the same preference, that is the signal. Do not just fix it in the moment. Write it down somewhere the agent will read it next time. A companion is not the model. It is the accumulated residue of every correction you bothered to make permanent.

Building Inside a Live Company

Tue, 23 Jun 2026 00:00:00 GMT

I want to start with something I find a little embarrassing, because it took me much longer to understand than it should have.

Almost everything written about building software assumes a set of conditions I have never actually had. A clean slate. A team to catch the things you miss. A staging environment nobody depends on, where you can break whatever you want at two in the morning and the only casualty is your own sleep. The freedom, when you get down to it, to be wrong in private until you have figured out how to be right. I read that kind of advice for years and quietly assumed it applied to me, the way you assume a recipe applies to your kitchen. It mostly doesn't. What I have instead is a running company, and the gap between those two situations has turned out to be most of the story of how I actually build.

The software I make is in use every day by people who are not engineers and did not sign up to be test subjects. They have quotes to send, orders to push into production, customers waiting on the other end of an email. So when something I changed at midnight is wrong, they do not find out in a code review. They find out at nine the next morning, in the middle of a task, with someone on the phone. It is not a ticket sitting politely in a backlog. It is somebody's morning. And I have come to think that this one fact, more than any tool or framework or clever decision, is the thing that has really shaped the work.

For a long time I thought of all this as the hard version of the job. The version with the safety rails taken off. And I will be honest, some days it still feels like exactly that.

But I have been turning it over lately, and I am no longer sure "hard mode" is the right way to describe it. Or it is true, but it is not the interesting part of the truth. And if you build anything for people who depend on it, the interesting part is yours too, so let me try to get at it.

There is no Monday where the new system appears

Let me try to describe what building on a live system actually feels like, because I do not think the phrase carries its own weight.

In a tutorial, there is always an implied Monday. The day the rewrite ships. The before, and then the clean after. You work in the dark for a while, and then you flip a switch and the new thing exists. I used to picture my work that way too, and it took me an embarrassingly long time to notice that the Monday never comes. There is no version of this where the new system arrives all at once. There is only the current system, the one people are using right now, and the small careful change I am about to make to it while it keeps running. Every change is closer to open-heart surgery on a machine that cannot be switched off than it is to building something new on an empty lot.

Which means I cannot do most of the things the tutorials take for granted. No big-bang rewrite. No "we will fix the data later," because later never has a quiet moment to arrive in. Everything goes out in small, boring, reversible pieces, not because I am especially disciplined but because the cost of being wrong is paid by somebody other than me, and that changes the math on every single decision. A bold move that might save me a week is not worth it if the failure case is a person standing at a screen, stuck, while a customer waits.

Here is the honest texture of it. I have caught myself, more than once, with my hand resting over the keyboard, not because I did not know what to type but because I knew exactly who would feel it if I typed the wrong thing. For a while that hesitation annoyed me. I read it as slowness, as a lack of nerve. I am starting to think it might be the single most useful instinct I have developed, and that the version of me who could type without that hesitation was not braver, just further from the consequences. If you have felt that pause in your own work, do not be in a hurry to train it out of yourself. It is not timidity. It is information about who pays for your mistakes.

The constraint started doing my thinking for me

This is the part where I changed my mind, and I want to actually walk through it instead of just asserting it, because the assertion is cheap and the walking-through is the thing that convinced me.

If you had asked me a year ago, I would have told you the live constraint was a tax. Something I paid in exchange for the work being real. Pure cost, grudgingly accepted. What I did not see is that the constraint was quietly making decisions I would otherwise have made badly.

It will not let me build the clever abstraction that nobody needs. There is no time for it and no cover for it, and a running company has a wonderful way of ignoring anything that does not earn its place that week. It tells me almost immediately when a feature does not fit the way the work actually happens, because the people doing the work will say so by lunch, in plain language, without a single thought for my feelings about the architecture. A feature that survives contact with a real Tuesday is worth ten that demo well in a meeting. I knew that sentence was true before I believed it. The live system is what made me believe it.

And the strange thing is how much of the methodology I have written about elsewhere is really just this instinct, formalized. The whole framework I work from rests on the idea that you build up from what is actually true: decompose the product, get the real data, and let pricing and quoting and the rest become functions of that instead of guesses. I used to think I arrived at that by being principled. Looking back, I think the live constraint arrived at it for me and let me take the credit. You cannot get away with a guess for very long when the guess is going to be wrong in front of someone by Thursday. I wrote a whole separate note about how that played out with our cost data, how the boring foundation has to come before the clever layer, and only now do I see that both of those lessons have the same parent. The constraint was the teacher. I was just the one taking notes.

So I want to be careful not to romanticize it, because that is the easy move and I do not fully trust it. The constraint is not magic. It does not make me a better engineer in some general, transferable way. What it does is narrower and more honest than that: it removes my ability to fool myself for very long. That is all. It just turns out that the ability to fool yourself, undisturbed, for months at a time, is most of what goes wrong in software.

So if you want the practical version of all this, it is almost insultingly simple. Put yourself somewhere you cannot get away with fooling yourself for long. Ship to real people, in pieces small enough to take back, and let them tell you by lunch when you are wrong. You will not have to muster the discipline to build only what is real, because the situation will keep supplying it for you.

The part that humbles me

There is a sentence I used to lean on without noticing how much weight I was putting on it. "Technically, it works."

It is a comforting sentence. It means the code does what the spec said. It means I can close the laptop. And it is almost always beside the point, because "technically it works" can still cost a real person an hour of their actual day. The form that saved most of the way and then lost the rest. The error message that nobody reads until it is the only thing on the screen and they have no idea what to do next. The thing that happens when the network blips in the middle of a quote and the state ends up somewhere I never imagined, because I was thinking about the happy path and they were just trying to get their work done.

Building for people you can picture does something to you. I am not sure I would call it pressure, exactly, though it is related. It is closer to a kind of attention. When the user is an abstraction, the unglamorous edges feel optional, like polish you will get to if there is time. When the user is a specific person who is going to be standing at a screen at four in the afternoon with a customer waiting, the edges stop being edges. They become the whole thing. I have spent more care on a half-saved form than on features I was much prouder of, and I have stopped feeling like that is a misallocation. The proud features were for me. The half-saved form was for them. You probably already know, in your own work, which of your features were which. Building for someone you can picture just makes the difference impossible to keep ignoring.

Reality reviews in public

I build most of this alone, though not really alone, and for a while I worried about the absence of a second set of eyes. No senior engineer to catch my mistakes before they ship. No review gate. It felt like a real gap, and on the narrow technical points it sometimes is.

But I have come to think I do have a reviewer, and it is a more honest one than most. It is reality. The live system reviews every decision I make, continuously, and it gives its feedback in public. If I have understood the work, the feature gets used and disappears into the background the way good tools do. If I have not, I hear about it, and not as an abstract critique but as a concrete person who could not do the thing they needed to do. There is no arguing with that reviewer. It does not care how elegant the solution is. It only cares whether the work held up when a real person leaned on it, which is, in the end, the only question that was ever going to matter.

This is also what I mean when I say I am building the platform in the open, and why I have started writing about it while it is still being built rather than reconstructing it later from a safe distance. Reconstruction is flattering. You get to skip the parts where you were wrong. Writing about it now, while the system still has to keep working tomorrow, keeps me closer to the truth of it, because I cannot quietly edit out the mistakes when the mistakes are still load-bearing. If you want your own account of your work to stay honest, write it while it is still load-bearing too. Hindsight is generous in a way that does not teach anyone much.

And it has changed what "done" even means to me. There is no done. There is only working, today, for the people who depend on it, and a quiet obligation to keep it that way tomorrow. I used to find that exhausting to think about. Lately I find it almost clarifying. A thing that is never finished is a thing you never get to stop caring about, and I am not sure I would want the version of this work where I was allowed to stop.

Would I trade it?

So let me ask myself the honest question, the one I have been circling the whole time. If someone offered me the clean slate tomorrow, the team and the staging environment and the freedom to be wrong in private, would I take it?

I want to say no, cleanly, and make a tidy ending out of it. But that is not quite true either, and I promised myself I would not do that. Some days I would take the clean slate in a heartbeat. Some days I am tired, and the weight of building on live wires is just weight.

What I think is actually true is smaller and steadier than a clean yes or no. The greenfield teaches you to build what is elegant. The live system teaches you to build what is true, and it does it by refusing to let you confuse the two for very long. I did not choose that lesson. It was handed to me by circumstance, and I resented it for longer than I would like to admit. But it has made me a more careful builder than any amount of empty land ever could have, and at this point I am not sure I would know how to unlearn it.

Maybe that is the real answer. Not that the constraint is a gift, which sounds too neat. Just that it became part of how I think, so quietly that I cannot find the seam anymore between the discipline and me. And if you are building something inside a running operation of your own, on live wires, for people who will feel it when you are wrong, I suspect you already know the feeling I am describing. The only thing I would tell you is the thing it took me too long to learn myself: the constraint you keep resenting is probably the one teaching you the most.

Every Business Sits on a Product

Tue, 23 Jun 2026 00:00:00 GMT

If you run a business that makes something, you are sitting on a product, and you almost certainly understand it less precisely than you think you do. That is not an insult. It is the single most useful thing you can know about your own operation, because once you see it, a lot of problems you were treating as separate turn out to be the same problem.

Here is the idea, and it is not really about cabinets even though that is what I happen to build for:

Every manufacturing business sits on a product. If you understand that product at its most granular level, every material, every labor second, every overhead dollar, you can automate everything above it.

Think about what "everything above it" actually contains. Pricing. Quoting. Scheduling. Sales. Marketing. Reporting. You probably treat each of those as its own problem, with its own software and its own headaches. They are not separate problems. They are all functions of product data. Get the product data right and the work above it stops being manual effort and starts being arithmetic. Get it wrong, or skip it because it is boring, and nothing you stack on top of it will hold. So if you only take one thing from this, take the order: the product comes first, and everything else is downstream of how well you understand it.

Start by taking the product apart

The first move is the unglamorous one, and it is the one most people skip. Take the product apart until there is nothing left to take apart. Every material. Every labor step. The time each operation actually takes, not the time you assume it takes. The overhead each unit actually absorbs. You are building a real bill of materials for every variation you sell.

This sounds like data entry, and it is not. Data entry is when you already know the answer and you are just typing it in. Decomposition is where you find out what you only thought you knew. When I did this on my build, one operation I had estimated at roughly twenty minutes turned out, when measured, to take closer to seven. That is not a rounding error. That is a threefold mistake that had been quietly mispricing the work for years, and nobody had caught it because nobody had ever forced the product to explain itself. You will have one of these too. Everyone does. The only question is whether you find it, or whether your customers keep paying for it in one direction and you keep eating it in the other.

So here is the test for whether you have actually done this phase, and it is a strict one. Hand your product documentation to someone with zero context. If they cannot arrive at a rough cost from what you gave them, you are not done. The gap they hit is the gap that everything above will inherit. Do not build pricing, or quoting, or anything clever on top of a foundation that cannot pass that test. You will just be automating your guesses, faster. (If you want the longer version of why the boring data has to come before the clever layer, I wrote about that exact mistake separately.)

Eight phases, each one standing on the last

Once the product is decomposed, the system builds up in eight phases, and the order is not arbitrary. The first four are the foundation, and they are strictly sequential: formulate the product, map the operation that produces it, put all of it in one relational database so nothing lives in a silo, and capture the knowledge that currently survives only in people's heads. The next three turn that foundation into a working commercial engine. The last one turns the whole thing outward, to the market.

I will not walk all eight here, because the framework page does that properly, with the theory each phase rests on and an honest account of what is actually built. What is worth your attention is the shape, because the shape is the part almost everyone gets wrong, and getting it wrong is the difference between a pile of tools and a system.

The part almost everyone gets wrong: 5 to 7 is a loop

Look at phases five, six, and seven: project intelligence, quoting, and sales. If you are like most people, you will read those as a pipeline. Track the work, price the next job, sell it. Left to right, done. Build them that way and you will get three tools that each do their job and never talk to each other.

They are not a pipeline. They are a triangle, and the data is supposed to run both ways around it.

Watch how it actually moves. A change order in sales books a new project on the factory floor. That project produces real costs, measured, not estimated. Those costs flow back two directions at once: they correct the profitability of the job you just did, and they sharpen the estimate for the next one, so the quote that produced the change order gets a little less wrong every time the loop closes. Production truth, quote accuracy, and sales promises end up continuously correcting each other.

This is the whole difference between "I built some tools" and "I designed an intelligence layer," and it is worth being able to tell which one you are doing. A linear framework is a checklist: you do the steps and you are finished. A system with feedback loops is an architecture: it gets measurably smarter the longer it runs, because every closed project is a test of its own accuracy. If you want the second one, you have to wire the loop deliberately, because it will not happen on its own. Left alone, software flows in one direction.

That is also why I split the methodology in two. The Build gets you the system once. The Run is what a team does with it every day afterward to keep the loop closing, because a loop that nobody tends quietly goes slack. And before you write a line of code for any phase, there is a set of questions you have to answer honestly about your own operation. Those live in the Navigator, and they are worth more than the code, because the code is easy once the answers are real.

When you get this right, marketing is just publishing

Phase eight is content and marketing, and it is the one I am in now, which makes the premise almost uncomfortable to admit: if the first seven phases are done right, marketing stops being a creative act too. The project photos already exist. The specs already exist. The results already exist. You are assembling what the system already knows, not inventing a story to cover for the fact that you do not know it.

Which is exactly what this website is. It is phase eight in action, published from the same data architecture that prices the quotes. And it comes with a built-in honesty check: if you are not proud enough of the underlying work to show it, that is not a marketing problem you can write your way out of. It is a product problem, and the marketing is just telling you the truth about it. So I am showing the work, while it is still being built. (If you want to see the structure that came out the other end, the shape of the system lays it out.)

Where to start

If all of this lands and you want to do something with it, do not start with the impressive part. Do not start with the AI, or the dashboard, or the quoting tool. Start with the product, and take it apart further than feels reasonable, until a stranger could price it from your notes. Everything you want to build later, all of it, is a function of how honestly you do that one boring thing first.

If you want the full blueprint from there, with all eight phases, the theory under each, and where each one actually stands, start with the framework.

The Shape of the System

Tue, 23 Jun 2026 00:00:00 GMT

When you want to know whether a piece of software is any good, you probably reach for a feature list. Resist that. A feature list tells you what someone built, not whether the parts add up to anything. The honest way to measure a build is its shape: do the parts form a system, or just a pile of tools that happen to share a login? That is the question worth asking about your own work too, and it has a real answer, not a vibe.

After months of building this one mostly on my own, in daily use the whole time, the answer here is a system with a clear structure. And the structure is not an accident. It is the visible result of one decision, made early and held to even when it was inconvenient: everything is a function of product data. Decompose the product accurately, down to materials, labor, time, and overhead, and pricing, quoting, scheduling, sales, and the customer-facing surface all become outputs of that one core rather than separate things you maintain by hand. That single commitment is what lets one engine sit underneath everything else. Make the opposite choice, and let each surface own its own logic, and you get the pile of tools instead. The shape follows directly from that one fork.

What the structure buys you

Read the modules top to bottom and they line up with the framework phases. That is not a coincidence: the framework is just the reverse-engineered description of this build, the map drawn after the territory. If you are building something similar, this is roughly the order the layers have to come in, because each one assumes the one below it is solid.

A foundation: the product-and-cost engine, one relational source of truth, and a knowledge base. Get this right and nothing above it is guessing. Get it wrong and everything above it inherits the guess.
A commercial layer: configure-price-quote, estimate versioning, a sales funnel, change orders, and multi-factory linking. This is where a quote becomes a calculation instead of a creative act, but only because the foundation made the numbers real.
A production layer that feeds real cutting, nesting, and bill-of-materials data back in, so estimates get corrected against what the floor actually consumed. This is the layer most people skip, and skipping it is why their estimates never improve.
An intelligence layer: an agent with read-only, tightly-scoped access that turns the knowledge base and live data into recommendations. Notice it comes near the top, not the bottom. The intelligence is the last thing you build, not the first, because it is only as good as everything underneath it.
Customer-facing tools and automation built on the same core, so what reaches a customer is assembled by the system instead of rebuilt by hand each time.

If you take the shape seriously, you will notice it is mostly a statement about dependencies. Each layer earns the right to exist by standing on a solid one below it. That is the difference you are looking for when you ask whether you have a system: not how many features there are, but whether they depend on each other in a way that makes the whole thing more correct over time. It is also why the shape is worth documenting at all: a structure built this way is reproducible, and making it reachable for other small manufacturers, not just describing my own, is the point of the whole effort.

The one number worth stating

Most of the concrete results here stay private, because they are tied to a specific business and not mine to publish. But one is safe to share, because it is a property of the method rather than the company: the cutting-layout optimizer lifts material utilization from roughly 31% to around 79%. In plain terms, that is what makes a unit meaningfully cheaper to produce in an optimized batch than as a one-off, and it flows straight back into how the work gets priced.

Treat that figure as a stand-in for the rest, not as the headline. The point is not the number itself. The point is that the structure makes improvements like it measurable, repeatable, and connected: you can see the gain, you can reproduce it, and it does not sit in a slide deck, it changes the price. If an improvement in your own operation cannot do all three of those, the structure underneath it is probably not finished yet.

The real test: it produces its own evidence

Here is the part a feature list can never show you, and the part I would point at if you asked me how to tell a system from a pile of tools. This one produces its own evidence. It records what it does. It measures its own estimates against what actually happened. And it generates the material it is described with, this site included, from the same data that prices the quotes.

That is the quiet signal you are aiming for. When the thing you built can show you its own shape, when it can tell you how it is doing without you assembling the answer by hand, you have crossed from tools into a system. Until then, you are still holding the pile together yourself, and you are the only reason it looks like it has a shape at all.

Building Solo, With an Agent

Tue, 23 Jun 2026 00:00:00 GMT

I build most of this platform by myself. That is true, and also a little misleading, because for the last stretch I have been building with an AI coding agent at my side the whole way. If you are going to work this way too, it is worth being honest about what it actually changes, because the honest version is smaller and more useful than the hype around it.

The biggest thing it removes is activation energy. You know the hardest moment in solo work: the blank file at the start of a task you do not feel like beginning. The agent makes that moment cheap. You describe what you want, you get a first pass that is most of a scaffold, and you start editing instead of staring. If you have no team to bounce off, that one shift is the difference between a feature shipping this week and it sitting in your head for a month.

It carries real weight in a specific place: the work that is more tedious than hard. Boilerplate you would resent writing. An unfamiliar API you would otherwise lose an afternoon to. Holding context across a codebase too big to keep in your head. Writing the test you would have quietly skipped. Hand it that, and it is a tireless pair.

But here is where you still have to drive, and it is the part the breathless takes leave out: everything that takes judgment. What is worth building at all. How the pieces should fit so the system still makes sense a year from now. Whether a confident-looking answer is actually right, because the failure mode is not gibberish, it is plausible and wrong. The agent will happily build the thing you should not build. Knowing not to is still your job, and it does not get outsourced.

So the discipline that makes this work is unglamorous, and you should hold yourself to it: small steps you can verify, reading every line before it lands, and never confusing a fast draft for a finished decision. Used that way, it is the reason one person can credibly run a platform this size. Used carelessly, it is a very efficient way to generate problems you do not understand yet.

It does not replace understanding the system. What it does is lower the cost of acting on the understanding you already have, which, when you are the only one in the room, turns out to be most of the battle.

Data Before Intelligence

Tue, 23 Jun 2026 00:00:00 GMT

If you are building something with AI in it, you are going to want to build the impressive part first. The agent. The thing that answers questions and generates the quote and feels like the future. It is the part you can show someone. I wanted to build it first too, and it took me a while to admit the order was backwards.

Here is the thing nobody tells you up front: the intelligence is only ever as good as the data underneath it, and that data almost certainly does not exist yet in any usable form. Mine lived in spreadsheets, in file names, in one person's memory of how a particular job is really priced. So before any agent could be trusted with a question, I had to do the part nobody asks to see: take the product apart into its atoms, every material, every labor step, every overhead dollar, and put it somewhere a machine could read without guessing. You will have to do the same, and it will not look impressive to anyone, including you.

It was months of unglamorous work. Decomposing things that "everyone already knows." Arguing with my own assumptions. At one point I found a time estimate I had quietly trusted for years was off by roughly threefold, not because anyone was careless, but because no one had ever made the number meet reality. That is the kind of thing the boring work surfaces, and you only find it by doing the boring work.

Then comes the part that will surprise you. Once the data was right, the clever layer got almost dull. The "AI" was not doing anything magical. It was reading clean, structured, honest data and stating what was already true. The intelligence felt smart because the groundwork was solid, not the other way around.

This is the thing the demos get wrong. They show you the model. They never show you the six months of decomposition that make the model worth listening to. So if you take one instruction from this, take the order, because it is the part that is easy to get backwards: get the foundation right first, and have the patience to do it before you have earned anything visible for the effort.

Data before intelligence. Not as a slogan. As the actual order the work has to happen in.

One Engine, Two Audiences: Letting Customers Quote Without Seeing Costs

Mon, 22 Jun 2026 00:00:00 GMT

Sooner or later, if you build internal software, someone is going to ask you to point it at customers. The system that quietly runs the business now has to face the people the business sells to. And the moment that happens, you inherit a problem that looks small and is not: the same engine that knows every number now has to talk to someone who is allowed to see exactly one of them.

In my case the engine is a quoting system for a manufacturer. It knows the material cost per square foot, the labor, the overhead, the markup applied to every line. The ask was a self-service portal: let customers configure a project and get a price themselves, instead of emailing back and forth and waiting on someone internal to quote it. Reusing the engine to produce that price is the easy part. Making sure the customer never sees a cent of the cost behind it, not today, and not three releases from now when you have completely forgotten this was ever a concern, is the actual job.

So this is a piece about how you build that boundary. Not how you remember to hide the cost, but how you make the cost structurally unable to escape, even on the day you stop thinking about it.

The number is the dangerous part

Start by being honest about what you are actually guarding, because it is easy to get this wrong.

The danger is not the price. You want the customer to see the price. The danger is everything sitting behind the price. An internal pricing engine is usually built to expose cost. It itemizes the board, the edgebanding, the hardware, the labor, and the margin stacked on top, because the people running the business need to see all of it to make decisions. That is the whole point of it internally. So the engine you are about to reuse is, by design, a machine for revealing exactly the things your customer must never see.

A customer gets to see one thing: their price. Nothing underneath it. Which means the interesting question is not "how do I compute the price for the portal." You already have that. The question is "how do I let the portal use a cost-revealing engine without any of the cost coming with it."

Two ways to do this, and why both of them end badly

When you sit down to solve this, two options present themselves immediately, and both are traps. It is worth walking through why, because the right answer is mostly a reaction to how these two fail.

The first is to reimplement a simpler pricing path just for the portal. It feels clean. The customer-facing calculation is simpler, so you write a smaller version of it that only knows about price, and the cost logic never even exists on that side. The problem is that you have just signed up for two sources of truth. The day someone changes a markup rule, or adds an install fee, or adjusts a tier discount in the real engine, your portal keeps quoting the old way. The two will drift, quietly, and you will not find out until a customer's self-serve quote does not match what your team would have charged them, in front of the customer. A second implementation of pricing is a second thing to keep correct forever, and you will lose that race.

The second is to expose the real engine and strip the cost fields on the way out. Reuse everything, and just remember to remove cost, margin, cost_per_sqft, and friends from every response before it leaves the building. This is worse, even though it looks more responsible. You have made the safety of the whole boundary depend on you, and every future contributor, remembering to do a thing on every endpoint, forever. It will hold for a while. Then someone adds a new field, or a new endpoint, or returns the internal object directly because it was faster, and the leak ships. If your safety depends on remembering, you have not made it safe. You have scheduled the leak for whenever you happen to be busy.

So here is the principle both failures point at, and it is the one decision the rest of this follows from: do not make leak-prevention something you do. Make it something the code cannot not do. One engine, guarded at the boundary by construction.

Decision one: reuse the engine, and do not fork it

Reuse the internal pricing logic exactly. The portal endpoints import and call the engine's own functions, the same ones the internal app calls: create a quote, add a line item, recalculate totals. You do not reimplement the markup, the install rules, or the tier discounts anywhere. There is exactly one place pricing can change, and both audiences run through it.

The payoff is not just less code. It is that a self-serve quote becomes a real quote rather than an approximation that will embarrass someone later. When your customer builds a quote in the portal, it is the literal output of the engine your team trusts, so it cannot disagree with what your team would have charged. That property is worth protecting, and it is the entire reason you do not fork.

If you have read the framework these systems are built on, this is the same idea wearing work clothes: pricing, quoting, and the rest are all functions of one well-formed product model, so you want one engine computing them, not two engines disagreeing. Reuse is how you keep that promise at the boundary.

Decision two: make the leak structurally impossible, not merely avoided

Here is the decision that actually does the work. The portal never serializes an internal object. It returns a separate, cost-free view model that was never given the cost fields in the first place.

class PortalQuote:           # the customer-facing view
    code: str
    rooms: list[PortalRoom]  # items carry quantity + the customer's price
    total: Money             # ...and nothing about cost or margin

# catalog responses are cost-free too: id, code, name, never cost_per_sqft

Look at what this buys you. Because PortalQuote has no cost fields, there is nothing to accidentally include. You are not stripping cost out on the way through. The customer-facing type was simply never a shape that could carry it. The guarantee comes from the structure, not from your discipline, and that is the whole difference between a boundary that holds and one that holds until you are tired.

The instinct to fight here is the lazy one: "I will just return the internal object and leave off the sensitive fields in the response." Do not. The moment your safety is a thing you remember rather than a thing the type system enforces, you are back to scheduling the leak. Give the outside audience its own shape, and let that shape be incapable of betraying you.

Decision three: derive who the customer is, never let the browser tell you

There is a second leak that has nothing to do with cost, and it is the one people forget. Once customers are calling your engine, you have to be certain each call only touches that customer's own data. The wrong way is to trust an id that came up from the browser. The right way is to derive ownership from the session token and let the request body have no say in it.

def get_current_customer(token) -> ClientId:
    claims = decode(token)
    if claims.user_type != "customer":
        raise Forbidden()
    return claims.client_id  # the browser never gets to choose this

# every portal endpoint starts the same way
quote = assert_quote_owned(quote_id, current_customer)

The rule worth internalizing: anything the client can set, the client can tamper with. So the identity that scopes a request should come from something the client cannot forge, which means the token, not the payload. Every portal endpoint starts by asserting ownership against the derived id, and an attempt to read someone else's quote dies at the door.

Decision four: make a leak a failing test

You have made the boundary safe by construction. Now make it stay that way after you have moved on and forgotten the whole design. Write a test that treats a cost leak as a build failure: drive a quote all the way through the portal, then assert the response carries zero cost fields.

It is a few lines, and it is the cheapest insurance you will ever buy. If someone a year from now wires an internal object straight through because it was the quick path, the test goes red before it ships, not after a customer screenshots their own margin. By-construction safety stops the leaks you can foresee. The test catches the one you cannot, which is some future change you have not imagined yet.

What will bite you anyway

Do all of that and the boundary will hold. Something else will get you instead, and it is worth seeing the shape of it, because the shape is general.

The bug that taught me the most came from duplicating a quote. A customer duplicates an existing quote, and the copy's total does not match the original. The line items had copied perfectly, identical down to the part, so it was not the items. It was fulfillment.

The original was an old quote, from before the engine had an explicit fulfillment mode. It had no mode set, but it did carry a saved delivery charge sitting on the row. When the duplicate recalculated from scratch, "no mode" fell through to the current default of install, and computed a different number. The old row said one thing implicitly. The new logic assumed another. Nobody was wrong on the day they wrote either one. They just never met until a customer pressed duplicate.

The fix was to stop trusting the absence of a value. Before recalculating, derive the effective mode from what is actually there: if there is a delivery charge, it is delivery; otherwise install; otherwise pickup. Set the mode explicitly, then recalculate, and the totals line up.

Here is the part to carry with you, because it will happen to you in some other form: when you run old records through logic that now expects state to be explicit, distrust their blanks. An empty field is rarely a clean nothing. It is usually a default that made sense when the row was written and has since moved underneath you. This is one of the quiet taxes of building on a system that is already live: your data remembers decisions your code has forgotten.

The rule worth carrying

If you are putting an outside audience on top of an internal system, three things are worth taking with you, and none of them are specific to quoting.

Reuse the core logic. A second implementation is a second source of truth, and it will drift away from the first until the gap shows up in front of the person you least wanted to see it. Make the boundary safe by construction, not by vigilance: give the outside audience its own shape, one that cannot carry what it must not reveal, so the guarantee does not depend on anyone remembering. And distrust the blanks in your old data, because an empty field is often a default in disguise.

The deeper version of all three is the same instinct. Do not build a system that is safe as long as you stay careful. Build one that is safe when you forget, because you will. If you have wrapped a customer-facing layer around an internal system, it is worth asking yourself honestly: where would your first leak actually come from, the serializer, or the old data nobody has looked at in a year? The answer tells you where to spend your care. The rest of the platform is mostly this same question, asked again at every boundary.

What I’m Documenting Here

Mon, 22 Jun 2026 00:00:00 GMT

This is where I write about building the software that runs a small custom manufacturer, while it's being built, not reconstructed afterward from a safe distance.

Most of what's written about this kind of software assumes a dedicated team, clean data, and a budget to match. A small manufacturer has none of that. So the work here is about closing that gap with what a small company actually has, and being honest about what holds up and what doesn't. If that is the spot you are in, a small operation with a big ambition and not much slack, you are who this is written for.

How the writing is organized

The longer pieces fall into four pillars. Read them in order and you move from why this matters to what actually happened:

The Problem. Why AI tooling built for enterprises doesn't transfer to small manufacturers, and what the gap costs.
The Methodology. The Manufacturing Intelligence Framework: two interlocking frameworks, eight phases, and the feedback triangle that ties them together.
The Implementation. How the systems actually get built. Tools, agent configuration, architecture, and the parts that broke.
The Results. Quantified before/after outcomes from real deployments.

Shorter, looser thoughts, the things I'm learning or figuring out, live in notes. What I'm actively building lives in projects.

If you're an engineer or operator trying to figure out where AI realistically fits in a small operation, that's exactly who I'm writing for. If you only read one thing, make it the framework. Everything else here is a footnote to it. And if you want the why underneath all of it, the larger aim these pieces serve, that has its own page.

How This Site Is Built

Mon, 22 Jun 2026 00:00:00 GMT

If you want to actually keep writing, the decision that matters is not your stack. It is making everything except the writing boring. So that is what this site is built to do: pick deliberately dull technology, and let publishing be the only thing that takes any effort.

It is a static build. No server, no database, almost no JavaScript shipped to you, the reader. Do it this way and the site stays fast and cheap enough to keep online indefinitely, which is exactly what you want from something meant to be a durable, citable archive rather than a thing you babysit.

Make each piece a Markdown file with a typed front-matter block, and let the build fail loudly when a required field is missing, so a broken page never ships:

title: 'Weeks to One Day: Catalog Automation Across Ten Product Lines'
description: 'What multi-line catalog automation actually looks like.'
pubDate: 2026-06-28
pillar: 'results'

Take the slug from the filename and never change it once published. That permanence is the point: any copy you post elsewhere can point its canonical link back to the version here, so this stays the source of record no matter where it gets mirrored.

The original lives here. Everywhere else is a mirror.

The payoff is the workflow. Adding a piece means dropping a file in the right folder and pushing to the repository. There is no CMS to log into, nothing to configure, no friction between the thought and the publish. And that is the whole trick, the one worth stealing for whatever you build: the less the tooling asks of you, the more consistently the writing actually happens.