There’s a graveyard of internal apps in every large organisation. Custom-built portals nobody logs into. Mobile apps with 12 downloads — all from the development team. Dashboards that took six months to build and display data nobody checks.

It happens over and over: someone in leadership has an idea, the tech team builds it, and three months after launch, usage flatlines. The project gets quietly shelved. Nobody talks about it at the next town hall.

This pattern wastes enormous amounts of money. More importantly, it wastes your team’s time and erodes their trust in the decision-making process. If you want to stop the cycle, you need to understand why it keeps happening.

The “Build It and They Will Come” Fallacy

The fundamental mistake is assuming that availability creates demand. It doesn’t.

Just because something can be built doesn’t mean it should be. And just because a senior leader thinks it’s a good idea doesn’t mean the intended users agree. The gap between what leadership imagines people want and what people actually need is often vast.

A Harvard Business Review study found that nearly 70 percent of digital transformation initiatives fail to deliver their intended outcomes. The primary reason isn’t technical failure — it’s misalignment between the solution and the actual problem.

How It Usually Goes Wrong

The solution comes before the problem. Someone sees a new technology or hears about what a competitor is doing and decides “we need one of those.” There’s no analysis of whether it addresses a real pain point. No validation with the people who’d actually use it. The entire project is solution-first.

The wrong people are consulted. Leadership signs off based on a slide deck. Middle management nods along because they don’t want to be seen as blockers. The actual end users — the people who’ll live with this thing daily — aren’t meaningfully involved until user acceptance testing, by which point it’s too late to change direction.

Success is measured by delivery, not adoption. The project is considered “done” when it ships. Nobody sets adoption targets. Nobody tracks usage after launch. Nobody asks, six months later, whether it was worth it.

IT builds what they’re told to build. In many organisations, IT is an order-taker. A request comes in, requirements get documented, and the team builds it. There’s no pushback, no challenge, no “have you validated this with users?” Because that’s not their role — or at least, that’s how it feels.

What to Do Instead

Talk to users first. This sounds painfully obvious, but it’s skipped far more often than you’d think. Before writing a single line of code, sit down with the people who’d use the tool. Understand their current workflow. Watch them work. Ask what’s frustrating, what’s slow, what they wish they could do differently.

You’ll often discover that the problem is different from what was assumed. Sometimes there’s no problem at all — the existing process works fine and people just need a small tweak, not a new application.

Build the smallest possible version. Don’t commit to a six-month build. Create a prototype. A spreadsheet. A Figma mockup. A basic workflow in an existing tool. Put it in front of real users and see if they engage with it.

If people don’t use a free, available prototype, they definitely won’t use a fully built application. Kill the project early and save yourself months of wasted effort.

Set adoption metrics before you start. Define what success looks like in terms of actual usage. How many daily active users? What percentage of the target audience? How often? If you can’t define these upfront, you don’t have a clear enough understanding of who this is for.

Involve your tech team in discovery. Engineers and developers often have the best instinct for what’s feasible and what’s overcomplicated. When they’re involved early — during the problem definition phase, not just the building phase — they can suggest simpler approaches that leadership might not have considered. Organisations that get AI implementation help from experienced consultants often start with this discovery phase specifically to avoid building the wrong thing.

The Off-the-Shelf Question

Before building anything custom, ask: does something already exist that solves this?

The SaaS market in 2026 is mature enough that there’s a pre-built tool for almost every common business need. Project management, CRM, HR workflows, expense tracking, document approval — all of these have dozens of affordable, well-supported options.

Custom development makes sense when your process is genuinely unique or when off-the-shelf tools can’t integrate with your existing systems. But “we want it to look exactly the way we imagined” isn’t a valid reason to build from scratch. That’s ego, not strategy.

Check platforms like G2 to compare existing solutions before committing to a custom build. You might find that a $20-per-month subscription solves the same problem that a $200,000 custom project would.

The Culture Problem

Ultimately, the “build apps nobody asked for” pattern is a symptom of a broader cultural issue: organisations that value activity over outcomes. Shipping a new tool feels like progress. Running a discovery process that concludes “we don’t need to build anything” feels like failure.

But it’s not. Saying “no” to a bad project is one of the highest-value decisions a technology leader can make. Every project you don’t build frees up capacity for the ones that matter.

The next time someone walks into your office with a brilliant idea for a new app, ask one simple question: “Who have you talked to about this, and what did they say?”

If the answer is “nobody yet,” you know exactly what to do next.