AI Productivity Discount and Cost to Recreate: Software, SaaS, CRM

Introduction: the cost-to-recreate method meets AI development tools

Will a developer equipped with Claude or GitHub Copilot really cost less to employ than a developer working without assistance? The question sounds trivial, but it is now unsettling one of the three classic approaches used in intangible asset valuation: the cost to recreate, which estimates the value of a piece of software, a SaaS product or a CRM by the cost it would take today to rebuild it from scratch. Under IVS 210 of the International Valuation Standards Council, this cost approach remains one of the three recognized methodological families in intangible asset valuation, alongside the market approach and the income approach.

"An obsolescence adjustment should be applied to the cost to recreate or the replacement cost where the asset exhibits functional, technological or economic obsolescence.", International Valuation Standards Council, IVS 210.

In 2026, three factors converge to make this technological obsolescence adjustment harder to document than before. First, productivity studies published since 2023 report contradictory results depending on the context observed, ranging from a speed gain of more than 50% on a laboratory task to a measured slowdown among experienced developers working on mature code. Second, the technical literature documents a risk of deferred technical debt that can partially cancel out the apparent speed gain. Third, no published valuation doctrine, whether from the IVSC, the AICPA or the American Society of Appraisers, currently offers a quantified grid for adjusting the software cost to recreate in the era of generative artificial intelligence, exposing valuers to arbitrary discounts that are not defensible under audit or litigation.

This article proposes a reference grid built exclusively from verifiable empirical studies, which distinguishes several development contexts rather than relying on a single figure. It presents the definition and origin of the cost-to-recreate method, the reasons for and steps of its adjustment, the situations in which it applies, two quantified case studies, a frequently asked questions section and an operational summary.

Secure the valuation of your software assets

Before applying a discount to the cost to recreate a piece of software, a SaaS product or a CRM, a 30-minute conversation with Hectelion lets you qualify the real context of your codebase, identify the studies relevant to your case and build a defensible estimate for an investor, an auditor or a tax authority.

Acontos: get a free online estimate of your company's value

Before going further, Hectelion has developed Acontos, an online audit, due diligence and business valuation tool, powered by Claude Sonnet 5 artificial intelligence by Anthropic and calibrated using Hectelion's methodology. From your financial statements, it produces, within minutes, a first estimate of the value of your shares, free of charge and without retaining any document. Launch the valuation simulator to get an order of magnitude, then continue reading to understand what drives it.

Definition: what is the AI productivity discount on cost to recreate?

The AI productivity discount is the adjustment applied to the gross cost of rebuilding a software asset to reflect the positive or negative effect of generative artificial intelligence tools on development time and cost. It follows the classic logic of technological obsolescence, which requires correcting the cost to recreate or the replacement cost whenever a more efficient or less costly technology makes the valued asset prematurely outdated.

Two points need to be made from the outset. First, the discount does not apply to the final value of the software, only to the cost of its hypothetical reconstruction, which makes it a parameter of the cost approach rather than the income approach. Second, contrary to a widespread intuition, the adjustment is not always a discount: in certain contexts of mature code maintained by highly specialized teams, available studies observe the opposite effect, which would instead justify a premium on the cost to recreate. The next section traces the origin of this question and explains why it cannot be settled with a single figure.

Origin: from the COCOMO model to AI-augmented productivity

The idea that the cost to recreate a piece of software cannot be reduced to a linear sum of working hours is not new. As early as 1995, the COCOMO II parametric model, developed by Barry Boehm at the University of Southern California, incorporated multiplicative adjustment factors for the reuse and reengineering of existing code, combining code understanding, programmer familiarity and the structure of the existing codebase. This methodological precedent established, well before generative artificial intelligence, that an adjustment to development cost must rest on several contextual factors rather than on a single percentage.

The question of AI-augmented productivity emerged from 2022 onward, with the commercial rollout of GitHub Copilot followed by large conversational language models. A first randomized study, conducted by researchers from Microsoft, GitHub and MIT in 2023 on a sample of freelance developers, measured a speed gain of 55.8% on a standardized programming task. This widely publicized result fueled the idea of a uniform discount applicable to all software development. Studies published since 2024 by Microsoft, Google and the research organization METR significantly qualify this initial result, which is the core issue addressed in this article.

Special case: is software mostly generated by AI still protected by copyright?

IVS 210 requires an intangible asset to be identifiable and controlled by the business in order to be valued separately, which presupposes stable legal title. Under French law, however, Article L112-2 of the Intellectual Property Code protects software under copyright, a protection that traditionally presupposes an original work resulting from a human intellectual contribution. Under Swiss law, Article 2(3) of the Federal Act on Copyright and Related Rights holds the same principle for computer programs. Where a substantial part of the code is generated by an artificial intelligence tool without meaningful human supervision or revision, the qualification as an original work becomes uncertain in both legal systems, which weakens the chain of title and, by extension, the very relevance of a cost-to-recreate valuation.

This uncertainty is not purely theoretical for the valuer. A piece of software whose title to rights is questionable sees its value reduced independently of any productivity adjustment, and this risk must be documented separately from the AI productivity discount addressed in this article. In practice, case law and doctrine on this specific point remain nascent at the time of writing, which requires the valuer to pay particular attention to documenting the development process, in particular the trace of human contributions to design, review and validation of the generated code.

Why adjust the software cost to recreate in the age of artificial intelligence

• Ignoring the positive effect in a favorable context: ignoring the effect of generative AI on development cost leads to a systematic overstatement of the cost to recreate in contexts where that effect is genuinely positive, particularly for standard code developed by junior or intermediate teams.
• Ignoring the negative effect in a legacy context: conversely, mechanically applying a uniform discount leads to an understatement in contexts where AI slows down production, particularly on complex legacy code maintained by highly experienced teams, a counterintuitive but documented result from a randomized study by METR in 2025.
• Deferred technical debt: AI-assisted code generation comes with a risk of deferred technical debt, documented by an analysis of 211 million lines of code published by GitClear in 2025, which must be taken into account to avoid confusing a gross speed gain with a net productivity gain.
• Growing documentation requirements: tax authorities and auditors scrutinize with increasing attention the assumptions used in intangible asset valuation reports, which requires documenting any discount with verifiable sources rather than an intuitive estimate.
• An opportunity to structure a doctrine: the absence of an established doctrine on this specific topic gives a valuation firm an opportunity to build a rigorous methodology before heterogeneous and poorly documented market practices become entrenched.

This question is not merely academic. In October 2026, Hectelion held discussions with the management of a software publisher engaged in migrating its products from desktop to cloud, whose leadership estimates that artificial intelligence reduces the cost of developing a digital product by around 50%. This figure, in the same order of magnitude as the upper bound of the confidence interval measured by Peng and co-authors but well above the gain observed in real enterprise conditions by Cui and co-authors, illustrates exactly the risk described above: a field estimate, however sincere, does not amount to a documented discount unless it is tied to a precise codebase and team context and to a verifiable empirical source.

How the AI productivity discount grid is built

Building a defensible discount follows a six-step sequence that deliberately departs from the practice of applying a single percentage.

• Establish the gross cost to recreate: following the classic cost approach method, based on an independent technical estimate expressed in development, testing and documentation hours, valued at a blended hourly rate representative of the local market.
• Qualify the context of the software being valued: along two crossed axes, the type of codebase (recent standard development or complex legacy system) and the experience level of the development team on that specific code, a qualification that can usefully be supplemented by the asset's technological maturity level, measured for example on a scale such as Technology Readiness Level.
• Select the interval in the reference grid: the gross discount or premium interval corresponding to that context, anchored on the empirical study most representative of the actual situation rather than on the most favorable study.
• Apply the technical debt holdback: a cross-cutting holdback of 10 to 15 percentage points, designed to capture the deferred maintenance risk documented in the literature regardless of the context selected.
• Document the reasoning: every assumption used, the empirical source relied upon and the reasoning behind selecting the exact point within the interval, so that the calculation withstands adversarial review.
• Submit to independent review: the discount used, to a second valuer, particularly when the amount at stake is material relative to the asset's total value.

Reference grid built from the studies cited in the sources. The intervals are not an automatic standard but an anchor point to be refined according to the software being valued.

Choosing between the cost approach and the income approach when AI compresses the cost to recreate

Some commentators argue that the general decline in software development cost, facilitated by generative AI tools, makes the cost approach increasingly irrelevant for software generating significant revenue. This argument deserves to be qualified rather than dismissed. When the gross cost to recreate tends to fall sharply, the gap with the software's true value, as measured by its future cash flows, widens mechanically, which should lead the valuer to favor the income approach whenever identifiable cash flows exist, and to retain the cost approach only as a control method or for recent software lacking a sufficient operating history.

Hectelion addresses the complementary question of technological obsolescence applied to the income approach elsewhere, in particular through the attrition rate used to model the economic useful life of a piece of software or a SaaS product in light of the accelerating pace of innovation driven by artificial intelligence. The two grids, the cost-to-recreate grid presented in this article and the attrition-rate grid applied to the income approach, must be used consistently whenever a valuation combines both approaches as a cross-check.

When to use this discount grid

Using this discount grid is warranted whenever an intangible asset valuation report applies the cost approach to software, a SaaS product or a CRM whose development or maintenance relies, even partially, on generative artificial intelligence tools. This is notably the case during a valuation conducted for a fundraising round, a contribution in kind of a software asset to a company's share capital, an impairment test under IAS 36 or Swiss GAAP FER 27 where the cost to recreate serves as a control method, or a dispute between shareholders over the value of an internally developed technology asset.

The grid is also useful during a contractual negotiation between a software vendor and its counterparty, where the cost to recreate serves as a minimum reference for setting a license price or a royalty, as well as during a technology due diligence preceding an acquisition, where the acquirer wants to verify that the price proposed for a software asset does not reflect a historical development cost that has become outdated relative to the tools available today.

Who to call on to apply this discount grid

Rigorously applying this grid requires bringing together three skills rarely found in a single person. The first is mastery of intangible asset valuation standards, in particular IVS 210 of the IVSC, which governs the choice and implementation of the cost, market and income approaches. The second is sufficient technical understanding of software development to properly qualify a codebase's context, its technical debt and the team's actual familiarity with the code concerned. The third is the ability to follow a fast-moving empirical literature, published in English by research organizations and technology labs, and to distinguish a robust result from a preliminary or contested one.

Hectelion brings together these three skills within its intangible asset valuation engagements, with dual French and Swiss expertise and economic independence from traditional financial intermediaries. The firm is not FINMA-licensed and therefore does not operate on transactions involving listed companies, a limitation with no bearing on software and SaaS valuation engagements, which represent the vast majority of situations covered by this grid.

Advantages: methodological rigor, defensibility, relevance

• A grid grounded in published randomized studies, rather than in an intuitive estimate, which better withstands adversarial review before a court, an auditor or a tax authority.
• An explicit distinction between development contexts, which avoids wrongly penalizing complex legacy software or, conversely, understating the relevant discount for recent standard development.
• A possible update as the literature on the productivity of generative AI tools continues to grow, without calling into question the method's overall structure.
• Consistency with the practice established in software engineering since the COCOMO model, which anchors the approach in a recognized precedent rather than in an isolated methodological innovation.

Limitations: scientific uncertainty, heterogeneity, lack of consensus

• Available studies rely on small samples, ranging from 16 to 95 developers depending on the case, and a replication conducted by METR in 2026 shows that the confidence interval of some results contains zero, which calls for great caution regarding the precision of the figure used.
• No published valuation standard, whether from the IVSC, the AICPA or the American Society of Appraisers, currently offers an official quantified grid on this specific topic, meaning that any discount used rests on the valuer's professional judgment rather than on the mechanical application of a standard.
• Available results predominantly concern English-speaking environments and mainstream programming languages, which limits their direct transposition to software developed in different technologies or linguistic contexts.
• The literature is evolving rapidly, which requires periodically reviewing the grid used rather than treating it as permanently fixed.

The 5 mistakes to avoid in the AI productivity discount

Mistake 1: using a single figure regardless of context

Applying a flat discount of 20% or 30% to any piece of software, regardless of its context, ignores the considerable dispersion of empirical results depending on the type of codebase and the development team's experience level. This simplification produces an estimate that is not defensible as soon as a counterparty cites a contrary study.

Mistake 2: confusing gross speed gain with net productivity gain

A speed gain measured on lines of code produced does not automatically translate into a net productivity gain, since part of that code will have to be reworked later. The analysis of 211 million lines published by GitClear in 2025 documents a marked rise in duplicated code and a decline in the volume of refactored code, which should reduce the gross discount applied.

Mistake 3: ignoring the reverse effect on complex legacy code

Assuming that artificial intelligence systematically speeds up development leads to overlooking the most counterintuitive finding of the recent literature: a randomized study by METR observes a 19% slowdown in 2025 among experienced developers working on mature repositories they know well, in particular because the assistant does not have access to the tacit knowledge of the codebase accumulated by the team.

Mistake 4: extrapolating a laboratory result to a real production context

The most spectacular result, a 55.8% speed gain measured by Peng and co-authors in 2023, comes from a standardized programming task performed by freelance developers, not from a real enterprise production context. A later study conducted in real conditions at Microsoft, Accenture and a Fortune 100 group measures a significantly lower gain of 26.08%, which should guide the choice of anchor used in the grid.

Mistake 5: failing to document the discount used

An unsourced discount, however reasonable in principle, does not withstand a tax audit or a dispute between shareholders. Every discount used must be accompanied by the empirical source relied upon, the reasoning behind selecting the point within the interval and, where relevant, a second valuer's opinion.

Case 1: SaaS CRM developed by a mixed junior and mid-level team

A company publishes a vertical CRM aimed at SMEs in the transportation sector, developed over 18 months by a team of 4 developers, two mid-level and two junior, in the context of a planned contribution in kind to the share capital of a holding company.

• Estimated volume: 10,800 hours of development, testing and documentation, equivalent to 150 monthly hours per developer over 18 months.
• Blended hourly rate used: CHF 115, representative of the Swiss Romandy market for this team profile.
• Gross cost to recreate: 10,800 hours multiplied by CHF 115, or CHF 1,242,000.
• Context selected in the grid: recent, standard development, mixed junior and mid-level team, anchored on the study conducted in real enterprise conditions rather than on the laboratory task.

The gross speed gain used is 26%, anchored on the study by Cui and co-authors conducted in real conditions at Microsoft, Accenture and a Fortune 100 group, considered more representative of this production context than a laboratory task. A technical debt holdback of 12 points, at the midpoint of the 10-to-15-point interval documented by GitClear, is deducted to account for the risk of unrefactored duplicated code. The net discount applied therefore stands at 26% minus 12 points, or 14%. The adjusted cost to recreate comes to CHF 1,242,000 multiplied by 0.86, or CHF 1,068,120, against an unadjusted gross cost of CHF 1,242,000 that would have overstated the asset's value by CHF 173,880.

Case 2: legacy industrial ERP maintained by a highly experienced senior team

An industrial group holds an internal production management ERP, comprising 420,000 lines of code and developed 11 years ago, maintained from the outset by a team of 3 senior developers whose average tenure on this code reaches 9 years. The context arises in connection with an impairment test under IAS 36.

• Estimated volume for a hypothetical reconstruction: 13,500 hours, equivalent to 150 monthly hours per developer over 30 months, a longer horizon than Case 1 given the system's complexity.
• Blended hourly rate used: CHF 130, representative of a senior profile specialized in industrial systems.
• Gross cost to recreate: 13,500 hours multiplied by CHF 130, or CHF 1,755,000.
• Context selected in the grid: complex legacy codebase, senior team highly familiar with the code, the exact context of the randomized study published by METR in 2025.

That study observes, in this precise context, a 19% slowdown in output among AI-assisted developers, attributed in particular to a suggestion acceptance rate below 44% and to the assistant's lack of tacit knowledge of the code. No discount is therefore applied; a 15% premium, at the midpoint of the 10% to 20% interval documented for this context, is instead applied to reflect the additional review and correction time generated by a poorly calibrated use of AI tools on this type of system. The adjusted cost to recreate comes to CHF 1,755,000 multiplied by 1.15, or CHF 2,018,250. This result illustrates why a uniform discount would, in this precise case, have understated the asset's value by more than CHF 450,000 relative to the documented adjustment.

A Word from the Director

"For two years now, I have seen the idea spreading that artificial intelligence would mechanically make software development cheaper, and therefore any software asset cheaper to rebuild. That idea is not wrong, but it is incomplete, and it is precisely that incompleteness that becomes a problem in a valuation report meant to withstand adversarial review."

"The studies published since 2023 tell a more nuanced story than a simple, generalized productivity gain. A spectacular speed gain measured in the laboratory becomes far more modest in real enterprise conditions, and even turns into a documented slowdown among experienced developers working on mature code they know intimately. Ignoring this dispersion, in favor of a convenient single figure, amounts to sacrificing the rigor of the valuation for the simplicity of the presentation."

"I built this grid to give our clients, and the profession more broadly, a documented starting point rather than an intuitive estimate. It is not meant to replace the valuer's professional judgment, but to anchor it on verifiable sources that can be updated as research progresses. At Hectelion, we believe a valuation method is only as good as the solidity of the sources underpinning it, particularly on a topic as recent and fast-moving as the impact of generative artificial intelligence on software development cost."

FAQ: the 10 essential questions about the AI productivity discount

Introduction: what to know before the questions

The questions below come up systematically during software, SaaS and CRM valuation engagements that incorporate an adjustment linked to the productivity of artificial intelligence tools, and they clarify the points most often misunderstood on this recent topic.

Q1: is there a standard AI discount recognized by IVS or AICPA standards for the software cost to recreate?

No. Neither the IVSC, nor the AICPA, nor the American Society of Appraisers currently publish an official quantified grid on this specific topic. IVS 210 only requires the principle of a technological obsolescence adjustment, without specifying its level for this particular use case.

Q2: why do studies on developer productivity with AI produce such different results?

Because they measure different contexts. A standardized programming task performed by freelance developers on a new project does not reproduce the conditions of an experienced developer working on a mature system they have known for years, which explains the gap between a 55.8% gain in the laboratory and a 19% slowdown in complex real-world conditions.

Q3: can a legacy piece of software see its cost to recreate increase because of artificial intelligence?

Yes, in certain documented contexts. The randomized study published by METR in 2025 measures a slowdown in output among experienced developers working on mature, complex code, which justifies, in this specific case, a premium rather than a discount on the cost to recreate.

Q4: how does technical debt linked to AI-generated code affect the discount?

An analysis of 211 million lines of code published by GitClear in 2025 documents a marked rise in duplicated code and a decline in refactored code between 2021 and 2024. This deferred maintenance risk justifies a holdback of 10 to 15 points applied to any discount calculated from the speed gain alone.

Q5: should the same discount apply to an internal ERP and a commercial SaaS product?

No. The grid distinguishes the context by the type of codebase and the team's experience level rather than by the software's commercial or internal purpose. A recent internal ERP developed by a junior team follows the same adjustment logic as a commercial SaaS product under the same conditions.

Q6: what is the difference between cost to recreate and replacement cost?

The cost to recreate targets an identical replica of the asset, with the same architecture and the same functionalities, while the replacement cost targets equivalent utility obtained through current technological means. The AI productivity discount applies to both variants, but its interpretation differs slightly depending on which variant is used.

Q7: does the AI discount replace classic technological obsolescence or does it add to it?

It adds to it. Classic technological obsolescence covers any risk that a more efficient technology renders the asset outdated; the AI productivity discount is a specific and recent component of it, tied precisely to AI-assisted development tools.

Q8: how should the discount used be documented to withstand a tax audit or a dispute?

Every discount must be accompanied by the precise empirical source relied upon, the reasoning behind selecting a given point within the documented interval, and ideally a second valuer's opinion when the amount at stake is material relative to the total value of the asset being valued.

Q9: should the discount grid be reviewed regularly?

Yes. The literature on the productivity of generative AI tools is evolving rapidly, as illustrated by the replication published by METR in 2026, which significantly qualifies the initial 2025 result. An annual review of the grid used is recommended.

Q10: which method should be preferred if the cost to recreate is not relevant for this software?

When the software generates identifiable and significant cash flows, the income approach, whether through a discounted cash flow analysis or a royalty method, generally provides a more robust basis than the cost approach, which remains better suited to recent software or software lacking a sufficient operating history.

Estimate your company's value with Acontos, Hectelion's online simulator

To extend this reading with a concrete figure, Hectelion provides Acontos, its online audit, due diligence and business valuation tool. Powered by Claude Sonnet 5 artificial intelligence by Anthropic and calibrated using Hectelion's methodology, it reads your financial statements, normalizes EBITDA, applies real sector multiples and reconstructs a net debt bridge to estimate the value of your shares within minutes. Launch the valuation simulator for free: the tool is confidential, retains no document and does not replace a formal valuation, but it provides a reliable first order of magnitude before discussing it with our team.

Conclusion: a grid rather than a single figure

Whether artificial intelligence justifies a discount on the cost to recreate a piece of software, a SaaS product or a CRM has no single answer, and that is exactly what the empirical literature available since 2023 demonstrates. A speed gain measured in the laboratory only partially holds up in real enterprise conditions, and can even reverse when experienced developers work on mature code they know intimately.

Faced with this dispersion, the only defensible approach is to precisely qualify the context of each piece of software being valued, to anchor the discount used on the study most representative of that context, to apply a cross-cutting holdback for deferred technical debt, and to document the entire reasoning so that it withstands adversarial review. This approach, consistent with the practice established in software engineering since the COCOMO model, carries over to generative artificial intelligence an old principle: an adjustment to development cost rests on several contextual factors, never on a single percentage applied without discernment.

Article summary

The cost to recreate remains an approach recognized under IVS 210 for valuing software, a SaaS product or a CRM, but its application in 2026 requires a technological obsolescence adjustment specific to generative artificial intelligence. Available studies show widely dispersed results depending on context: a 55.8% speed gain in the laboratory, a 26.08% gain in real enterprise conditions, and a 19% slowdown among experienced developers working on complex legacy code.

This dispersion rules out a single figure. The grid proposed in this article distinguishes the context by the type of codebase and the team's experience level, applies a cross-cutting holdback of 10 to 15 points for the technical debt documented by GitClear, and explicitly provides for a premium scenario rather than a discount for legacy systems maintained by highly specialized teams.

The two case studies illustrate the concrete gap produced by this contextualized approach: a net discount of 14% for a SaaS CRM developed by a mixed team, versus a 15% premium for a legacy industrial ERP maintained by a senior team, two opposite adjustments that a single figure could never have captured correctly.

In the absence of a published doctrine on this specific topic, rigor of approach and traceability of the sources used provide the valuer's and the client's best protection, and, where relevant, shape the outcome of an audit or a dispute over the value of a software asset.

Sources

• Cui, Demirer, Jaffe, Musolff, Peng and Salz, The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, 2025
• GitClear, AI Copilot Code Quality, analysis of 211 million lines of code, 2025
• Google Cloud, DORA, State of DevOps Report, 2024
• International Valuation Standards Council (IVSC), IVS 210, Intangible Assets
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025
• Peng, Kalliamvakou, Cihon and Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, 2023

Author

Aristide Ruot, Ph.D.
Founder | Chief Executive Officer, Hectelion SA