The Real Cost of Building Custom Software

By year three of active use, cumulative maintenance spend on a piece of custom software typically exceeds the cost of the original build — a fact that rarely appears in the initial project quote a CFO signs off on. Industry benchmarks put annual maintenance at 15 to 25 percent of the original development cost, and legacy or poorly architected systems push that figure to 30 to 40 percent, meaning the sticker price on a custom software proposal is reliably somewhere between a third and a half of what the platform will actually cost across its useful life. For a CFO evaluating a build decision, understanding this full cost curve — not just the initial invoice — is the difference between an accurate multi-year budget and a recurring line-item surprise. Teams running the build-versus-buy half of that decision can see how the same curve applies in our Custom Software vs SaaS comparison.

This article breaks the real cost of custom software into two parts a CFO needs to model separately: how the build cost itself should be classified between CapEx and OpEx for financial reporting purposes, and what the recurring post-launch costs — hosting, security patching, and technical debt — actually run once the software is live.

How Should Custom Software Development Costs Be Classified: CapEx or OpEx?

Under ASC 350-40, internal-use software development costs can be capitalized once management has authorized and committed funding to the project and it is probable the software will be completed for its intended use — with preliminary planning and post-implementation maintenance work expensed as OpEx on either side of that capitalizable window.

The accounting standard governing this distinction changed meaningfully in September 2025. FASB's ASU 2025-06 removes the previous requirement to map costs to specific project development stages, a rule that had never fit cleanly with agile development, where planning, coding, and bug fixing routinely happen within the same sprint. Under the new standard, capitalization begins based on two tests — management commitment to funding and probability of completion — rather than which named phase the work falls into. This change takes effect for annual reporting periods beginning after December 15, 2027, but early adoption is permitted, and companies still operating under the old three-stage model should begin planning the transition now rather than waiting for the mandatory date.

The classification decision is not purely academic. CapEx treatment spreads the cost across the balance sheet and improves near-term reported earnings, since the expense is amortized over multiple years rather than hitting the income statement in full during the build period — a meaningful lever for a company managing EBITDA optics ahead of a fundraise or exit. OpEx treatment, conversely, offers greater budgeting flexibility and avoids the administrative burden of tracking capitalizable time, which is precisely why cloud migration shifting spend from owned infrastructure to consumption-based services is described by Gartner as the defining financial trend in enterprise IT for 2026.

Correctly capitalizing software costs under agile development requires disciplined time tracking at the task level, distinguishing capitalizable development work from non-capitalizable planning, research, and maintenance activity within the same sprint. Companies that find this administratively unmanageable a common outcome, since a single sprint can include research, development, and bug fixing with three different accounting treatments often abandon capitalization altogether, which is a defensible choice operationally but one that leaves EBITDA and valuation upside unclaimed on the balance sheet.

Domestic Section 174 rules required the amortization of software development costs over five years (fifteen for offshore development) for several recent tax years — a materially different timeline than typical financial-statement amortization schedules — so a company's capitalization policy for GAAP reporting purposes does not automatically determine its tax treatment, and the two should be modeled separately with a tax advisor.

What Do Post-Launch Software Costs Actually Run?

Annual post-launch maintenance for custom software typically runs 15 to 25 percent of the original development cost for a reasonably well-built system, rising to 30 to 40 percent for legacy or poorly architected platforms — and this figure compounds every year the software remains in active use, making it a recurring budget line rather than a one-time cost.

These percentages break down into three cost categories that a CFO should budget for separately, since they behave differently and are cut in a different order when budgets tighten. Perfective maintenance — UI refinement, latency improvements, minor feature additions — typically consumes the largest share of the post-launch budget in 2026, driven by the recognition that customer retention correlates directly with a product's perceived freshness and responsiveness. Adaptive maintenance covers the work required simply to keep the software compatible with a changing environment: security patches, dependency updates, and third-party API changes that break existing integrations without warning. Preventive maintenance — technical debt reduction, refactoring, and documentation — is the most consistently underfunded category, precisely because skipping it produces no visible short-term consequence, right up until it does.

The cost of deferring preventive maintenance compounds in a specific, measurable way: a year of skipped dependency updates might take two to three days to resolve later, while two years of deferral can take two to three weeks, because major version jumps introduce breaking changes that cascade through the codebase rather than accumulating linearly. This is the mechanism behind the jump from a 15-25 percent maintenance budget to a 30-40 percent one — it is rarely a single bad decision, but a compounding pattern of deferred preventive work.

Infrastructure hosting costs sit alongside, not inside, the maintenance percentage above. A growth-stage application commonly runs $100 to $400 monthly in baseline infrastructure — hosting, database, transactional email — scaling with usage well beyond that baseline as traffic grows. Security-specific costs also scale with regulatory exposure: platforms under HIPAA, PCI DSS, or GDPR carry additional recurring costs for penetration testing, audit logging, and encryption updates that a consumer-facing application without regulated data simply does not face, and these should be modeled as a distinct line item rather than folded into a generic maintenance percentage.

The Consortium for IT Software Quality estimates in its 2022 report that the cost of poor software quality in the US reached $2.41 trillion, a substantial share of it attributable to accumulated technical debt — a useful figure for a CFO pushing back against pressure to cut preventive maintenance spend, since it frames technical debt not as an engineering abstraction but as a quantified, industry-wide drag on capital efficiency.

How Should a CFO Model the Total Cost of Ownership Before Approving a Build?

A defensible total cost of ownership model for custom software should combine the capitalized build cost, a realistic first-year maintenance estimate at 15 to 25 percent of build cost, infrastructure costs scaled to expected usage, and a specific allowance for preventive maintenance — with the model revisited annually rather than treated as a one-time estimate fixed at launch.

// Simplified 3-year TCO framework for a custom software build
Year 1: Build cost (capitalized under ASC 350-40, subject to management
         commitment and completion-probability tests)
       + Infrastructure ramp-up (hosting, database, monitoring)

Year 2: Maintenance @ 15-25% of build cost (standard) or 30-40% (legacy/
         high-debt systems)
       + Infrastructure cost scaled to actual usage growth
       + Preventive maintenance allowance (explicitly budgeted, not implied)

Year 3: Maintenance cost typically meets or exceeds original build cost
         on a cumulative basis for actively used systems
       + Compliance/security costs if regulatory scope has expanded

The most common planning failure is not underestimating any single line item, but omitting the recurring lines entirely from the initial approval — founders and finance teams who budget only for the launch cost are, by the industry's own maintenance benchmarks, looking at roughly 40 to 60 percent of the true multi-year cost of the platform. Building the full three-year model in before a build is approved, rather than discovering the maintenance line item after the first post-launch invoice arrives, is what separates a CFO who can forecast software spend accurately from one who is perpetually surprised by it. If the build quote is only one line in a wider funding decision, our breakdown of dedicated development team costs works through the staffing side of the same model.

Where Geekssort Fits

Geekssort scopes custom software builds with the full multi-year cost curve made explicit from the proposal stage — separating capitalizable build cost from the maintenance, infrastructure, and technical debt allowances a CFO needs to model accurately, for clients across the US, UK, UAE, Australia, and DACH markets. For a finance team building a total cost of ownership case for a new platform, a structured cost breakdown against the categories in this article is the starting point for a defensible multi-year budget rather than a single up-front estimate.