Renting software was a good trade when code was expensive. The cost has moved, and the shape of business software is moving with it.
What SaaS was for
Most of the software a company runs today is rented. The ERP, the quoting tool, the CRM: each is a subscription from a vendor who built one product for thousands of companies. The industry calls this SaaS, and it was a good idea when code was expensive.
Twenty years ago, building your own software meant hiring engineers, keeping them, and hosting what they built. Almost no company outside the software industry could afford that for every process it ran. So a vendor built one tool for a thousand companies and spread the cost across all of them. Each company paid a fraction of what a build would have cost, and in exchange it got the average of what a thousand companies needed.
Everyone understood the trade. You shaped your process to the software, because the alternative was no software at all. If the tool did eighty percent of what you needed, the other twenty percent lived in a spreadsheet, in someone's head, or nowhere.
This is the same reason a machine shop buys fasteners from a catalog instead of cutting its own. For the parts that are the same everywhere, off-the-shelf is correct. Payroll is the same everywhere. Email is the same everywhere. Nobody should build those, and nobody will.
But most of what a company does is not the same everywhere. That is the part SaaS was never good at, and it is the part where the cost has moved.
The cost moved
The first version of almost any piece of software is now cheap. Not cheaper. Cheap. An internal tool that would have taken an engineer a month a few years ago is now an afternoon.
And the first version is wrong. It handles the case you described and not the one you forgot. It works for the person who built it and confuses the second person who uses it. It works until the business changes its mind, which a business does every six months, or until the system it reads from renames a field, or until the model underneath it is updated and starts answering slightly differently.
None of this is new. The cost of software was never mostly the first version. It was every version after, plus the cost of being the one who understands it when it breaks. What changed is that the first version stopped hiding that. When creation was expensive, ownership was a rounding error against it. Now creation is nearly free, and ownership is the whole bill.
It is tempting to conclude that everyone should now build their own software. I would draw a different conclusion.
If everyone builds their own, everyone owns their own. A company with a hundred small tools, each built in a week by whoever needed it, has a hundred things to maintain and a hundred people who each understand one of them and did not ask to. The tools stop working one at a time, quietly, and the company keeps using them anyway.
There are also parts of an application you should not have an AI build for you, at least not today: authentication, permissions, audit logs, and security. You can generate them, and they will look fine. If they are wrong, the liability is yours.
In regulated industries this is not a preference. If you operate under ITAR, CMMC, or HIPAA, a tool that touches your data has to be correct in ways that have nothing to do with whether it works. The requirement is not that it runs. The requirement is that you can show how it runs, who touched it, and what it did.
So the cost of software moved from creation to ownership, and ownership is the hardest thing to provide alone.
AI should remove work, not create it
There is a simple test for any AI product: after the customer buys it, do they have less to do, or more?
When AI automates a process, work goes down. The report writes itself. The quote goes out. The inspection plan is assembled before anyone asks for it. When AI hands someone a tool and asks them to figure out how to use it, work goes up. Writing the right prompt is work. So is choosing a model, or finding where a chat window fits in a day that was already full. Building an application with AI is the most work of all, because now you own something.
The request from every operator is the same: make the pain go away. Do not add any.
Chat is the interface AI arrived with, and it is a good way to explore. It is a poor way to run a process, for the same reason a shop does not run production on a manual mill. Every part depends on the operator. A skilled person can make a good part on a manual machine and a tired one can make a bad one, and nothing about the machine tells you which you got.
Production runs on fixtures. A fixture holds the part one way, so it cannot be loaded wrong. A go/no-go gage says yes or no. The Japanese term is poka-yoke, or mistake-proofing, and every good shop is full of it. The intelligence is designed into the setup so it does not have to be supplied by a person every time, under pressure.
That is what a good AI business application looks like. The model does its work inside the walls. What the person sees is a form that only accepts what is valid, a queue of things that need a human decision, or a report that is already right. It is easier to learn than a chatbot because there is less to learn. It is harder to misuse because the ways to misuse it were removed.
Most of the AI in a business will end up invisible.
Every business is a lot size of one
Every business is a prototype. It is a particular set of people and processes, built on someone's dreams, trying to do something different from everyone else. That is the point of it.
In manufacturing terms, every business is a lot size of one. And we run them on parts made in lots of a million, shimmed together with spreadsheets until they roughly fit.
Form-fit is short for a manufacturing phrase. Form, fit, and function are the three tests of whether a part does the job: is it the right shape, does it go where it goes, and does it do what it is for. A form-fit application passes all three for one company. It uses that company's words for things. Its steps are that company's steps. It does the things the company does and none of the things it does not.
Form-fit software has always been better. It is easier to learn, because there is nothing in it you do not recognize. It does more of what you need, because it was made from what you need. Nobody argued with this. The argument was always cost. Custom software was terrible to build and terrible to keep, and so the average won by default.
AI changed the first half of that. A lot size of one is now affordable to make. The second half, keeping it, is why this essay is about job shops and not about code generators.
Build to print
A job shop makes parts to a customer's print. The customer designs the part; the shop makes exactly that, to the tolerances on the drawing, and certifies that it did. This is not the low end of manufacturing. The most precise parts in the world come out of job shops. The tightest tolerances in aerospace and medical are held in lots of a dozen by shops most people have never heard of, because a shop's whole business is hitting someone else's spec. Mass production optimizes for cost per unit. A job shop optimizes for the print. Every part that comes through the door is different.
The process is not. A good shop's advantage is everything it reuses across thousands of different parts: fixtures, tool libraries, programs, gaging, and a quality system that decides what to measure and how often. The first run of a new part is expensive. The second is a fraction of the first, because the program exists, the fixture exists, and the control plan exists. A shop that has made a family of parts before can quote the next one in a day.
An AI job shop works the same way. The business is the print. Its processes, its systems, and its people's judgment about what matters are the drawing, and the application is built to it.
This summer we built one for a precision machining shop in Texas. Their quality engineers were building inspection plans by hand: reading each 2D print, working out which tolerances apply at which stage of production, and assembling the plan in Excel. A dimension that gets plated or ground afterward is not the dimension it was before.
The application reads the print, carries each tolerance through the operations that change it, and produces the plan in the format the shop already used. It does not do anything else. It was not built for machining shops in general. It was built to that shop's print, and it happens that a lot of shops have a similar print.
That last part is where the reuse comes from. What we keep between jobs is not the application. It is the process for making one: the components that show up in every application, the catalog of applications that recur across an industry, and one way to deploy all of them with the same authentication, permissions, and audit logs underneath. The applications are form-fit. The way we build them is not.
What a shop will not take
A shop is defined as much by what it will not take as by what it will. One does micro-precision work in titanium and turns away anything it could not fit in a palm. Another makes boat transmission housings and has no use for a Swiss lathe. This is not modesty. The bounds are the process.
A shop that accepts every job cannot reuse anything, because nothing repeats, and it ends up engineering every part from scratch. A shop that knows its envelope - the range of sizes, materials, tolerances, and certifications its process is built around - gets faster and more precise inside it every year. SaaS makes one thing for everyone. A job shop makes a family of things for anyone inside its envelope, and drawing that envelope is most of the strategy.
Ours is narrow on purpose. We build applications for complex and regulated businesses, starting with fast-growing US industrial manufacturers, where the inputs are messy operational data and the output has to be exact and auditable.
We do not replace the system of record; the ERP stays. We do not build general-purpose chatbots. We are bad at making slide decks, so do not use us for that. A quoting process, an inspection plan, a monthly report, or a stack of documents that has to be read the same way a thousand times: those are inside the envelope, and we keep a catalog of the twenty-five that come up most often. A request outside it is a job for a different shop.
The envelope is also what separates a job shop from a dev shop. A dev shop has no envelope. It takes whatever the customer will pay for, so nothing repeats, nothing gets reused, and every project starts from a blank page. It delivers and leaves, and whatever was built belongs to the customer, along with the problem of keeping it running.
In software, custom has come to mean loose. In manufacturing it means the opposite.
The fair question about any job shop is whether it scales. A physical shop is limited by spindle hours. Every additional part takes machine time, and every additional machine costs money. Software does not have that constraint. The second copy of an application costs nothing, and inside a defined envelope the process for making the first one gets better with every job. A software job shop compounds in a way a physical one cannot.
Keeping it in spec
Parts drift. Tools wear, material lots vary, and the print gets revised. A shop does not measure a part once and forget about it. A control plan says what gets measured, how often, and what happens when a measurement moves toward the edge of tolerance. Drift is expected. The system exists to catch it before it becomes scrap.
Software drifts the same way, and AI software drifts faster. The model underneath it is updated and its answers shift. The system it reads from changes a field. The business changes what it wants, which is what businesses do. An application that was correct in July is slightly wrong in October, and nobody notices, because nothing about it looks different.
Somebody has to notice, and that is what ownership is. When it breaks, you get the call. When someone new needs to learn it, you teach them. When the business wants one more field, you are the assumed person to add it. Whatever happens to it, you are the first to be told and the one expected to fix it. If it fails badly enough, you are the one who is fired.
Ownership is not a line in a contract. It is a standing claim on your time, and every application you build is a new claim. This is why building your own adds work even after building got cheap.
Inside a company, that claim lands on whoever built the tool, and nothing rewards them for holding it. Nobody is promoted for keeping an internal application running. It does not show up in a review. So the rational thing is to let it decay, and people do, while the company keeps depending on it.
It gets worse as the automation gets bigger, not better. A small tool at least has a builder. A large automation, the kind that takes over a whole job, removes the one person who knew what correct looked like. That person moves to other work, retires, or is never backfilled, and not needing to backfill them was usually the point.
What is left is an automation running a process nobody in the building does anymore, drifting in ways nobody in the building can see. The more work an automation removes, the fewer people remain who could own it. That is the ownership problem underneath everyone-builds-their-own, and it is worst exactly where the automation is worth the most.
Ownership goes where it is paid for. A job shop is paid to own. The part staying in spec is the revenue and the reputation, so the incentive points the right way.
A shop can afford to own because it owns on a foundation: every application deployed the same way, with the same permissions and audit log, and the reason it was built and what correct looks like written down and kept current. The person who built a tool in an afternoon has neither the reward nor the cheapness. The party that laid the foundation has both. Incentives align when the owner is paid to own and can afford to.
The same logic is why an AI cannot own an application.
That is not a claim about what models can do. It is a claim about responsibility. If I tell an AI to make my company secure, and it does a hundred things and gets one of them wrong, the blame does not go to the model. I cannot fire the AI. The blame comes to me. Society is not ready to let a model carry that blame, and it may never be. Someone has to sign.
In a shop, every part ships with a certificate of conformance. It says the part was made to the print and measured against it, and it has a name on it. An AI application needs the same thing: a party of record who keeps it in spec and answers when it is not.
That is what an AI job shop is for. Making the first version is the smallest part of the job.
Everyone gets their own
Here is where I think this goes.
A company will run on a set of applications that do exactly and only what that company needs. Most of them will run in the background. A few will have a screen, and the screen will be simple, because everything that could be decided in advance was.
The systems that hold the company's core records will still be there underneath. What changes is the layer through which the work gets done.
Each application will be built to the company's print and kept in spec by someone whose name is on it. And they will be cheap, not because they are generic, but because the process that makes them is the same every time.
Not everyone builds their own. Everyone gets their own.
Structify is the foundation for AI transformation in complex and regulated industries, starting with fast-growing US industrial manufacturers.
