Table of content
- The Promise Every Vendor Makes
- The Mechanism Behind the Lie: Underscoped Discovery
- What the Numbers Actually Say About Custom Software Projects
- The Myths Vendors Use to Keep You From Asking Hard Questions
- Vendor Lock-In: The Trap Nobody Puts in the Brochure
- What to Demand Before You Sign Anything
- Is Custom Software Still Worth It? An Honest Answer
- Frequently Asked Questions
- How to Choose a Partner Who Won’t Lie to You
The biggest lie in custom software development isn’t a single outright falsehood. It’s a structural deception. Vendors promise one thing at the proposal stage. What actually gets delivered, billed, and maintained tells a different story. Custom software development myths compound over years, eating budgets and board patience alike. This post doesn’t soften that reality. It names the mechanisms, gives you the numbers, and tells you precisely what to do about it.
The Promise Every Vendor Makes
The promise is consistent: fixed scope, fixed price, delivered on time. Every reputable vendor makes it. Almost no large project fulfils it without modification, renegotiation, or the quiet addition of a Phase 2 that absorbs what Phase 1 couldn’t contain. Understanding why that promise exists and why it breaks is the first step to protecting your investment.
Fixed Scope, Fixed Price, On Time: The Three-Part Promise
The three-part promise is a sales architecture, not an engineering commitment. Vendors who win on price and certainty are, structurally, vendors who underestimate. They underestimate the discovery they haven’t run, the integrations they haven’t mapped, and the decisions you haven’t made yet. The promise clears procurement. It doesn’t reflect reality.
Consider what it takes to actually fix scope on a system touching your CRM, your finance tools, and your customer-facing portal. Every dependency must be known, every edge case documented, every third-party API rate-limited and tested. That work can’t happen in a two-week proposal sprint. Fixed-scope proposals written without that depth aren’t firm commitments. They’re optimistic guesses dressed in contract language.
The best vendors tell you upfront that fixed price and fixed scope require a paid discovery phase first. Everything else is a red flag.
Why the Proposal Stage Is Where the Lie Is Told
The proposal stage is competitive. Vendors know others are quoting, and the incentive pushes them to come in credibly low rather than honestly high. Software development false promises don’t originate from malice in most cases. They originate from incentive misalignment. The team that wins the work is rarely the team that builds it. The business development lead who signed your NDA has limited visibility into what delivery actually costs.
Ask any senior developer at a mid-size agency what they think of the scopes their sales colleagues write. The answer will be uncomfortable. That discomfort is systemic, not exceptional. Proposals exist to win contracts. Contracts exist to define risk. Those two purposes are in tension from the first page.
The “Phase 2” Promise: and Why It Almost Never Gets Built
Phase 2 is where the lie finds its exit. When scope gets cut in delivery and it almost always does the features that don’t survive get parked in a Phase 2 roadmap. This polite fiction keeps the relationship intact while the vendor ships something smaller than you bought.
The reality: fewer than 30% of Phase 2 promises result in a funded, delivered project within 18 months of Phase 1 completion. This pattern appears consistently across delivery retrospectives in the UK software sector. The gap isn’t laziness. It’s budget fatigue. By the time Phase 1 ships late and over-budget, your appetite for another round is gone. Phase 2 is where features go to be forgotten. Don’t let your core requirements live there.
The Mechanism Behind the Lie: Underscoped Discovery
The mechanism behind most failed custom software projects isn’t bad code. It’s underscoped discovery. When a vendor rushes or skips the requirements gathering phase, every estimate downstream builds on assumptions rather than facts. The gap between assumption and reality is where cost overruns live, where timelines slip, and where the promise of Phase 1 quietly becomes the burden of Phase 2.
What Proper Requirements Gathering Actually Looks Like
Proper requirements gathering is an investment, not a formality. It involves structured stakeholder interviews across every team that will touch the system: operations, finance, customer service, compliance, and IT. It maps every data source, every integration point, and every user journey before a line of architecture gets drawn. It surfaces conflicting requirements between departments and resolves them in writing.
The output is a functional specification that a developer who wasn’t in the room can build from without guessing. That process typically takes two to six weeks, depending on system complexity. It carries a real cost. Any vendor who compresses it into a half-day workshop and calls it discovery hasn’t done discovery they’ve done theatre. Discovery is the foundation. What you build on it either stands or cracks.
How Underscoping Leads to Cost Overruns and Scope Creep
Scope creep isn’t an accident. It’s the inevitable result of requirements that nobody defined in the first place. When a developer hits a decision point the spec didn’t cover, they make an assumption. That assumption gets built. Two months later, you see it in a demo and say “That’s not what we meant,” and the cycle of change requests begins.
Each change request carries a cost: not just the direct development time, but the regression testing, the documentation update, and the sprint replanning. A mid-market logistics company that skipped a proper discovery phase on their warehouse management system found that change requests in months three through seven added 68% to the original contract value. Nobody had mapped the edge cases in their returns workflow before writing a single line of code. The vendor wasn’t dishonest. The process was just incomplete.
Undefined requirements don’t disappear. They reappear as invoices.
Red Flags in a Vendor’s Discovery Process
Watch for these specific signals. A proposal delivered within 72 hours of your first meeting deserves scrutiny. So does a fixed-price quote with no paid discovery stage preceding it. A requirements document that fits on two pages for a system with more than four integrations is a warning sign. A project manager who can’t name the specific workshops or artefacts their discovery process produces is another.
Ask directly: “What does your discovery phase produce, and who signs off on it before development begins?” A vague answer means a vague scope. Evaluate the discovery process as carefully as you evaluate the portfolio. It’s the better predictor of delivery quality.
What the Numbers Actually Say About Custom Software Projects
The data on custom software delivery is not encouraging. Understanding it protects you from decisions based on the vendor’s best-case narrative rather than the industry’s actual track record. These statistics aren’t outliers they describe the mean. Your project isn’t immune unless you actively engineer it to be.
31% of Projects Are Cancelled: What Drives That Statistic
The Standish Group’s CHAOS Report has tracked software project outcomes for decades. Roughly 31% of IT projects are cancelled before completion, and that figure has remained stubbornly consistent. The drivers aren’t primarily technical. Incomplete requirements account for the largest share of failures, followed by lack of user involvement and unrealistic expectations.
Not technology failure. Not developer incompetence. Requirements gaps and misaligned expectations the exact outputs of underscoped discovery drive most cancellations. A cancelled project doesn’t just waste the contract value. It wastes the internal time your team spent on requirements workshops, UAT preparation, and change management planning. The true cost of a cancelled project typically runs two to three times the contract value when indirect costs are included.
31% isn’t a fringe outcome. It’s a base rate. Plan accordingly.
Budget Overruns: Why the Average Project Costs Far More Than Quoted
McKinsey research on large IT projects found that 45% run over budget, with the average overrun sitting at 45% above the original estimate. For custom software specifically, the pattern holds: projects with inadequate discovery phases overrun more severely than those with thorough upfront investment.
The mechanism is direct. A discovery gap of two weeks at the start translates to a scope gap of two months at the delivery end. That scope gap doesn’t disappear it becomes change requests, sprint extensions, or deferred features.
Picture a fintech startup that budgeted £180,000 for a client onboarding platform. By go-live, the actual spend reached £267,000. The overrun came almost entirely from integrations the original scope never mapped: a KYC provider API requiring custom middleware, a CRM sync needing bespoke transformation logic, and a document storage layer the vendor assumed a third-party SaaS would handle. None of these were surprises to anyone willing to ask the right questions upfront.
Timeline Reality: The 13-Month Average vs. What You Were Told
The average custom software project of moderate complexity takes 13 months from kick-off to production deployment. The average quoted timeline at proposal stage: six to eight months. The gap isn’t fabrication. It’s optimism compounding across every phase.
Vendors quote for a world where requirements are stable, stakeholders are available, third-party APIs work as documented, and no team member turns over. That world doesn’t exist. Requirements change because businesses change. Stakeholders get pulled into other priorities. APIs deprecate. Developers leave. Each event adds weeks.
Build in contingency from the start. Add 40% to any quoted timeline and treat the original date as a best-case rather than a plan. That isn’t pessimism. That’s project literacy.
The Myths Vendors Use to Keep You From Asking Hard Questions
The biggest myths about custom software development share a common function: they stop you from doing the due diligence that would reveal inconvenient truths about a vendor’s capability, process, or incentives. Custom software development misconceptions aren’t always deliberate misdirection. Some vendors genuinely believe them. But they serve the same purpose they create a frame in which asking hard questions seems either naive or obstructive. Recognise them. Push through them.
“Custom Software Is Too Expensive”: The Real Cost Comparison
The “too expensive” objection cuts both ways. Vendors use it to qualify out prospects. Buyers use it to dismiss custom builds before they’ve run the comparison properly. The real cost comparison isn’t custom versus free SaaS. It’s the total cost of ownership across five years: licencing fees scaling with your user count, integration costs for tools that don’t natively connect, workaround labour when the SaaS doesn’t fit your workflow, and the opportunity cost of capability gaps.
A professional services firm running three SaaS tools that didn’t integrate was spending an estimated 14 hours per week on manual data reconciliation. At a fully loaded cost of £65 per hour, that’s over £47,000 per year in lost productivity. A custom integration layer cost £34,000 to build and paid back in under nine months. The maths on “too expensive” depends entirely on what you’re comparing it to.
Not expensive. Often cheaper. Do the five-year model.
“Off-the-Shelf Won’t Scale With You”: When This Is True and When It Isn’t
This vendor myth has aged least well. The claim that off-the-shelf software can’t scale was credible in 2012. It’s far less credible now, and UK businesses need to interrogate it rather than accept it. The AI vs traditional software for UK businesses debate has shifted decisively. AI-powered SaaS platforms have closed the customisation gap. Tools like Salesforce, HubSpot, and sector-specific vertical SaaS products now offer configuration depth that would have required custom builds five years ago.
The honest answer: off-the-shelf won’t scale with you when your workflow is genuinely differentiated from your sector peers. It won’t work when regulatory requirements demand data sovereignty that SaaS can’t provide, or when you’re processing volumes that break SaaS pricing models. But off-the-shelf scales perfectly well when your process is standard and your “unique” requirements are actually just unfamiliarity with the platform’s configuration options.
Custom vs off-the-shelf software myths persist because both vendors and buyers have incentives to oversimplify. Vendors want to build. Buyers want certainty. The right answer is messier than either side admits.
“You Need Us for Ongoing Maintenance”: Separating Dependency from Value
Ongoing maintenance contracts are legitimate. Software requires upkeep, security patches, and feature evolution. The myth is the implied dependency the suggestion that only the original vendor can maintain what they built, and that switching would be prohibitively expensive or risky.
That dependency is sometimes real. When it is, it’s almost always because the vendor structured the codebase, the documentation, and the deployment architecture to make it real. Not accidentally. Not because the technology required it. Proprietary frameworks rather than industry standards, sparse documentation, undocumented environment variables, custom deployment scripts with no runbooks these are the hallmarks of a codebase designed to be sticky rather than maintainable.
The fix: insist on documented, standards-based code from day one, and commission an independent code review at the midpoint of any large engagement. Dependency gets engineered in. Insist it isn’t.
“Only Large Enterprises Need Custom Builds”: Why This Gatekeeps SMEs
This myth does particular damage to SMEs and growth-stage companies. It positions custom software as an enterprise luxury rather than a strategic tool accessible at multiple scales. The reality is that SMEs often have more to gain from bespoke software than large enterprises, because they can’t afford the inefficiency that bloated SaaS stacks and manual workarounds create at scale.
A 40-person company with a custom-built quoting and contract management tool one that integrates directly with their accounting software isn’t overengineering. They’re removing the friction that slows their sales cycle and caps their growth. MVP-scoped custom builds, designed to address one high-value workflow rather than replace an entire tech stack, are well within reach for businesses investing £30,000 to £80,000. The gatekeeping myth serves vendors who don’t want smaller contracts. It doesn’t serve buyers.
Vendor Lock-In: The Trap Nobody Puts in the Brochure
Vendor lock-in is the post-contractual risk that proposals don’t mention and brochures don’t address. It’s the mechanism by which a vendor relationship that started as a partnership becomes a dependency. You reach the point where leaving costs more than staying, regardless of whether the vendor performs. Understanding lock-in before you sign is the only time you have leverage to prevent it.
Who Owns the Code When the Contract Ends?
IP ownership is non-negotiable. You must own the code, full stop. This sounds obvious. Contracts don’t always make it clear. Some vendor agreements assign IP to the vendor and license it back to you a structure that sounds reasonable until you want to switch providers, bring development in-house, or use the codebase as collateral for investment.
Others assign IP to the client but include carve-outs for “frameworks,” “libraries,” or “tools” the vendor developed language broad enough to cover core architecture. Insist on a contract clause that assigns full IP ownership to you, clearly defines any genuinely third-party licensed components, and explicitly excludes any vendor claim on bespoke work product. Have a lawyer review it. Not an IT lawyer a commercial IP lawyer who has read software development contracts before.
You paid for it. Own it completely.
What Happens If Your Vendor Disappears or Pivots?
Vendors close, get acquired, pivot to different markets, or lose the key people who built your system. This isn’t a remote scenario. The UK software agency market has seen significant consolidation and attrition, particularly in the post-2022 economic environment.
Ask the vendor: “What happens to our codebase and documentation if your company ceases trading?” The answer should be a contractual escrow arrangement. Source code, documentation, environment configurations, and deployment runbooks should sit with a third party and release to you automatically on defined trigger events. If the vendor hasn’t faced this question before, that’s a data point about their typical client’s sophistication. If they resist the escrow clause, that’s a different kind of data point entirely.
Documentation Standards That Protect You
Documentation is the infrastructure of maintainability. Without it, every developer who touches the codebase after the original team works blind. At minimum, you should demand: inline code comments on all non-obvious logic; an architecture decision record documenting why key technical choices were made; a deployment runbook enabling a competent developer unfamiliar with the system to deploy a new version; and an API reference for any endpoints your system exposes or consumes.
Enforce this contractually, with documentation completeness as a condition of final payment sign-off. Vendors who deliver documentation as a post-project afterthought deliver documentation that is incomplete, outdated, and worthless. Maintain it throughout the build don’t create it retrospectively at the end.
What to Demand Before You Sign Anything
The biggest mistakes companies make with custom software happen before the first line of code gets written. They happen in the contract negotiation, the vendor evaluation, and the scoping conversations that precede both. For readers who want a structured vetting framework, the UK tech partner selection guide covers the evaluation criteria, due diligence questions, and contract red flags that procurement teams frequently miss. This section gives you the non-negotiables.
Three Contract Clauses Every Buyer Should Insist On
First: IP assignment, as described above. Full ownership of all bespoke work product, with clearly scoped exclusions for genuinely third-party components.
Second: a change control clause that defines the process for scope changes with explicit cost and timeline impact assessment before any change gets approved and actioned. Verbal scope agreements kill projects. Every change must go through a written change request with a sign-off trail.
Third: a milestone-based payment structure tied to defined deliverables rather than calendar dates. Paying in advance removes your leverage. Tying payment to working, tested software at defined milestones keeps the vendor’s incentives aligned with your outcomes. These three clauses won’t guarantee success — but their absence almost guarantees the conditions for the most common failure modes.
Negotiate these in. Not optional.
How to Evaluate a Vendor’s Discovery Process Before Committing
Ask the vendor to walk you through exactly what their discovery phase produces. Not what it costs, not how long it takes what artefacts you’ll hold at the end of it. The answer should include: a functional requirements specification, a system architecture diagram, an integration map, a user story backlog, and a risk register.
Ask who facilitates the discovery workshops and whether that person also leads the delivery team. Continuity between discovery and delivery is a quality signal. Ask for an example discovery deliverable from a previous project, with sensitive information redacted. A vendor who can’t or won’t provide one either doesn’t produce artefacts of sufficient quality to share, or doesn’t produce them at all. Either answer tells you what you need to know.
Questions That Reveal Whether a Vendor Is Being Honest About Scope
Ask: “What would cause this project to cost more than you’ve quoted?” An honest vendor gives a specific, detailed answer: undefined integrations, stakeholder availability, third-party API instability, regulatory changes mid-build. An evasive vendor says “nothing” or offers generic reassurances about change requests.
Ask: “What’s the most common reason your projects run over timeline, and how do you mitigate it?” Then ask: “What percentage of your projects deliver within 10% of the original budget estimate?” A vendor who can’t answer that last question with data doesn’t track it. Vendors who don’t track delivery accuracy can’t improve it.
You’re not asking these questions to be difficult. You’re asking because the answers predict your experience more accurately than any portfolio case study. A vendor who can’t explain why their last three projects slipped can’t explain why yours won’t.
If you want to compare options side-by-side before committing to a discovery engagement, Foundry 5 offers a no-obligation scoping call that covers your build requirements, the realistic cost range, and the questions you should be asking every other vendor you’re speaking to. It takes 30 minutes, requires no preparation on your part, and costs nothing. Book your scoping call here.
Is Custom Software Still Worth It? An Honest Answer
Is custom software development worth the cost? The honest answer: yes, in the right circumstances, and no in others. The truth about custom software development is that it’s a high-leverage investment when the conditions are right — genuine workflow differentiation, volume that breaks SaaS economics, regulatory requirements off-the-shelf can’t meet, or a core capability that is itself a competitive asset. When none of those conditions apply, it’s a poor investment. The question isn’t “custom or off-the-shelf?” It’s whether your specific situation meets the bar that justifies the cost, complexity, and risk of a bespoke build.
When Custom Development Genuinely Delivers ROI
Custom development delivers strong ROI when it removes friction from a high-frequency, high-value workflow that your current tools handle poorly. A recruitment platform that built a bespoke matching engine rather than relying on a generic ATS reported a 34% reduction in time-to-placement within six months of go-live. At their billing volume, that translated to roughly £220,000 in additional annual revenue from the same headcount. The build cost £95,000. The payback period was under six months.
ROI of that quality is achievable but it depends heavily on choosing a partner with the right technical depth and domain understanding. Not all development studios deliver equally. Outcomes in bespoke software depend significantly on partner quality. Among custom software and AI development companies in London, the difference between a studio with genuine discovery rigour and one without it can be the difference between a system that transforms your operations and one that costs twice what was quoted.
The right partner multiplies the investment. The wrong one destroys it.
When Build vs. Buy Should Favour Off-the-Shelf
Buy rather than build when: your workflow is standard for your sector; when a SaaS product covers 80% or more of your requirements and the remaining 20% can handle workaround or configuration rather than code; when your team lacks the internal capacity to manage a vendor relationship through a multi-month build; or when speed to market matters more than optimisation.
Build rather than buy when: your process is genuinely differentiated; when the SaaS alternative forces you to restructure your workflow around the tool’s limitations rather than the other way around; when data sovereignty or compliance requirements make cloud SaaS untenable; or when the custom system is itself a product you intend to commercialise.
These criteria aren’t exhaustive, but they provide a decision frame more useful than the generic “build vs. buy” advice most vendors give advice that tends to correlate strongly with which option they profit from.
How to Scope an MVP That Doesn’t Become an Abandoned Phase 1
The MVP trap catches many teams. You scope an MVP to ship quickly, then find it’s too limited to be useful, too expensive to extend, or built on an architecture that doesn’t support the features that would make it valuable. The fix is to scope your MVP around a single, complete user journey rather than a collection of partial features.
Complete means a user can begin, execute, and finish the journey without workaround. Partial means you’ve built the intake form but not the processing logic, or the dashboard but not the data pipeline feeding it. A complete single journey, delivered well, generates the evidence and momentum that funds Phase 2. A collection of partial features generates user frustration and board scepticism. Scope ruthlessly. Ship one thing completely. Build from there.
Frequently Asked Questions
What is the biggest lie in custom software development?
The biggest lie in custom software development is the fixed-scope, fixed-price, on-time promise delivered without a thorough discovery phase to support it. Custom software development myths cluster around this central deception: that a vendor can commit to cost and timeline before fully understanding the requirements. The mechanism is consistent. Vendors underscope discovery to win competitive proposals, then recover costs through change requests, scope reductions, or Phase 2 promises. The lie isn’t always intentional. But incentive structures make it almost inevitable, and recognising it is the prerequisite to protecting your investment.
Why do so many custom software projects fail to meet expectations?
Three root causes account for the majority of disappointing outcomes. First: teams define requirements inadequately at the outset, creating a gap between what was imagined and what gets built. Second: stakeholder engagement drops off after the proposal stage, meaning critical decisions fall to developers rather than to people who understand the business need. Third: vendors don’t flag scope and timeline risk early enough either because their tracking isn’t sophisticated enough to see it coming, or because the commercial incentive rewards staying optimistic until the problem can’t be hidden. All three root causes are preventable with the right vendor selection and contract structure.
How long does custom software development really take?
The honest benchmark for a moderately complex system: eight to fourteen months from kick-off to production deployment. Vendors typically quote six to eight months for the same scope. The gap is structural rather than dishonest. It reflects optimistic assumptions about requirement stability, stakeholder availability, and integration complexity. Add 40% to any vendor-quoted timeline as your planning baseline. For an MVP scoped to a single user journey, four to six months is achievable with a disciplined team and a well-run discovery phase. For a multi-integration, multi-role platform, twelve months is a realistic target not a ceiling.
What is the truth about custom software development costs?
The truth is that the initial quote is a floor, not a ceiling, for projects with inadequate discovery. McKinsey research indicates 45% of IT projects run over budget by an average of 45%. For custom software specifically, budget overruns are almost always traceable to requirements nobody defined before work began: integrations not mapped, edge cases not considered, and decisions not made until a developer hit them in build. A well-scoped project with a paid discovery phase producing a complete functional specification before development starts delivers far more predictable costs. Not because the technology is simpler, but because the unknowns surface before they become expensive surprises.
How do I know if a software vendor is being honest about scope?
Ask three questions and listen to how specific the answers are. First: “What would cause this project to cost more than quoted?” An honest vendor names specific risk categories: undefined integrations, stakeholder availability, API instability. An evasive vendor offers generic reassurances. Second: “What percentage of your projects deliver within 10% of the original budget estimate?” No data means no tracking. Third: “Walk me through exactly what your discovery phase produces.” The answer should name specific artefacts: a functional specification, an integration map, a risk register, a user story backlog. Vague answers to specific questions are the most reliable signal available that a vendor’s scope confidence isn’t grounded in evidence.
How to Choose a Partner Who Won’t Lie to You
Choosing a partner who won’t lie to you isn’t about finding someone with perfect integrity in a sea of bad actors. It’s about finding a vendor whose process, incentive structure, and track record align with honest delivery rather than optimistic selling. Those are different things, and the difference shows up in specific, observable behaviours not in values statements or proposal language.
The partner you’re looking for insists on a paid discovery phase before any fixed-price commitment. They produce documented artefacts from that discovery rather than verbal summaries. They assign full IP ownership to you from the first contract draft. They track delivery accuracy and share the data. They flag scope risk early, in writing, rather than managing it quietly until it becomes a crisis. They use standard frameworks and document their architecture decisions. They want you to own the code, understand the system, and have the freedom to take it elsewhere because a partner who builds that way earns retention through quality, not through dependency.
Foundry 5 builds software and AI products for founders and enterprise teams from its base in London. Every engagement starts with a rigorous discovery phase that produces a functional specification and architecture blueprint before a development sprint begins. If you’re evaluating a custom build, an AI integration, or a platform rebuild, the clearest next step is a direct conversation. It takes 30 minutes, covers your specific requirements, and gives you a realistic picture of what a well-run build looks like. Start the conversation with Foundry 5 here.
The lie is structural. The solution is structural too. Choose accordingly.
