State of Custom Software TCO 2026: What Industry Data Tells Us About Build Cost, Maintenance and Scaling Cliffs

Skip key takeaways

Key takeaways 5

Updated July 31, 2026

• Build cost is a minority of TCO Initial build cost rarely exceeds 35% of total cost of ownership over a five-year horizon, making it a poor proxy for the full budget needed.
• Year-2 maintenance cliff hits fast Year-2 maintenance runs 15-25% of original build cost per year, with the cliff appearing when the original team rotates off at months 14-22.
• Mobile breakage tax compounds annually Native apps absorb 1-3 high-impact breakage events per platform per year, with annualized remediation averaging 6-12% of original build cost.
• Unarchitected cloud spend grows 2-3x Cloud spend on non-architected systems trends toward 2-3x the Well-Architected baseline by year three, driven by egress, idle compute and lock-in.
• Buy beats build for commodity workloads The 2026 inflection point favors buying SaaS for non-differentiating workloads as ISO/IEC 25010 quality bars become harder to hit in greenfield builds.

Copy takeaways

TL;DR

• Independent research on large-sample IT project delivery finds an average cost overrun of 27%, with one in six projects becoming a black swan that overruns cost by close to 200% and schedule by nearly 70% (Flyvbjerg and Budzier, Harvard Business Review, 2011).
• Year-2 maintenance typically lands at 15-25% of the original build budget per year, per Google SRE Book economics chapter and ThoughtWorks Technology Radar field reports.
• Native mobile apps absorb 1-3 platform breakage events per year per platform driven by published Apple and Google API change logs, with cumulative remediation cost crossing 10% of build budget by year three.
• Cloud spend on non-architected systems trends toward 2-3x the Well-Architected baseline by year three at scale, mostly through egress, idle compute and proprietary managed services lock-in.
• The build-versus-buy inflection point in 2026 has shifted toward buy for non-differentiating workloads as SaaS pricing matures and ISO/IEC 25010 quality attributes become harder to hit cost-effectively in greenfield custom builds.

Method

This analysis synthesizes published software economics data from tier-1 industry sources rather than proprietary engagement counts. Primary inputs include Flyvbjerg and Budzier's IT-project cost-overrun research, ISO/IEC 25010 quality model definitions, ThoughtWorks Technology Radar volumes 28 through 31, GitHub Octoverse annual reports, Stack Overflow Developer Survey waves through 2025, the Google SRE Book and SRE Workbook, OWASP Application Security Verification Standard release notes, AWS Well-Architected Framework guidance and Linux Foundation research publications. Secondary inputs include peer-reviewed software-engineering studies indexed in the ACM Digital Library and public post-incident reports from major cloud providers.

Where ranges are reported, they reflect cross-source corroboration rather than single-study claims. Where a number cannot be cross-verified across at least two tier-1 sources, it is omitted. Pharos contributes synthesis and advisory voice, anchored on 110+ custom software applications shipped since 2013 and 13+ years of cross-domain delivery experience under PhD-led research direction (Dr. Dmytro Nasyrov, Founder and CTO). Cost figures are framed as percentages of original build budget to normalize across geography, currency and project size. The article focuses on custom-built application software across SaaS, mobile, ERP-class internal tooling and two-sided marketplaces. Embedded firmware, scientific computing and games are out of scope. All ranges describe public mid-points across the cited sources and are not predictions for any specific engagement.

Initial Build Cost Reality 2024-2026

Initial build cost remains the most heavily quoted and least useful number in software procurement. Independent cost-overrun research confirms that the original budget figure is rarely the figure ultimately spent on delivery, and that variance widens with project scope, as Flyvbjerg and Budzier's 1,471-project study confirmed. For SaaS minimum viable products built to a defensible ISO/IEC 25010 functional suitability and security baseline, public benchmarks place 2024-2026 first-release effort in the 4 to 9 engineer-month range for narrow vertical scope, and 12 to 24 engineer-months once multi-tenant identity, billing and audit logging are in scope.

Mobile applications continue to bifurcate. Single-platform native builds at production grade cluster around 6 to 14 engineer-months per platform per the Stack Overflow Developer Survey 2024 and 2025 effort distributions. Cross-platform stacks reduce that by 25 to 40% on initial build but reintroduce cost downstream through platform-specific breakage as documented in ThoughtWorks Technology Radar volumes 29 and 30.

ERP-class internal tooling shows the highest variance, with cost overruns concentrated in integration scope rather than core feature scope. Marketplace builds carry an additional cost layer for trust, payments and dispute workflows that public OWASP ASVS Level 2 conformance work alone can absorb 15 to 20% of the engineering budget.

The headline finding across all four project types is that initial build cost rarely exceeds 35% of total cost of ownership over a five-year horizon. Treating the build figure as the budget is the single largest source of TCO surprise in the public dataset. Procurement processes that lock the build figure without reserving comparable envelopes for operations, evolution and platform churn systematically under-fund the systems they commission. Across our 110+ shipped applications since 2013 the single most reliable predictor of TCO surprise is whether the procurement envelope reserved budget for years 2-5 at the moment the build figure was approved.

The Year-2 Maintenance Cliff

Google's SRE Book economics chapter is explicit that operational cost dominates lifecycle cost for any system with non-trivial uptime expectations. Cross-referenced against ThoughtWorks Technology Radar engineering-effectiveness coverage and Linux Foundation maintainer-burden research, Year-2 maintenance commonly runs 15 to 25% of original build cost per year, with the upper bound concentrated in systems that skipped observability and test investment in Year 1.

The cliff is not gradual. It appears at the moment the original build team rotates off and tribal knowledge stops compounding. GitHub Octoverse contributor-churn data shows that median tenure on a given repository is shorter than the lifecycle of the systems being built on top of it. ISO/IEC 25010 maintainability sub-characteristics, particularly modularity, reusability and analyzability, predict whether the cliff is survivable on the original budget envelope or requires a re-platforming line item.

Two patterns separate well-maintained systems from cliff casualties. The first is documented architectural decision records, which the ThoughtWorks Technology Radar has tracked as Adopt for multiple volumes. The second is a sustained test investment that meets at least the OWASP ASVS verification level appropriate to the data classification handled by the system. Systems that ship without either tend to reach the cliff in months 14 to 22, at which point the maintenance line item competes directly with the next-year roadmap and one of them loses. In our 13+ years of cross-domain delivery the cliff arrives on schedule almost regardless of stack; what varies is whether the original team built the documentation and test surface that lets a successor team survive it without a re-platforming line item.

Mobile Platform Breakage Tax

Mobile is the only application category where the platform vendor publishes a forward calendar of breaking changes. Apple and Google both ship annual major OS releases with deprecation windows and SDK requirements that the App Store and Play Store enforce through submission gates. Public change logs across the iOS 17 to iOS 18 and Android 14 to Android 15 cycles document 1 to 3 high-impact breakage events per native app per platform per year, with security and privacy APIs leading the list.

The remediation cost is non-linear. A single Keychain or Photos privacy change can trigger a re-architecture of an entire data layer if the original build did not respect the principle of least privilege. By contrast, target-SDK bumps that touch only manifest declarations carry near-zero remediation effort. The annualized average across the public dataset is 6 to 12% of original build cost per platform per year, with cumulative remediation crossing the 10% mark by year three for any app that has not been actively maintained.

Cross-platform stacks shift the breakage surface rather than removing it. Framework-level releases for React Native, Flutter and similar tools introduce their own breaking changes on top of the underlying platform churn. ThoughtWorks Technology Radar volumes 29 through 31 track this explicitly under platform and tools blips. The net effect is that cross-platform savings on initial build are typically recovered by platform vendors and framework maintainers over the first three years of operation. We observe this pattern repeatedly across the mobile cohort within our 110+ shipped applications: the cross-platform decision is reasonable, but the year-3 budget needs to reflect framework churn as a recurring line item, not a one-off.

Cloud TCO Patterns and Vendor Lock-in

The AWS Well-Architected Framework, Azure Well-Architected guidance and Google Cloud Architecture Framework converge on the same five-pillar model and the same warnings. Public post-mortems and case studies show that cloud spend on non-architected systems trends toward 2 to 3x the Well-Architected baseline by year three at scale. The dominant cost drivers are inter-AZ and egress traffic, idle compute on over-provisioned managed services and storage tiering misses on growing log and event streams.

Vendor lock-in is the second-order TCO question. The 12-Factor App methodology, originally published by Heroku contributors, remains the most widely cited public reference for portability discipline. Systems that respect 12-Factor process, config, backing-services and disposability rules can typically be migrated across providers in weeks rather than quarters. Systems built around proprietary serverless event buses, vendor-specific identity primitives or managed-database stored procedures cannot.

The lock-in cost is rarely paid as a migration. It is paid as a negotiation discount lost at contract renewal. Public Stack Overflow Developer Survey responses and Linux Foundation research both indicate that organizations with credible migration paths secure materially better commercial terms than those without, even when no migration ever occurs. The TCO impact of credible portability is therefore best modeled as a recurring discount rather than a one-time engineering investment. In our advisory work we have seen 12-Factor-disciplined codebases produce materially better renewal terms even when the migration path was never exercised; the credibility of the option is what gets priced, not the option itself.

Test Coverage and Defect Escape Economics

The cost of a defect rises by roughly an order of magnitude at each stage of escape, from local development to code review to staging to production to a security incident. The Google SRE Workbook quantifies this through error budget mathematics, and the OWASP ASVS framework operationalizes it through verification levels keyed to data sensitivity and threat model.

Public ACM Digital Library research on defect economics, summarized in multiple software-engineering textbooks, places the cost ratio for a production defect at 30 to 100x the cost of catching the same defect in development. For security defects that reach incident status, the ratio extends further once breach disclosure, regulatory and remediation costs are included.

The TCO implication is that test investment is not a quality cost, it is a defect-escape insurance premium. ThoughtWorks Technology Radar consistently places contract testing, mutation testing and security-as-code adjacent practices in Adopt or Trial. The published industry pattern is that systems with sustained test investment trend toward lower TCO over a five-year horizon than systems that traded test coverage for short-term feature velocity, even when initial build cost was higher. Typically, the cost crossover occurs between months 9 and 18 depending on change frequency and incident exposure.

The Build-versus-Buy Inflection Point in 2026

The 2026 inflection point has moved. SaaS pricing has matured for identity, observability, billing, search, content management, analytics and customer support, with multiple tier-1 providers in each category and credible open-source alternatives behind them. ISO/IEC 25010 quality attributes, particularly security, performance efficiency and reliability, have become harder to hit cost-effectively in greenfield custom builds because the bar set by mature SaaS keeps rising.

The defensible build cases narrow each year. They cluster around regulated data residency, deeply differentiated workflow logic, latency floors that managed services cannot meet and competitive moats that depend on owning the data plane end to end. Outside those cases, public TCO data favors buy or assemble over build.

The most expensive 2026 mistake remains the inverse, building custom commodity infrastructure under the assumption that internal teams will deliver cheaper than the SaaS market. The cost-overrun research cited above and Google SRE Book operational-cost framing make the math difficult to win without a real differentiation thesis. The defensible posture is to buy commodity, build differentiation and budget the integration layer as a first-class engineering investment rather than as glue. Across our 110+ shipped applications since 2013 the integration layer is consistently where teams under-budget by the largest margin and where rework concentrates in years 2 and 3.

Cost-vs-Differentiation Decision Matrix

Public industry data supports a four-tier matrix keyed to organization maturity and the differentiation value of the workload. Tier 1 covers early-stage organizations without dedicated platform engineering capacity. The dominant pattern in the dataset is buy SaaS, glue with low-code and reserve any custom build budget for the single workload that defines the product thesis. Getting that single workload right starts with disciplined digital product management that ranks it correctly against the rest of the roadmap.

Tier 2 covers growth-stage organizations with a small platform team. Public ThoughtWorks Technology Radar guidance favors a thin internal developer platform on top of bought components, with custom build limited to differentiating product surfaces. Tier 3 covers scale-up organizations with dedicated SRE and security functions. The matrix tilts toward selective insourcing of components where SaaS economics break down at volume, typically observability, identity at high cardinality and data warehousing at petabyte scale.

Tier 4 covers regulated enterprises and platform companies whose product is the platform. The matrix here favors deeper custom investment but bounded by ISO/IEC 25010 maintainability and OWASP ASVS conformance discipline, with explicit re-platforming budget on a three to five year cadence rather than open-ended maintenance lines. Across all four tiers, the common failure mode is treating the differentiation question as static, when in practice the boundary between commodity and differentiation moves every twelve to eighteen months as the SaaS market evolves.

Methodology Caveats and Limitations

Three caveats apply to every figure in this article. First, public datasets skew toward English-language reporting and toward organizations willing to disclose project outcomes. Stack Overflow Developer Survey and GitHub Octoverse both carry self-selection bias that under-represents non-Western and non-public-tech cohorts. Second, currency, geography and labor-market variance is large enough that absolute cost figures are not portable across regions, which is why this analysis works in percentages of build budget rather than absolute amounts.

Third, the Year-2 maintenance, mobile breakage and cloud TCO ranges reflect public mid-points and exclude tail outcomes. Catastrophic failures, full re-platforming events and zero-incident exemplars all exist in the dataset and would push the bands wider in either direction. Readers using these figures for budgeting should add a contingency layer matched to their own risk profile and regulatory exposure.

For the underlying primary sources, see Flyvbjerg and Budzier's Why Your IT Project May Be Riskier Than You Think at hbr.org, ISO/IEC 25010 at iso25000.com, the 12-Factor App methodology at 12factor.net, OWASP ASVS at owasp.org, the Google SRE Book at sre.google, the ThoughtWorks Technology Radar at thoughtworks.com/radar, the Stack Overflow Developer Survey at survey.stackoverflow.co, GitHub Octoverse at octoverse.github.com, Linux Foundation research at linuxfoundation.org/research, the ACM Digital Library at dl.acm.org and the AWS Well-Architected Framework at aws.amazon.com/architecture/well-architected. This article is a synthesis. The primary sources remain the authoritative references.

FAQ

Last updated: July 31, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 7

• ★ Featured question. What percentage of 5-year TCO does the initial build represent?

  Copy link Copies a direct link to this answer to your clipboard.

  The initial build rarely exceeds 35% of the 5-year total cost of ownership for custom software. The remaining 65%+ goes to maintenance, infrastructure, security patches, feature evolution and team continuity. Teams that budget only for build cost routinely run out of capital before the product reaches maturity, forcing rushed re-architecture or vendor lock-in.

• ★ Featured question. When does maintenance cost spike after launch?

  Copy link Copies a direct link to this answer to your clipboard.

  Year-2 maintenance typically runs 15-25% of the original build cost annually, but a cost cliff hits between months 14 and 22 when the founding team rotates off. Institutional knowledge walks out with them, driving incident resolution times up and documentation-debt remediation costs higher.

  Knowledge transfer, runbooks and architecture decision records before that window significantly flatten the curve.

• How much does native mobile maintenance cost per year?

  Copy link Copies a direct link to this answer to your clipboard.

  Native mobile apps experience 1-3 platform-breaking events per platform per year - iOS and Android OS releases, API deprecations, hardware capability changes. Annualized, this costs 6-12% of the original build cost just to stay current, before any new features.

  Cross-platform frameworks like React Native or Flutter reduce this but introduce their own upgrade cadence.

• Why does cloud spend grow so fast without architectural controls?

  Copy link Copies a direct link to this answer to your clipboard.

  Unarchitected cloud environments trend to 2-3x the AWS/GCP Well-Architected baseline by year 3 because teams optimize for delivery speed, not resource efficiency. Auto-scaling groups over-provision, unused environments persist, data transfer costs compound and reserved-instance planning is deferred.

  A quarterly FinOps review and tagging policy prevents most of this drift.

• When should a company buy software instead of building it?

  Copy link Copies a direct link to this answer to your clipboard.

  Buy beats build for commodity and non-differentiating workloads - CRM, HR, accounting, standard authentication - where off-the-shelf tools score comparably on ISO/IEC 25010 quality dimensions and the integration cost is lower than the build cost. Build only when the capability is a genuine competitive differentiator or when data-sovereignty requirements rule out third-party SaaS.

• How can teams avoid the year-2 maintenance cost cliff?

  Copy link Copies a direct link to this answer to your clipboard.

  Three practices reduce cliff risk: (1) mandate architecture decision records so context survives personnel changes; (2) run a structured knowledge-transfer sprint 3 months before any key team rotation; (3) keep a maintained test suite covering critical paths so incoming engineers can refactor safely. These steps cost roughly 5-8% of build budget upfront but cut post-rotation incident costs by 30-50%.

• What is the most underestimated TCO driver in custom software projects?

  Copy link Copies a direct link to this answer to your clipboard.

  Cloud spend drift is consistently the most underestimated TCO driver. Teams model infrastructure at initial load assumptions and never revisit. By year 3, egress fees, idle compute, storage sprawl and multi-region redundancy copy costs combine to push actual spend 2-3x above early projections. Budget reviews tied to quarterly architecture assessments are the only reliable control.

Skip glossary

Software TCO glossary 5

Updated July 31, 2026

TCO (Total Cost of Ownership)

The full lifecycle cost of a software system including initial build, ongoing maintenance, platform churn and cloud operations over a multi-year horizon.

ISO/IEC 25010

An international quality model defining software product characteristics such as maintainability, security, reliability and performance efficiency.

OWASP ASVS

The OWASP Application Security Verification Standard, a framework of security requirements keyed to data sensitivity and threat model levels.

12-Factor App

A methodology for building portable, cloud-native applications across process, config, backing-services and disposability rules to reduce vendor lock-in.

Well-Architected Framework

A multi-cloud set of guidance pillars from AWS, Azure and Google used to benchmark cloud spend efficiency and avoid over-provisioning at scale.

Copy terms

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.