Software That Ships and Dies: The Adoption Gap Your Dev Shop Never Put a Number On
Most custom software gets built, paid for, and then quietly abandoned. The shop got paid the moment it launched, and you kept paying after that, for the subscription, the hosting, and the support retainer, all for a tool your team works around instead of in. That isn't bad luck, it's the model working exactly as it's built to.
What is the software adoption gap?
The software adoption gap is the distance between "we shipped it" and "people actually use it." A piece of software crosses that gap when the team you built it for genuinely changes how they work because of it, and that's a different moment from when it passes QA, or when it goes live, or when the project manager signs off. In most custom software engagements, the shop's job ends at launch, which is precisely where yours begins.
The gap tends to show up in a recognisable pattern. The tool works, technically, and your team uses it when they're forced to, for the compliance field or for the report the boss asks about, but the actual work keeps happening in the spreadsheet, the WhatsApp thread, and the email chain. The software becomes a copy-paste space, a place to log what already happened somewhere else. You paid for a tool, and what you got was a second system of record.
Why does software adoption fail?
Software adoption fails for two reasons, and almost everyone in the industry names only one of them.
The one they name is the buyer-side story: poor training, no internal champions, people resistant to change, unclear value to the end user. All of this is real, and a tool that's hard to use, or that no one ever explained the point of, will die on the shelf regardless of how good the code underneath it is.
The one they don't name is the other half: the shop that built it has no financial stake in whether it gets used.
The moment your software launches, the agency's economic relationship with you is essentially over, because they've been paid. If adoption then fails, they'll happily sell you more hours to "fix" whatever they attribute the failure to, whether that's a UX refresh, a new module, or more training sessions, but the original engagement's incentives all ended at go-live. Compare that to how the agency was paid to build the thing in the first place: every milestone was tied to delivery, with the spec signed off, the development complete, the launch hit, and not one of those milestones was ever tied to your team still using this five months in.
That isn't an oversight, it's how the category is structured, and it's why a whole standalone industry, Digital Adoption Platforms, tools like WalkMe and Whatfix, exists specifically to fix software that nobody uses. When a market creates a billion-dollar category to solve a problem, the problem is structural rather than accidental.
Who is responsible for software adoption after launch?
Here's the uncomfortable answer: right now, nobody with any financial skin in the game.
Your employees have their own workflows to protect, your IT team's job was getting the thing deployed, and the shop that built it has already been paid, so you're left holding the outcome, along with the budget for whatever it takes to fix adoption after the fact.
The training industry and the change-management consultants will tell you that adoption is a buyer-side problem, that you didn't name the right internal champions, that you didn't run enough training sessions, that you didn't measure adoption metrics from day one. Some of that is genuinely true, because adoption is partly a shared outcome, and if no one inside your business is willing to change how they work, no agency can fix that alone. The honest version of this problem requires both sides to show up for it.
But here's what the industry never says: if adoption is partly your problem, it should also be partly your agency's problem, and they should have money on the line to prove it.
Right now they don't, and that's the gap.
What does the adoption gap actually cost?
The numbers that exist on this come mostly from enterprise and SaaS contexts, because that's where researchers can measure at scale, and the picture isn't pretty. Roughly 60% of global businesses report regretting at least one software purchase in the last 18 months, according to Capterra's research, and the majority describe the financial impact as "significant" or "monumental." For SaaS subscriptions, an average company now manages over 300 different software applications, and a substantial slice of those are going unused while the subscription quietly keeps running.
For custom software, the shelfware problem is well-documented qualitatively even where the precise rate isn't independently measured, and you've almost certainly seen it yourself: the internal tool that cost £60K, launched with fanfare, and is now used by two people to pull a monthly report, or the AI-powered intake system that the front-desk team rerouted around within six weeks because it was slower than their email.
The money doesn't come back, and the shop doesn't refund you because your team didn't adopt it. So the next time you need software built, you're either going back to the same shop because they at least know your systems now, or you're explaining the failure to a new one and hoping they'll do better.
Why doesn't the dev shop price adoption in?
Occasionally someone asks this directly, and the honest answer is that it would require the shop to take on risk it doesn't currently carry.
Guaranteeing adoption means owning some share of the business change that actually makes adoption happen, which means naming internal champions, redesigning process, and doing the change-management work that most agencies bill separately, or don't offer at all. It also means holding payment against a real outcome, with a defined threshold, a measurable window, and an automatic trigger, rather than a vague promise of "we'll support you post-launch."
Most shops just aren't set up for that. Their model is time-and-materials or fixed-price-to-spec, and "we delivered what you asked for" is the whole contract, so whether your people end up using it is, in their framing, an operational problem on your side of the wall. That's defensible in a narrow sense, but it's also exactly why the adoption gap exists.
The mechanism, not the promise
The interesting thing about risk-reversal claims in this industry is how quickly they collapse the moment they cost something.
Naked Development marketed "the only money-back guarantee in the industry," and when a build went bad, with independent engineers judging the code unlaunchable, the guarantee dissolved into legal disputes and refund resistance. The claim was real enough, but the mechanism behind it wasn't.
A goodwill promise holds when nothing goes wrong, whereas a structured instrument holds precisely because it's defined, with a specific metric, a specific window, and a specific financial consequence if the threshold isn't met. Those two things are not the same. And the difference matters for adoption in particular, because if an agency says "we care about adoption" but there's nothing written down, no money at risk, and no defined measure of success, then you're right back to trusting a pitch. The adoption gap is exactly the kind of problem that requires the mechanism rather than the claim.
What should you ask a dev shop about adoption?
If you're evaluating a custom software agency and adoption matters to you, and it should, because that's the whole point of building the thing in the first place, here are the questions that separate a real commitment from a well-worded promise:
What's your definition of adoption success for this project? If they can't define it in measurable terms before the build even starts, then they haven't really thought about it. What you want is a specific threshold, agreed in writing before a line of code is written, covering what percentage of your team is using it, how often, and doing what.
What happens to your fee if adoption doesn't happen? A shop that can't answer this doesn't have a mechanism, while a shop that has a real answer, with a percentage held, a defined window, and an automatic trigger, is worth a closer look.
What change-management work do you include? Adoption isn't purely a software problem, so the agency that builds your tool should have a view on naming internal champions, on redesigning the process the tool is meant to replace, and on what "success" actually looks like in your team's daily workflow. If they hand you a tool and wish you luck on the training, the adoption gap is already open.
Can I see something working before I commit real budget? This is the most useful question of all, because it forces the conversation out of promises and into evidence. A shop that will build you a real, working version of your product, not a wireframe and not a clickable mockup but an actual functioning thing with real business logic, before you've paid for the full build, is betting on their own capability rather than asking you to bet on it for them.
The adoption gap is a pricing problem in disguise
Here's the frame that makes everything else clear: the adoption gap exists because nobody in the current model charges for the outcome, so nobody is accountable for it.
The shop charges for delivery and you pay for delivery, and the outcome, whether your team actually uses the thing, whether it changes how your business operates, whether it earns back what you spent, floats free of the contract entirely. When the outcome isn't in the contract, it isn't in the incentives, and when it isn't in the incentives, it isn't in the work, and when it isn't in the work, you get software that ships and dies.
Fixing this isn't complicated in principle, because it requires just one thing: the agency holds some of its own money until the software is genuinely adopted, against a defined threshold, in a defined window. Not a goodwill gesture, but a structured instrument with real financial consequences. That's it. The shop that will do that is the shop that thinks about adoption before it's your problem to solve.