AI has collapsed the time it takes to build software, and vendors can now say yes to almost anything. When a technology company builds what each customer tells it to build, it stops being a product company and becomes a custom development shop. Over time, the software gets harder to maintain, harder to explain, and less useful to everyone, including the fleet that requested the change.

When an end-user asks for a feature, the job is to figure out what problem the feature is supposed to solve. That means working closely with the people who feel the problem every day: the dispatchers, planners, and account managers who sit in front of the screen and make the calls. If a vendor's answer to "can you build this?" is always yes, treat that as a reason to ask harder questions.

The right partner should approach product development as a two-phase process.

Phase 1: Build to learn 

The right vendor works with current customers as design partners. They put early versions in front of their users and gather feedback week over week. The goal is to understand the decision the user is trying to make.

This phase often uncovers a gap that catches fleets off guard: the difference between how people believe their business runs and how it actually runs. A planner will look at a recommendation and say, "I would never assign that driver to that load." But if they look at the historical data across the whole network, they often find that the fleet made that exact assignment routinely.

A machine will happily follow whatever rule you give it. Tell it to optimize for driver preference, and it will, at the expense of profit. If you tell it to follow a hard constraint, it will follow it even when the network has been quietly ignoring it for years. Good product development means bringing in the fleet’s learned behavior while still optimizing for the outcomes leadership cares about and being realistic about what users will accept.

Phase 2: Build to earn 

When one customer asks for something, the test is whether it represents a repeatable pattern across the customer base and the industry or a constraint unique to a specific fleet's network. Constraints unique to one fleet can be handled through configuration, while patterns that show up across many fleets are worth building into the product.

This distinction is what keeps a product from deteriorating. Software shaped by patterns across many carriers tends to hold up better as a fleet grows, changes lanes, or brings on new planners than software bent to fit one operation's preferences at one point in time.

What success looks like for the user

The most useful measure of whether any of this is working comes from watching real sessions. When a planner opens the platform, they should be able to answer two questions quickly:

1. What is the most important thing I can do right now?
2. Do I have the information I need to trust that decision?

If they have to jump to the TMS, a spreadsheet, and a phone call to justify a recommendation, the product has failed them, regardless of how good the underlying optimization is.

A good vendor will record user sessions for exactly this reason. Dead time in a session tells the software provider where the interface is getting in the way. A planner who leaves to finish an assignment in the TMS and then comes back tells the vendor that either the recommendation was wrong, or it was not explained in a way that matched how they think about planning.

Explainability without overload

Fleet leaders should understand this tension when they evaluate AI tools. On any single truck, an experienced planner can probably beat the machine. Across 100 or 1,000 trucks, with the full context of the network, the machine wins. The challenge is getting planners to trust recommendations at scale, and the instinct is to show them everything.

More detail tends to backfire. What users need is the least amount of information required to make the decision in front of them. When a planner asks why a particular driver did not receive an optimal match, the answer should be specific to that assignment and readable in seconds.

What fleet leaders can do

• Ask vendors how they decide what to build and be skeptical if the answer is "whatever customers ask for."
• Involve planners and dispatchers early and expect the data to contradict some of what they tell you about how the fleet operates.
• Measure adoption by whether users stay in the tool to make decisions. Login counts say very little about that.
• Push for explanations that are short and tied to the specific decision.

The vendors worth partnering with will welcome those questions. The ones who just want to build the button will not.