Why Most Mid-Market Software Projects Fail Before Anyone Writes Code

I've been building custom software for middle-market companies since 2008, and I'll tell you the thing that still surprises people. Most software doesn't fail because the engineering was bad. It fails because the project was built on a misunderstanding of the problem. By the time anyone notices, the money is spent and the people in the field have quietly gone back to the old way of doing things.

I talked through a lot of this recently on the NaiL podcast with George Paladichuk (YouTube, June 2026). In our industry, the failure rate runs above 70%. Our success rate with clients at Feature[23] has held north of 95% for over a decade. That gap isn't about talent. It's about how the work gets framed before a single line of code gets written.

So let me walk you through the patterns I've watched cost mid-market operators time, money, and growth, and what the companies that get it right do differently.

Why Do Most Software Projects Fail?

Most software projects fail at the decision stage, not the build stage. PMI found that 47% of unsuccessful projects miss their goals because of inaccurate requirements management, with about 5% of every dollar wasted on poor requirements (PMI, 2014). The problem usually isn't the code. It's that the project solved the wrong thing.

I see the same pattern repeat with newer technology. In 2024, RAND found that more than 80% of AI projects fail, roughly twice the rate of IT projects that don't involve AI, and the single biggest root cause is stakeholders misunderstanding or miscommunicating the problem the technology was meant to solve (RAND, 2024).

Here's how I think about it. There's a difference between building software and building software that moves a business forward. Almost every project worth doing does one of three things: it makes the customer's life better, it grows the top line, or it improves the bottom line. When a project can't tell me clearly which one it's doing, it's already in trouble.

If you're running a mid-market company, that's the real risk. You don't need me to convince you that off-the-shelf won't solve certain problems. You already know that. The question is how to invest so the money compounds instead of evaporating.

What Is the Understanding Gap?

The understanding gap is the distance between what leadership thinks is happening, what middle management thinks is happening, and what the people doing the work actually see every day. Interview those three groups separately and you'll often find they don't describe the same business. Yet leadership is making strategic decisions, and funding software, based on a version of the problem the field would barely recognize.

That gap is where projects quietly die. You build for twelve months, the system goes live, and the experts in the field won't use the tool because it didn't solve their problem. Then leadership asks why the project failed. It failed because it was built on a problem that wasn't real.

This is also why franchise and multi-location operators have a hidden advantage. Every location adds another layer of experts who sit even closer to the problem. The companies that win treat that as a source of signal, not an operational drag. I watched this happen with one of our clients. A franchise owner at a conference told us that seeing their territory data a certain way would change how they made decisions. We modeled it with AI-assisted tooling, had a prototype within days, and rolled an improvement across the entire platform inside two weeks. One expert bothered to voice an idea, and we captured it instead of ignoring it.

So the first thing my team maps on any new engagement is whether there's an understanding gap. Before scope, before architecture, I want to know whether leadership trusts that the people in the field see the problem accurately. If they don't, no amount of engineering is going to save the project.

What Is the Operational Tax of Bad Software?

The operational tax is the ongoing cost of bad software that never appears as a line item but shows up everywhere else. It presents itself as a worse customer experience, a worse employee experience, or a worse partner experience. The cost is real even though no report names it. Nationally, the cost of poor software quality in the US reached at least $2.41 trillion in 2022, with accumulated technical debt around $1.52 trillion (CISQ, 2022).

Most of the time the idea isn't even wrong. The execution is. A company picks a solution that ends up creating more operational tax than the value it delivers, and the damage shows up in the experience long before it shows up in the numbers. The hard part is that spotting that tax takes experience, because the average employee is used to being handed decisions they had no part in and just making do.

We take it seriously enough that we'll walk away over it. There are engagements where the operational tax is so high relative to the business value we could deliver that the honest thing to do is tell a client we're not the right partner, rather than keep spending their money chasing a return the constraints won't allow.

You can measure a lot about a company's culture by whether it's willing to look at that tax honestly. The healthiest version is when a team can say out loud, "this is costing us more in friction than it's worth," and actually act on it. I'd pair that honesty with a clear-eyed look at the build versus buy decision before you commit to any platform.

How Do You Decide What to Build and What to Buy?

Build what protects your competitive advantage. Buy everything else. The deciding question isn't cost or capability, it's whether the software touches what I call your secret sauce, the parts of your operating model that make you hard to compete with. Buy generic software for those parts and you quietly erode the very thing that sets you apart. Meanwhile, companies use only about half the SaaS licenses they pay for, wasting an average of $21M a year (Zylo, 2025), so "just buy it" is rarely as cheap as it looks.

The logic is simple once you frame it right. If you build your competitive advantage on an off-the-shelf platform and then ask the vendor to change it for you, you've just handed that same capability to every competitor on the same platform. You also end up reshaping your operations to fit the software instead of the other way around.

So the test I use is honest and specific. Would you describe this capability as "standard for our industry" or "the way we win"? Standard means buy. The way we win usually means build, because then you own the intellectual property that makes you different.

I'll give you an example of the discipline. A client came to us asking for a custom platform. We spent three months making them shop off-the-shelf options first, to be certain a build was warranted, before we'd commit them to one. That's the bar. Build is the answer only when the software protects something worth protecting.

This calculus also shifts with scale. At ten or fifteen locations, build versus buy is one kind of conversation. At a hundred and fifty, a 2% improvement per location across the whole network turns into real money fast, and protecting the operating model becomes a strategic priority rather than a preference.

How Does Impact Mapping Change the Conversation?

Impact mapping flips the starting question from "what should we build" to "what impact are we trying to make, and what are our options." Custom software is only one of those options, and a lot of the time it's not the best one. The framework comes from Gojko Adzic's book Impact Mapping, and I still use it on client calls more than a decade after it came out.

The value is that it stops you from defaulting to a tool before you've defined the goal. I've ended calls by telling a prospect to go hire a few summer interns instead, because the problem was short-term and a custom build would have added permanent complexity and cost for no lasting return. That's not how most firms talk to a paying prospect. It's just what happens when you start from impact instead of from the product.

It also protects you from the pressure to chase whatever everyone online says you should be doing. When a company tells me it "needs AI," I invert the question. What impact are you actually trying to make, and is AI even the best way to get there? More often than you'd think, the real constraint sits somewhere else, and the tool that looked essential turns out to be the wrong place to start.

There's an older idea underneath all of this, the distinction between the engineering method and the scientific method. The scientific method exists to create knowledge. The engineering method exists to solve problems with the resources and constraints you actually have. Good software work is engineering. It starts from the real problem and the real constraints, not from whatever technology happens to be in fashion.

What Made One Client's Software an Acquisition Asset?

Software becomes an acquisition asset when it delivers efficacy at scale, the ability to grow without losing consistency. When Superior Fence & Rail was acquired, the deal documentation cited its Fence360 platform as a core driver of value. That claim came from the buyers and advisers, not from us.

What the technology unlocked was the thing a franchise model exists to do: scale profitably, one location at a time, without the operating model drifting. The platform held consistency, visibility, and repeatability across the network, while still leaving room for each location to adapt to its local market. People in Oregon buy different fences than people in Florida, and the system has to respect that. Buyers on the acquisition side don't want to see human-intensive systems doing work that technology should be doing.

The harder truth is that this only works if leadership commits early. At fifteen locations, betting on technology to protect the operating model is an act of belief. At a hundred and forty and growing, it's proof. The leadership team there was aggressive about technology from the start, and they earned the payoff. The companies that treat their operating model as a competitive advantage, and use software to protect it, are the ones that turn belief into an asset somebody else will pay for.

Does AI Change Any of This?

AI raises the stakes but it doesn't change the rules. The same failure pattern just shows up faster, because AI is so easy to deploy that companies skip right past defining the problem. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025 (Gartner, 2024). The share of companies abandoning most of their AI initiatives jumped to 42% in 2025, up from 17% a year earlier (S&P Global via CIO Dive, 2025).

Used well, AI is a real advantage. My teams build faster, at lower cost, and diagnose problems in a fraction of the time, because we can funnel everything into a tool and let it find the outliers. Clients now show up with working prototypes instead of a Word document, which means projects start further along than they ever have.

But a prototype isn't a finished asset. You can use AI to build software an order of magnitude faster, and you still have to own and maintain the thing once it exists. It's like a car. You can't buy it and never change the oil. So the responsible path is to treat AI as research and development until you're sure it fits who you are, then deploy. Reaching for it because the market says you should is just the understanding gap wearing newer clothes.

Let's Talk It Through First

We run something at Feature[23] we call a good neighbor policy. If you're weighing a software investment and want to pressure-test the thinking, I'll get on a whiteboard with you. No contract, no invoice. The fastest way to de-risk a build is a real conversation about the problem before anyone scopes a solution. Same as I'd do if I passed you taking the garbage out in the morning. Start here: feature23.com.

Frequently Asked Questions

Why do most software projects fail?

Most fail for business reasons, not technical ones. PMI found 47% of unsuccessful projects trace back to inaccurate requirements (PMI, 2014). The project solves a misunderstood problem, so the people meant to use it never adopt it. The fix is closing the understanding gap before you commit budget.

What is the operational tax of bad software?

It's the ongoing cost of poor software that never appears as a line item but shows up as worse customer, employee, or partner experience. The cost of poor software quality in the US hit at least $2.41 trillion in 2022 (CISQ, 2022). Spotting it early takes experience and an honest culture.

Should mid-market companies build or buy software?

Build what protects your competitive advantage and buy everything else. If a capability is "the way we win," own it. If it's standard for your industry, buy it. Companies already waste about $21M a year on unused SaaS licenses (Zylo, 2025), so buying isn't automatically the cheaper path.

Is AI making software projects more or less likely to fail?

More likely, when teams skip defining the problem. RAND found over 80% of AI projects fail, with misunderstanding the problem as the top cause (RAND, 2024). AI is a real advantage when it fits the business, but deploying it because the market demands it just repeats the same mistake faster.

What is impact mapping?

Impact mapping, from Gojko Adzic's book of the same name, is a framework that starts with the impact you want and works backward to your options. Custom software is one option among several. It keeps you from defaulting to a tool before you've defined the goal, and it often reveals a cheaper, simpler path.

The Bottom Line

The companies that get software right aren't the ones with the best engineers. They're the ones honest about who they are, clear on the problem, and disciplined about building only what makes them hard to compete with. Close the understanding gap. Watch for the operational tax. Build your secret sauce and buy the rest. Do that, and software stops being a gamble and starts compounding into an asset, the kind a buyer will one day point to as the reason your business was worth more.