The expensive part was never the software
For as long as small businesses have bought software they have had two options, and both are bad. Generic and affordable, or custom and out of reach. Everybody who has run one knows this. Almost nobody says why.
The usual answer is that building software is expensive. That answer has been wrong for twenty years. Building got cheap with frameworks, cheaper with hosted platforms, and cheaper again in the last three years. If the cost of construction were the constraint, custom operating software for a thirty person company would have arrived a long time ago. It did not arrive.
The actual constraint is the specification. Before anyone writes a line, somebody has to write the business down. Every rule, every exception, every thing that cannot happen at the same time as another thing. That job requires a person who does not know the business to spend weeks learning it from people who cannot explain it, and to be wrong about a good deal of what they produce. It is slow, it is unpleasant, and it never got cheaper, because nothing in the technology stack touched it.
So the arithmetic held for forty years. Below a certain size, writing the business down costs more than the software would ever save. Every vendor who looked at that market ran that calculation and shipped something generic instead. That is not a failure of imagination. Given the inputs, it was the right call.
What changed
I run operations for a whitewater outfitter. Two rivers, two bases, a fleet of boats and vehicles, a large seasonal crew, and a peak day with 272 people on the water. The operation runs on things that cannot be in two places at once and on people who are not interchangeable.
Two years ago it ran on a whiteboard and on what a handful of us remembered.
It does not now, and the part worth writing about is not what we built. It is how the writing down got done.
I did not hire an analyst and I did not sit down with a blank document. I pulled our data out of the system it lived in and into a model I own. Then I worked out the rules by reasoning over that data conversationally, one question at a time.
The important part is this. I was not remembering rules and dictating them. I was being shown things and reacting. I knew we had vehicles. I could not have told you how to define one. Put the data in front of me in a shape I could interrogate and the definitions fell out, and so did a considerable number of rules I did not know we had.
That is a different activity from an interview, and it is much faster than one.
The part that proves it is real work
The fair objection to everything above is that it sounds like a demo. So here is the number.
I froze the ruleset last week and counted it. Over a hundred named rules. About a quarter of them do not detect anything. They exist to stop the other rules from firing on things that are fine.
A morning half day and an afternoon half day are not one person booked twice. That is a normal working day. A trip sitting on the calendar with no guests does not consume a boat or a driver, so it should not collide with anything. A multi-day trip occupies the shuttle pool on the day it launches and the day it comes off the water, and on no day in between. Somebody who guides a trip and drives the vehicle to it is one person doing two jobs, not two people, and not one person in two places.
None of that is an insight about rafting. Every one of them is something any dispatcher would tell you in a single sentence if you thought to ask. And not one of them existed in the system until the system got it wrong, in public, in front of somebody who knew better.
Which is the thing worth taking from this. A rule is not a fact. A rule is a fact, plus its exceptions, plus the window it applies in. The fact is now cheap. The exceptions cost a season.
It is also why the version history of that checker reads as a ledger of apologies. Several consecutive releases added no new detection whatsoever. Their entire job was to stop the thing shouting about work that was fine.
The limit, which matters more than the finding
I want to be precise about what got cheap, because the temptation here is to overclaim, and the overclaim is what will get the whole idea dismissed.
Writing a business down is two jobs, not one.
Encoding. Taking a rule you already know and turning it into something a system can enforce. This collapsed completely. What used to be weeks of data modeling is now an afternoon.
Elicitation. Getting the rule out of a person who has it in their hands and not in words. This did not move at all.
I could not see the difference for a long time, because in my own operation I was the source. Elicitation cost me nothing. I was talking to myself with a very fast assistant in the room.
In a business I do not run, elicitation is the whole job. The owner does not know his rules. He has them, after twenty years, in his hands. Ask him directly and he will give you the tidy version, which is the version he wishes were true. The real one surfaces only when something in front of him is wrong in a specific way and he can say so.
So the cold start problem did not disappear. It moved. It used to be an engineering cost and it is now an interview cost, and interviews do not get cheaper because models improve. They get cheaper when somebody writes down the right questions.
What this opens up, if the limit turns out to be solvable
If specification cost has genuinely fallen, and if the elicitation half can be made repeatable rather than depending on one person’s instincts, then something becomes possible that was not possible before. A business doing a couple of million dollars a year can run on software shaped like itself, rather than on software shaped like the average of its industry.
That is not a better product in an existing category. The category has been empty for a structural reason, and the reason moved.
I am not claiming it is solved. I am claiming the binding constraint changed, and that almost nobody has noticed, because it changed somewhere nobody was watching. Everyone has spent three years measuring how fast software can be built. Construction speed was never the bottleneck.
What I am testing next
The test is not whether I can do this again. I can. The test is whether it can be done by somebody who is not me, on a business nobody in the room has ever run.
So I am writing the elicitation down. For each kind of constraint: the question that surfaces it, the follow up that catches the exception, the tell that somebody is describing the ideal rather than the real, and the analysis to run against their own data so you arrive already holding the anomalies instead of asking for them.
Then I am going to run it on businesses I do not know, with a stopwatch, and log two numbers. Rules captured, and hours spent with humans getting them out. If hours per rule falls across three businesses, the method transfers and there is something real here. If only build time falls, then I bought better tools, so can anybody, and the interesting claim is false.
I would rather find that out this year than believe it for five.
If you run a service business where one person answers “can we do it, by when, for how much” all day from memory, I would like ninety minutes of your time.