Owned software · part two · a true story from this week
The first plan was good enough to be dangerous. It was 593 lines long. It mapped nearly every piece of software inside an equipment dealership we are fitting right now: the inbox, inventory, quotes, trade-ins, financing, signatures, service, parts, AI, advertising feedback, and the eventual path out of the dealer system underneath all of it. Tables. Timelines. Database fields. A sixteen-week build order. It looked finished.
So I handed it to another machine and gave it one instruction:
Try to kill this plan.
Do not make it prettier. Do not congratulate it. Find every place it could lose a message, promise the same machine to two people, charge one deposit twice, teach the AI a wrong answer, corrupt inventory, or leave the owner with software he technically owned but could not safely run.
The first plan understood the dealership. The second understood how software fails.
The sentence we had wrong.
The first plan said the conversation should sit at the center of the system. That sounds right — every sale starts somewhere: a text, a Facebook message, a call, a form, a man walking through the front door. But the conversation is not the customer. It is not the machine on the lot, not the quote, not the deposit, not the repair order, not the signed paperwork. A husband can text. His wife can call. The service department can talk to both of them six months later. Those conversations should all point to the same durable business record. None of them should own it.
That one correction changed the foundation underneath the whole build. A large plan is not the same thing as a safe plan — the more complete a bad assumption looks on paper, the more expensive it becomes in code.
What actually changed.
The corrected plan asks the questions a feature list avoids. What happens when two customers put money on the same machine at nearly the same time? When the payment company reports one deposit twice? When the old system says sold and the website still says available? None of those questions make a prettier demo. All of them make a safer business.
The first horizon is now one loop: a customer asks about a machine, the right person answers, the exact unit stays attached, a correct quote goes out, a deposit lands, one and only one unit becomes reserved, and management can see it happened. Then the new inbox earns the right to replace the old one. Then service. Then parts. Then financing, documents, and carefully controlled AI — each behind its own gate, each with a way back. Because a roadmap that cannot say not yet is not a roadmap. It is advertising.
This is where ownership gets real.
Most software companies own the roadmap. You can request a feature, vote on a feature, read a release note when they build some version of it for thousands of customers. But you do not decide what comes next.
You rent the present and petition for the future.
Owned software changes that deal. The owner does not merely receive whatever code exists on launch day — he controls what the system is allowed to become next. That does not mean unlimited development is free. It means the business decides what is worth funding, what should wait, what must never be automated, and who is allowed to build it. We have watched it work at speed, too: another owner on this fleet texted four corrections over morning coffee this week, and every one was live in his software before lunch.
And a real ownership deed settles more than two nouns. The code and the intellectual property. The data and the structure required to understand it. The accounts and infrastructure the system depends on. The instructions to deploy, restore, and operate it. The current roadmap, open decisions, and known risks. The right to continue with another qualified builder. A zip file nobody else can run is not freedom. A roadmap held only in the developer’s head is not ownership. A deed you cannot exercise is decoration.
The owner outranks every machine.
I do not care which AI wrote the first plan. I do not care which AI found the flaw. I care which answer survives contact with the business. We do not have to defend the first answer because it was ours — we can put it on the table, let another intelligence tear it apart, keep what survives, and hand the owner the stronger plan. He can change the order, reject a module, hold back an automation, demand more proof, replace the builder, and keep the system. That is not friction in the process. That is the product.
The client should never be trapped inside our first idea.
Whose roadmap is it?
On launch day this dealer will own the code and the data. But ownership started earlier — the moment the plan could be wrong in public, when a better answer could replace our answer without threatening our ego or his investment. Ask your software company what is on its roadmap. Then ask the question underneath it: whose roadmap is it? With rented software, the answer is theirs. With this one, the roadmap and the deed point to the same owner.
I’m Trevor. Found It Software, Alexandria, Louisiana.
Bring us the ugly part.
The spreadsheet. The duplicate entry. The quote living in somebody’s texts. The one task everybody knows is stupid but nobody has had time to fix. Show us how the work really moves, and we will map the first loop worth owning — and the ways it could fail — before we ask you to bet the business on it.
The 60-second fit check starts it · straight answer