Why Custom Software Projects Go Over Budget

Custom software projects go over budget for three reasons that are visible before the first line of code is written: the scope was defined by the buyer alone without engineering input on complexity, the estimate didn't include integration work with existing systems, and the engagement model incentivised the vendor to discover scope creep rather than prevent it.

Over 8 years and 50+ projects at Madgeek, we've seen the same budget failure patterns repeat. The project starts with optimism, hits reality around month 2, and by month 4 the client is either approving change orders or considering whether to cut their losses. The cause is almost never "the development took longer than expected." The cause is that the estimate was wrong — and it was wrong for structural reasons, not estimation skill.

Why does buyer-defined scope cause budget overruns?

When a COO writes a requirements document without an engineer challenging it, the estimate reflects what was written, not what's needed. The gap shows up in month 2 when the development team starts building and discovers all the assumptions that weren't in the document.

Here's what a typical requirements gap looks like. The document says: "Users can upload invoices and the system matches them to purchase orders." The engineering reality: What file formats? PDF, Excel, CSV, images? What happens when the invoice format doesn't match the expected template? What if an invoice matches multiple POs? What if a PO has been partially fulfilled? What's the tolerance for amount mismatches — exact match only, or within 2%? What happens when the upload fails mid-file?

Each of those questions represents engineering work that wasn't in the estimate. Not because the developers were padding — because the requirements didn't contain enough detail for an accurate estimate. The document described the feature in business language. The implementation requires engineering language. The gap between the two is where budgets die.

The fix: the engineering team must co-write the specification. Not review it — co-write it. A paid discovery phase where engineers ask the hard questions and document the answers produces a specification that can be estimated accurately. It costs $5,000-$15,000 and saves $50,000-$200,000 in overruns.

Why do integration costs blow up custom software budgets?

The system itself costs $80K. Integrating it with your ERP, CRM, and accounting system costs another $40K. Most estimates don't include the second number — or include it as a line item of $5K-$10K that bears no relationship to reality.

Integration work is consistently the most underestimated component of custom software projects. There are three reasons. First: existing systems have undocumented behaviour. The API documentation says one thing; the actual API does something slightly different. Discovering and handling those differences takes time that wasn't scoped. Second: data formats don't match. Your CRM stores dates as MM/DD/YYYY. Your ERP stores them as YYYY-MM-DD. Your accounting system stores them as epoch timestamps. Mapping and converting between these is engineering work.

Third: error handling between systems is complex. What happens when the CRM is down and the new system needs customer data? What happens when a sync fails halfway through? What happens when data in two systems conflicts? Each of these scenarios requires specific engineering decisions and code.

The fix: scope integration work separately and explicitly. For every external system the new software touches, budget 15-25% of the core build cost. If the project integrates with 3 systems, integration work should be 45-75% of the core build cost. That sounds high. It's accurate.

How do engagement model incentives cause cost overruns?

Time-and-materials vendors make more money when projects take longer. Fixed-price vendors make more money when they cut corners. Neither incentive aligns with your outcome. This isn't a criticism of any vendor's integrity — it's a structural observation about how pricing models create behaviour.

On T&M: the vendor has no incentive to find a simpler solution. A feature that could be built in 3 days using an existing library gets built in 2 weeks from scratch. Not maliciously — the team just defaults to building because that's what they're paid to do. Over a 6-month project, these decisions add up to 30-50% budget inflation.

On fixed-price: the vendor has no incentive to handle edge cases. The contract says "user authentication" and the vendor implements the minimum viable version. When you discover during testing that it doesn't handle password resets, SSO integration, or session management the way you expected, that's a change order.

The model that works: phased fixed-price. The project is broken into phases of 4-6 weeks. Each phase has a fixed scope and fixed price. Scope changes happen BETWEEN phases, not mid-sprint. This gives the client cost predictability per phase while allowing the scope to evolve based on what's learned during the build.

What gets estimated versus what gets discovered?

There's a predictable set of items that appear in every custom software project but rarely appear in the initial estimate. Here are the 8 most common.

1. Data migration from the existing system — often 15-20% of the total build cost, rarely estimated upfront. 2. User roles and permissions beyond basic admin/user — enterprise clients always need 4-6 roles with different access levels. 3. Audit logging and compliance — not requested until legal or compliance reviews the project mid-build. 4. Notification system — "send an email when X happens" sounds simple until you're building templates, managing delivery, handling bounce-backs, and supporting multiple channels.

5. Reporting and dashboards — requested after the core system is built because stakeholders can't see what's happening without them. 6. Mobile responsiveness or a mobile app — mentioned casually during the project as "oh, the team will need to use this on their phones." 7. Performance under load — the system works with 10 users but crawls with 500, and nobody tested at scale until production. 8. Documentation and training — the system works but nobody knows how to use it without the developer explaining it.

Each of these items costs $5,000-$30,000 depending on complexity. A project with 4 of these undiscovered items is $20,000-$120,000 over budget before anyone made a mistake.

How do you structure an engagement that prevents budget overruns?

Three structural practices prevent the majority of custom software budget overruns. All three must be in place — any one alone isn't sufficient.

First: a paid discovery sprint before any build commitment. This is 1-2 weeks of engineering analysis that produces a technical specification, not a summary of your requirements. The engineering team maps data models, integration points, edge cases, and infrastructure needs. The output is specific enough to estimate accurately.

Second: phased delivery with scope locked per phase. Each phase is 4-6 weeks with a fixed deliverable and fixed price. Scope changes are collected during the phase and implemented in the next phase. This prevents mid-sprint scope creep while allowing the project to evolve.

Third: weekly scope reviews. Every week, the engineering team and the client review what was built, what was discovered, and what needs to change. Scope changes are documented, estimated, and scheduled into the next phase — not absorbed silently into the current sprint.

When does time-and-materials work, and when does fixed-price work?

Neither model is universally better. Each works in specific circumstances.

Time-and-materials works when: the scope genuinely can't be defined upfront (R&D, exploration, prototype), you trust the team's efficiency and can monitor velocity, the project is ongoing with no fixed end date, or you have an in-house technical lead who can evaluate whether the hours billed match the output delivered.

Fixed-price works when: the scope is well-defined after a thorough discovery phase, the deliverable is discrete (a specific system with specific features), you need budget certainty for internal approval, or the project has a clear end state.

Phased fixed-price works for most custom software projects because it provides budget certainty per phase while acknowledging that scope evolves during the build. Each phase is estimated based on the discovery findings and the previous phase's learnings.

What should a good software estimate actually include?

A complete estimate covers nine categories. If any of these are missing, the estimate is incomplete and the budget will overrun.

1. Core build — the primary features and business logic. 2. Integrations — every external system connection, estimated individually. 3. Data migration — moving data from existing systems with validation and cleanup. 4. Testing — unit tests, integration tests, UAT support, and performance testing. 5. Deployment — infrastructure setup, CI/CD pipeline, staging and production environments.

6. Documentation — technical documentation for the engineering team and user documentation for the client team. 7. Training — sessions with the end users to ensure adoption. 8. 90-day warranty — post-launch bug fixes included in the original price, not billed separately. 9. Contingency — 10-15% buffer for genuine unknowns, stated explicitly rather than hidden in inflated estimates.

If a vendor provides an estimate with only item 1 and calls it "the project cost," the actual cost will be 40-80% higher. That's not a budget overrun — it's an incomplete estimate that was mistaken for a complete one.

What does custom software actually cost in 2026?

Here are realistic cost ranges based on our project history and current market rates for senior engineering teams. These assume a team based in India with senior engineers — US-based teams run 2-3x higher.

Internal workflow system (approval chains, task management, department-specific tools): $40,000-$150,000. Custom CRM (replacing Salesforce or HubSpot with a system built for your actual sales process): $50,000-$150,000. Custom eCommerce platform (replacing Shopify Plus with complex B2B pricing, catalog logic, or multi-vendor marketplace): $80,000-$300,000.

AI feature (adding ML-powered functionality to an existing system — cost estimation, lead scoring, document processing): $60,000-$120,000. Enterprise multi-system platform (ERP, procurement, multiple integrated modules for a large organisation): $150,000-$400,000.

The wide ranges reflect scope differences, not pricing games. A $50K CRM is for a 15-person sales team with one pipeline. A $150K CRM is for a 200-person organisation with 6 pipelines, territory management, and integration with 4 other systems.

How does Madgeek prevent budget overruns?

Our engagement model is built specifically around preventing the three budget killers described above. Every project follows the same structure: discovery, then phased build.

Discovery phase (1-2 weeks, fixed price): engineers — not PMs — analyse the requirements, identify integration complexity, map edge cases, and produce a technical specification. The output includes a phased build plan with per-phase cost estimates. If the discovery reveals that the project isn't feasible at the client's budget, we say so. A $5,000-$15,000 discovery that prevents a $200K failed project is a good outcome for everyone.

Build phases (4-week sprints, fixed price per phase): scope is locked per phase. Weekly reviews surface any scope changes, which are estimated and scheduled into the next phase. Price changes happen between phases, never mid-sprint. The client approves each phase before it begins.

Every estimate includes all nine categories listed above — core build, integrations, data migration, testing, deployment, documentation, training, 90-day warranty, and stated contingency. No hidden costs. No "implementation details" that appear as change orders later.

The result over 50+ projects: our final project costs average within 10% of the post-discovery estimate. Not because we're better at guessing — because we do the hard scoping work before estimating, not after.