The best system is the one your team still opens on a Tuesday afternoon. Not the one that demos best, and not the one with the longer feature list.
We would rather ship something modest that gets used than something impressive that gets ignored. That is not humility, and it is not ambition with the volume turned down. It is a constraint on the design, and it decides more about whether a build survives its first month than any choice of technology will.
The demo is not the test
A demo runs under the most favourable conditions the software will ever see. Somebody who knows it is driving. The data has been tidied. Everyone in the room has set aside half an hour for the express purpose of watching it work, and most of them want it to work, because they picked it.
Tuesday afternoon is the opposite of that. The person is behind. Something else is on fire, nobody has set aside time to learn anything, and the old way of doing it (the phone call, the spreadsheet, asking the person two desks over) takes about four seconds and has never once failed.
Software is adopted or abandoned in the moments when nobody is paying attention to it.
Modest is a design decision, not a smaller budget
Shipping something modest usually means building more, not less. The difficulty has to go somewhere, and the only real choice is whether it sits in the build or in the person using it.
The impressive version tends to push it onto the person. More options, more configuration, more judgement required at the point of use, every bit of it defensible on its own terms and all of it arriving on a Tuesday. Say a stock system that can model any warehouse layout a customer might have. It is genuinely more capable than one that only models yours. It is also the one where somebody has to sit down and describe your layout before it does anything at all, and that description turns out to be a fortnight of work nobody has spare in the week it lands.
Capability that has to be configured before it helps is capability the customer pays for twice.
The modest version absorbs the same difficulty into decisions made once, by people who can afford to spend a day on a question the user has four seconds for. That is more work rather than less, and it is where the case for building rather than buying gets settled in practice. A bought system has to make those decisions generically. A built one can make them for your floor, which is the only reason building is ever worth the trouble.
Restraint is exactly what a supplier would recommend
Every argument for restraint is also an argument for the cheaper, easier job, which is a good reason to distrust it.
Building less is cheaper, faster and easier to deliver on time. "We designed for adoption" is available as a justification for every corner that was quietly cut, and from the outside a considered constraint and a budget that ran out look identical. Anyone arguing for restraint is arguing for the option that happens to suit them.
The stronger form of the objection has nothing to do with incentives. Plenty of demanding systems do get adopted. A team can be brought to a harder tool when the payoff is worth the trip, and treating the way people work today as fixed is its own kind of failure. Sometimes the reason nobody uses the better way is that nobody has done the work of making the change, and filing that under "adoption" turns an unwillingness to lead into a design principle.
Both of those hold. The distinction that survives them is whether the restraint can be named out loud: which capability was deferred, what it would take to add, and what would have to become true for that to be worth doing. Adoption work is real work and it can be planned like any other. Somebody owns the rollout, somebody closes the old path, somebody is accountable when the thing sits unopened. What cannot be done is assuming it.
Working out which case you are in is what the assessment stage exists for, and it is why we would rather say a thing will not get used before it is built than afterwards.
Four questions that settle it before anything is built
How many steps stand between opening it and getting something you wanted? Count them honestly, including logging in and choosing which thing you are looking at. Every step is a place where the old way wins.
Does it live where the work already happens? A fifth browser tab has to be remembered. Something that turns up inside the system already open in front of somebody does not.
What happens when it is wrong? It will be wrong. If the person can correct it and carry on, they will keep using it. If being wrong means working around it, they will work around it permanently, you will never hear about the afternoon that decision got made, and you have bought the expensive kind of tool.
Who does it make look bad? Nobody asks this one, and it is the one that gets missed entirely, because it is not a technical problem and nothing in a specification has a place to record it. A tool that shows one team's numbers to another team for the first time carries a political cost, and that cost is paid by the person you are asking to open it on a Tuesday.
Questions people ask
Does this mean you talk clients out of the ambitious version?
Sometimes, and we say so plainly when the assessment points that way. Our recommendations always include what we would not build, with the reasoning attached so you can disagree with it. We would rather lose a sale than sell something that ends up unopened.
How can anyone know a system will be used before it exists?
Nobody can know. That is why you see a requirements document and a working demo before committing to a build: it keeps changing your mind cheap while changing your mind is still cheap. A demo put in front of the people who will actually use it answers this better than any amount of discussion about it.
Is a modest system just a cheaper system?
Not reliably. Moving difficulty out of the interface and into the build is work, and it can cost the same or more than the version that exposes everything. Scope decides that, which is why we do not publish a figure for either.
What to do before you sign off the next build
Take the thing you are about to commission and name the Tuesday. Who opens it, at what hour, under what pressure, and what they would do instead if it were not there. Name a job rather than a department.
If nobody can answer that, the specification is not finished, and no amount of capability will rescue it. If somebody can, you have written the test that matters, and it is worth handing to whoever builds the thing.