You can tell within the first five minutes. One of them gets the workflow wrong in a way the engineers cannot see. The other gets the workflow wrong in a way the operators cannot ignore.
I have had the same conversation with dealer-software vendors for 30 years. A very smart engineer shows me a product, and the product is missing the one thing the desk actually needs. I ask them about it, and they explain why they built it the way they did. The explanation is coherent. It is also wrong.
The signature of engineer-built software
Clean data model. Beautiful API. Thoughtful abstractions. The data flow is easy to follow.
Walk into a dealership with it, and the salespeople do not use it. The managers use the parts that fit their existing habits and ignore the parts that do not. Adoption stalls. The engineers blame the users for "not being open to change." The users are not being closed-minded — the software is not solving the problem in the shape the problem lives in.
The signature of operator-built software
Messy data model. The abstractions do not line up. Some fields exist for no reason the engineers would recognize.
Walk it into the dealership and the salespeople use it immediately. Because the messy fields are the fields they actually use. The guy who needs to note "customer said their wife has to see it" has a place to put that, because the person who built the software also needed that field.
Over time, an operator-built product gets cleaned up. Not by replacing the messy fields with clean ones. By moving them into the right place in the data model while keeping the same behavior.
The mistake both sides make
The engineers look at the operator's product and see chaos. They want to rewrite it. If they rewrite it, they will lose the thing that made it work.
The operators look at the engineer's product and see over-engineered complexity. They want to simplify it. If they simplify it, they will lose the thing that made it scale.
The right move is to take an operator-built product and have engineers clean the code without touching the behavior. Not rewriting the behavior — cleaning the implementation. That is the work that takes a Louie and turns it into a Louie-at-12,000-rooftops, without losing the Louie in the process.
The acquirer who understands this gets five years of operator-encoded knowledge for the price of a tuck-in. The acquirer who does not is going to try to rewrite what they bought, and discover after 18 months that the rewrite does not do the things the original did, and cannot.
Why this matters for an acquisition thesis
Operator-built software is not a feature list. It is a set of decisions about what the product should not do, made by someone who knows what happens when you do the wrong thing.
Louie does not try to structure the deal for the desk manager. That is a decision. It came from 30 years of watching software vendors try, and fail, to replace the desk manager's judgment. Louie presents the pre-chewed information and steps back.
Louie does not try to be the BDC CRM. That is a decision. The CRM is a record-keeping tool. Louie is a decision-layer tool. Mixing them makes both worse.
Louie does not try to replace the DMS. That is the biggest decision. The DMS is the ledger. Louie is the brain. They do different jobs. Most incumbents conflate them. That is why most incumbents are going to lose.
Every one of those "does-not" decisions was made by watching the alternative fail in production. An engineer-built product cannot be told about those decisions. It has to live through them.
That is what an acquirer is buying when they tuck Louie in. Not the 71 modules. Not the moat endpoints. The decisions. Everything else is implementation.