Custom software projects in the $200K–$400K range go over budget constantly, by 30 to 50 percent on average. Not because vendors are dishonest or teams are undisciplined, but because the number you agreed to was built before anyone actually understood the system they were pricing.
The estimate came from a requirements document, a few stakeholder calls, and a review of API documentation. It captured what the system should do. It did not capture how your existing systems actually behave, what your operations team actually enforces, or what compliance actually requires. By the time those things became visible, the SOW was signed and the contract was fixed.
That is the problem. The estimate was wrong before development started, because it was made from the outside.
You gave them everything they asked for. The problem started before a single line of code was written.
According to McKinsey and University of Oxford research across more than 5,400 IT projects, the average large IT project runs 45 percent over budget. One in six exceeds the original budget by 200 percent or more.
BCG surveyed C-suite executives across 25 industries and found that nearly half reported more than 30 percent of their technology projects coming in late and over budget. This held regardless of whether teams used agile or waterfall. The methodology was not the problem.
The overruns are not concentrated in projects with bad vendors or difficult clients. They show up everywhere, consistently, which means the causes are structural.
Custom software projects in the $200K–$400K range overrun by 30 to 50 percent on average. The causes are structural and largely preventable.
Before going into each cause in detail, here is the framework. Every software project budget overrun traces back to one or more of these four gaps. All of them open during estimation.
These four gaps are predictable. They appear in roughly the same sequence on most projects, and they are all visible before the SOW is signed, if the team building the estimate has actually been inside your system.
Here is a scenario that plays out constantly.
A CTO needs a new system in five months. The vendor does two weeks of discovery: calls with stakeholders, a look at the existing architecture, a review of the requirements doc, and comes back with a fixed-price SOW. The CTO signs because the timeline feels right and the number is within budget.
Three months in, the vendor hits the first integration and discovers the existing system does not behave the way anyone described it. Change request, then QA starts and the operations team sees the system for the first time and realizes forty workflows are wrong. More change requests raise and the five-month project is now eight months and 70 percent over budget.
None of that was malicious. It was the result of a discovery process that produced a document instead of understanding.
What separates a real discovery phase from what most vendors actually deliver:
BCG found that when technology leaders were involved in strategy development from the start, meaning they had actually seen the problem rather than just been handed a brief, project success rates were 154 percent higher than projects without that early involvement.
That is not about seniority. It is about proximity. The people building the estimate need to be inside your environment when they are forming it, not reading a document someone else produced.
A well-structured custom software development process treats discovery as the most important investment in the project, not a formality before billing begins.
Your vendor will tell you they scoped the integrations. What that usually means is they read the API documentation.
API documentation describes how an endpoint is supposed to behave under standard conditions. It does not describe how it behaves in your environment, against your data schema, with your authentication setup, under your traffic patterns.
Here is a real scenario from healthcare. A team scopes an HL7 integration against a major EHR system. The documentation is thorough. The staging environment behaves exactly as expected. Development goes fine through sprint four. In sprint five, the integration hits the client's production environment, and three edge cases appear that the documentation never mentioned, because those edge cases only occur when you combine a specific patient data schema with a specific authentication token structure the client's IT team had configured years ago.
The work from sprint two needs to be rebuilt. The vendor sends a change request and the client pushes back because this should have been in scope. Both are right. The documentation did not show it. Nobody tested it in the actual environment before the SOW was written.
Teams building run into the same thing. Payment gateways that work perfectly in staging surface undocumented behavioral differences in the client's production environment. Always in sprint five or six, always after the work they affect has already been built.
The timeline problem this creates:
By the time you know the integration is wrong, you have already paid for the work it affects. Either way, whether the vendor absorbs it or a change request goes out, you pay for a risk that was visible to anyone who had actually tested your integrations in your environment before the contract was signed.
Here is how this one goes.
Your operations lead has been processing insurance claims for eleven years. She knows the routing logic by heart. Case type B goes to reviewer group 3, not group 1, because group 3 handles accounts above a certain threshold, and that threshold was changed in 2021 after a compliance review, but the change was never documented anywhere because everyone who needed to know just knew.
Your vendor builds a system that routes case type B to group 1. Because that is what the requirements document said. Because nobody asked your operations lead, because she was not in the discovery meetings.
This version of the system gets to QA. Your operations lead uses it for the first time. She files a change request. Then another. Then fourteen more, each one individually reasonable, collectively representing three weeks of rework.
Every organization runs on rules like these. They live in the heads of the people who do the work every day. They feel obvious to those people, which is exactly why they never get written down.
When a vendor scopes your project, both of you assume these rules will surface naturally during development. They will. Just not at the point where they are cheap to address.
The rules are not hidden: A team embedded in your operations for two weeks will run into most of them directly: in your existing workflows, in your current systems, in direct conversations with the people who actually do the work. They are only invisible to a team that was never inside your operations before they priced the work.
Here is a scenario that plays out specifically in healthcare and fintech builds.
The SOW says "system will be HIPAA compliant." Everyone nods and development starts.
Month five, the security review begins. The team discovers that the data architecture needs to be restructured to properly isolate PHI. The audit logging was not built into the original architecture. It was going to be added later. The BAAs with three third-party vendors have not been executed yet. The risk assessment was never done.
None of this is in scope. All of it is now blocking the launch.
HIPAA compliance is a workstream with its own deliverables, its own timeline, and its own cost. None of that fits inside a feature list.
What properly scoped HIPAA compliance actually includes:
According to compliance implementation data from Accountable HQ, properly scoped HIPAA work adds 8 to 16 weeks and 20 to 30 percent to development costs.
When it is not scoped at all, those weeks and that cost do not disappear. They show up mid-project as unplanned work on a fixed-price contract, at the exact moment when your team has the least capacity to absorb them.
A fixed-price contract feels like protection. You agree on a number, the vendor is accountable to it, and your budget is predictable.
That is not what actually happens.
A fixed-price contract does not eliminate scope risk instead it relocates it. Everything your SOW does not explicitly cover becomes either a change request or a cost your vendor absorbs. When discovery was rushed and the SOW was built on assumptions, the volume of change requests in QA directly reflects the gap between what was estimated and what is real.
Here is the mechanism that makes it painful:
Each change request is individually defensible. Collectively they represent the cost of estimation that was built from the outside.
The risk is that a number agreed before anyone fully understood your system will prove optimistic once development hits production. A fixed-price contract ensures you feel that optimism as a financial problem rather than a scoping conversation.
Before you sign anything, you need to know one thing: did the vendor build this number from what they observed about your system, or from what you told them about it?
Those are different things. The first is an estimate. The second is a guess with a dollar sign on it.
Ask these five questions. The answers will tell you which one you have.
If you are getting red flag answers, the number in front of you is based on assumptions. The change requests are already written. They just have not been sent yet.
Most CTOs have never seen a properly scoped custom software project. Not because they are inexperienced, but because most vendors do not do real discovery, and most clients do not know what to ask for.
A $300K project scoped properly looks different from the start. The discovery phase runs four to six weeks and is led by a dedicated technical lead instead of a project manager running stakeholder calls.Your operations team is in the room and compliance is on a parallel track with its own timeline.
Here is what a well-scoped project produces before the SOW is signed:
An integration behavior report: Each third-party system tested in your environment, with documented behavior differences between official documentation and actual production behavior. For healthcare projects, this means HL7 endpoints and EHR integrations tested against your specific patient data schema, with edge cases identified and priced before the contract is written.
A business rules inventory: extracted directly from your operations team. An actual list of the 150 to 200 rules your system must enforce, written down for the first time, reviewed and signed off by the people who enforce them. This document alone prevents the majority of QA-stage change requests.
A compliance workstream plan: separate from the feature roadmap. HIPAA, SOC 2, or HITRUST scoped as their own body of work with its own timeline, technical dependencies, and budget line. Sized correctly: 8 to 16 weeks running parallel to development.
A risk-adjusted estimate: A well-scoped SOW shows what the base scope covers, what is explicitly excluded, and what conditions would trigger a scope change. Ambiguity is named upfront.
When you see all four of these, the estimate in front of you reflects what your system actually is. When you do not see them, the number is optimistic by construction. The only question is how optimistic.
For context on what this decision-making looks like across the full build-vs-buy spectrum, the custom software development benefits guide covers when a proper scoping investment pays off versus when it does not.
The four gaps above are invisible from a distance. They only surface when someone is actually inside your environment during estimation.
Ideas2IT's Forward Deployed Engineering model works differently: instead of engineers reviewing your brief from their office, an FDE embeds inside your environment from day one, working in your stack, in your standups, against your OKRs. By the end of week two, they have hit your integration endpoints in production, extracted business rules directly from your operations team, and identified what compliance requires as a separate workstream. The number that comes out of that engagement reflects what your system actually does.
If the SOW in front of you does not show an integration behavior report, a business rules inventory, a compliance workstream plan, and a risk-adjusted estimate, the number is built on assumptions.
Bring it to Ideas2IT before you sign. Within two weeks, you will receive a written scope risk assessment that maps your SOW against the four gaps above, names the specific assumptions in the estimate, and tells you what a grounded version of the scope would need to include. No sales process attached.
Request a scope risk assessment
Didn't find what you were looking for?
