The Uncomfortable Statistics
The Standish Group's CHAOS Report has tracked software project outcomes for decades. The numbers have improved over time, but the picture is still sobering: a significant portion of custom software projects are either delivered late and over budget, cancelled before completion, or delivered on time but with so little of the original scope that they're functionally useless.
The organisations that commission these projects aren't incompetent. Many of them are running sophisticated businesses. And the engineering teams building the software aren't unskilled — the majority are experienced professionals.
So why does this keep happening?
The Failures Are Almost Never Technical
When a software project goes wrong, the post-mortem usually uncovers one of a handful of root causes. Almost none of them are "the developers didn't know how to write the code."
The Scope Was Never Actually Defined
"We need a platform that manages our operations" is not a specification. It's a category. Custom software built against ambiguous requirements will be delivered against ambiguous success criteria — and the business will spend months after launch arguing about whether the thing they received is the thing they asked for.
The requirement gathering phase isn't overhead. It's the work that makes everything else cheaper. Every hour spent precisely defining what the software needs to do and under what constraints saves three to five hours of rework later. The projects that succeed invest heavily in this phase — wireframes, user stories, acceptance criteria, explicit decisions about what's in scope and what's not.
The Architecture Was Chosen for the Wrong Reasons
Technical decisions get made for a lot of reasons: familiarity with a particular framework, a blog post someone read, what the last project used, what a senior engineer is comfortable with. Most of these reasons are reasonable. None of them are sufficient on their own.
The right architecture for a custom software project depends on the specific requirements: expected load, scaling patterns, integration constraints, team size, deployment environment, regulatory requirements, and long-term maintenance expectations. A microservices architecture that makes perfect sense for a team of 40 engineers is often the wrong choice for a team of 4. A monolith that's fast to build and easy to operate can become a maintenance nightmare if it's not designed with clear internal boundaries from the start.
The architecture choices made in the first two weeks of a project are the hardest and most expensive to reverse. Getting them right requires engineering experience with similar systems — not just technical skill in general.
The Client and the Agency Were Solving Different Problems
This is the most common failure mode, and the most preventable. The client knows their business problem in detail. The agency knows how to build software. The two parties are working from different mental models of what the project is, and nobody noticed until the software was built.
A client who says "we need a dashboard for our operations team" is thinking about the six people who will use it every day, the specific workflows they're trying to streamline, and the business decisions the dashboard needs to support. An agency that hears "dashboard" starts thinking about data models, chart libraries, and real-time updates.
Both of those things matter. The problem is when they stay in separate conversations instead of being resolved into a shared understanding before any code is written.
What the Projects That Work Do Differently
They Define Success Before They Start
Not "the software is delivered" — that's not success, that's completion. Success means: the operations team can process orders 40% faster. Support tickets related to account management drop by half. The finance team can close month-end without the spreadsheet workaround they've been using for three years.
Concrete, measurable outcomes. Outcomes that can be tested in production, not just demonstrated in a staging environment.
They Build Less, Faster, and Learn From It
The instinct when commissioning software is to specify everything upfront and build it all at once. This instinct is wrong. Requirements change. What looks essential in planning turns out to be rarely used. Features that seemed like nice-to-haves turn out to be the things users can't live without.
A phased build that ships a core set of functionality to real users within weeks — not months — catches misalignments early, when they're cheap to correct. The best custom software projects treat the first release not as the finished product but as the first experiment.
They Treat Engineering Partners as Partners
The agency relationship works best when the client has direct access to the people making technical decisions, when the client's domain expertise is actively solicited (not just documented in a requirements doc), and when both parties are held to the same standard of clarity.
A fixed-price contract where the client hands over a PDF and waits for software to appear is almost guaranteed to produce the wrong thing. Not because of bad faith — because software requirements are never complete enough to build from without ongoing dialogue.
What to Look for When Choosing an Agency
The questions that matter aren't about the technology stack. They're about process:
- How does the team approach requirements definition, and can you see examples?
- What does the first four weeks of engagement look like, specifically?
- How are scope changes handled, and who makes those decisions?
- What does the team do when they disagree with a client's technical decision?
- How have past projects gone wrong, and what did the team do about it?
An agency that can answer those questions with concrete specifics — real examples, real decisions, real problems they've navigated — is more valuable than one with an impressive portfolio and vague process language.
If you have a software project you're planning — or one that's already in trouble — the most useful thing you can do right now is talk to an engineer about it before the scope is locked.
We work through the requirements honestly before we quote, because we've seen enough projects fail from unclear foundations to know that skipping that step doesn't save time. Start a conversation and let's figure out what you actually need to build.