SaaS vendors: building an advantage beyond the AI feature

An AI feature can materially improve a product, but it becomes a durable advantage only when it rests on assets and execution that a competitor cannot reproduce by adding the same model to its interface.

• Access to a general-purpose model and common integration components is widely available.
• Domain knowledge, authorised data, distribution and position in the customer’s workflow remain specific to each vendor.
• Reliability, cost per operation and governance take time to build and must be demonstrated in production.

---

Code throughput does not measure delivered value

Evidence published in 2026 supports a narrow but useful conclusion: AI can accelerate individual tasks, while enterprise value still depends on the organisation’s ability to integrate, verify and use that work at scale.

• KPMG classifies 11% of its 2,110 respondents as “AI leaders”, a maturity category in a sample where 75% of organisations have more than $1 billion in annual revenue, rather than a universal rate of organisations obtaining value [3].
• The same report describes orchestration across systems, workflows and teams as an observed difference between isolated uses and enterprise capability [3].
• A software vendor should therefore measure the path to production: lead time, change failure rate, recovery time, defects and product outcome.

Generation speed becomes counterproductive when review, testing and correction consume the time saved upstream, which makes the complete delivery flow more informative than lines of code or tickets completed.

• Measuring generation and verification time separately reveals where work has moved.
• Comparing changes of similar size and risk avoids attributing a change in work mix to the tool.
• Linking every pilot to a product metric prevents greater technical activity from being mistaken for customer benefit.

---

Technical debt constrains coding agents too

An agent connected to a fragmented estate may accelerate code comprehension and modification, but it also inherits the coupling, implicit rules and missing controls that already made the estate difficult to change.

• A tightly coupled architecture increases the blast radius of an apparently local change.
• Missing documentation deprives both agent and team of the context needed for sound decisions.
• A fragile CI/CD chain slows feedback and raises the cost of regressions.
• Imprecise access controls increase the risk of exposing code, secrets or personal data.
• Weak tests allow gaps between intent, implementation and actual behaviour to reach production.

The “Debt Behind the AI Boom” study offers empirical evidence of this risk without showing that all AI-generated code degrades a system: its authors analysed 304,362 commits attributed to five assistants across 6,275 GitHub repositories and tracked issues detected through static analysis [1].

• More than 15% of commits from each assistant studied introduced at least one issue detected by the method.
• Code smells accounted for 89.1% of the 484,606 issues identified.
• Of the tracked issues, 24.2% remained in the latest observed revision, supporting stronger controls without providing a defect rate for any particular project.

Data debt completes the diagnosis because an application may be technically sound yet produce fragile answers when its reference data conflicts, usage rights are unknown or provenance is not traceable.

• Uniqueness and freshness determine the consistency of outputs.
• Rights, confidentiality and retention determine which uses are permitted.
• Source traceability determines whether an answer can be checked and challenged.

---

Modernising legacy systems with controlled agents

Recent coding models make large modernisation programmes more accessible, but vendor-published scores and demonstrations should justify a pilot rather than establish reliability on a particular software estate.

• Anthropic reports that Claude Opus 4.8 scores 88.6% on SWE-bench Verified and 69.2% on SWE-bench Pro, two software issue-resolution evaluations [2].
• Anthropic also presents dynamic workflows that can plan, distribute and verify a large codebase migration; this is a vendor-stated capability whose outcome depends on the harness, tests and context [2].
• An internal Anthropic evaluation indicates that the model is less likely to let a flaw in its own code pass without comment; it does not measure a general production defect rate [2].

A controllable modernisation programme breaks the work into verifiable artefacts and leaves the team responsible for accepting, correcting or abandoning every change.

• Map dependencies, business rules and untested areas before modification.
• Reverse-document and isolate dead code with validation from domain owners.
• Generate characterisation tests to preserve intended behaviour before refactoring.
• Migrate in reversible, observable batches with a limited blast radius.

The operating discipline can be summarised as “Plan, Execute, Verify”, provided that each stage specifies its evidence and authority.

• The plan defines scope, acceptance criteria, access and stop conditions.
• Execution logs actions, tools called, costs and proposed changes.
• Verification combines automated tests, human review proportionate to risk and post-deployment observation.

---

Prioritising by process and strength of evidence

The best first target is the one whose actual workflow, data, risk and outcome can be observed well enough to support a stop-or-scale decision, rather than the one attached to the largest abstract forecast.

• Reconstruct the process from ERP, CRM or delivery traces when the logs are sufficiently complete.
• Select a limited number of cases with plausible impact, controlled dependencies and clear human oversight.
• Define a baseline, the full cost of the pilot and an evaluation window suited to the business cycle.
• Defer a case whose data, rights or quality criteria do not yet permit credible measurement.

Data Fabric and Data Mesh answer different organisational choices and should not become ceremonial prerequisites: the practical issue is who produces each data set, under which contract, at what quality level and for which authorised uses.

• A Data Fabric approach favours a coherent integration, metadata and governance layer across silos.
• A Data Mesh approach distributes responsibility for data products to business domains under shared contracts.
• A hybrid architecture is often more realistic if it makes owners, interfaces and controls explicit.

---

Developers become accountable for a wider production system

As generation automates more tasks, the developer’s contribution shifts towards specifying intent, architecture, evaluation and risk control, without removing the need to understand the code being delivered.

• Framing the problem and supplying the right context determine what an agent can reasonably execute.
• Deciding on dependencies, security and maintenance trade-offs requires understanding the whole system.
• Reviewing evidence, tests and deviations preserves human accountability for release.
• Teaching these practices to junior staff avoids reserving system knowledge for established experts.

Change management should treat the tool as a new delivery system with evolving roles and quality criteria, rather than merely as a way to reduce typing time.

• Involving teams in use-case and policy choices exposes operational constraints early.
• Training in decomposition, testing, security and critical review complements interface proficiency.
• Evaluating delivered quality and maintainability discourages unnecessary code generation.

---

Assets that make an offer difficult to replace

An AI feature can contribute to an advantage, but its defensibility comes from a combination of assets that customers value and competitors cannot recreate simply by changing models.

• Proprietary or contractually accessible data improves the service when it is relevant, governed and difficult to assemble.
• Effective distribution lowers acquisition cost and establishes trust before feature comparison.
• Deep workflow integration raises practical value, provided portability is handled honestly.
• Measured reliability, competent support and demonstrable governance reduce perceived risk.
• Controlled unit economics sustain the service and its quality as usage grows.

---

Connecting price to value and inference cost

Embedded AI adds a variable cost to a SaaS business often sold by subscription, so greater usage can reduce margin if price, limits and architecture do not follow the actual cost to serve.

• Measuring cost by feature, request, customer and quality tier reveals cross-subsidies.
• Routing simple tasks to a sufficient model and reserving expensive models for justified cases lowers cost without promising identical quality.
• Caching stable results and removing unnecessary context reduces calls, subject to freshness and confidentiality requirements.
• The choice between subscription, credits, usage and outcome pricing depends on the predictability of cost and perceived value.

A sound pricing decision uses contribution margin by segment and volume scenarios rather than a sector average that reflects neither the vendor’s model mix nor its service level.

• Include inference, storage, observability, review, support and incidents in cost to serve.
• Stress-test intensive use cases and agent loops to size quotas and circuit breakers.
• Revisit assumptions when supplier prices, routing or customer behaviour changes.

---

Turning governance into evidence of trust

A vendor’s role under the AI Act depends on what it develops or commissions, how the system is placed on the market or put into service and whose name it bears; embedding a third-party API does not by itself settle whether the vendor is a provider or deployer [4].

• A provider develops or has an AI system developed and places it on the market or puts it into service under its own name or trade mark.
• A deployer uses an AI system under its authority in a professional context, subject to the regulation’s other conditions.
• A single value chain may allocate different roles to the model provider, application vendor and customer according to the facts and modifications made.

Since 2 August 2026, Article 50 has imposed targeted transparency duties whose allocation varies by role, system and content, requiring analysis by feature rather than a blanket compliance statement [4].

• Providers of systems intended to interact directly with people must provide the required disclosure unless the AI interaction is obvious in context.
• Providers of relevant generative systems must enable machine-readable marking of generated or manipulated outputs.
• Deployers have specific duties concerning emotion recognition, biometric categorisation, deepfakes and certain public-interest text.

ISO/IEC 42001 can structure the policies, objectives and processes of an AI management system, while SecNumCloud qualifies a particular cloud service after assessment and does not automatically pass to an application merely hosted on that service [5][6].

• ISO/IEC 42001 covers the establishment, implementation, maintenance and continual improvement of an AI management system.
• SecNumCloud recognises a specific service and requires a separate process for the offer claiming qualification.
• These frameworks can strengthen commercial evidence of control, but they guarantee neither complete legal compliance nor total product security.

---

A roadmap built around five verifiable decisions

A twelve-month transformation can be organised into five successive decisions, each producing the evidence needed to take the next step without turning the duration into a universal promise.

• Diagnose the delivery flow, technical and data debt, costs, skills and regulatory roles.
• Scope one internal modernisation case and one product case with a baseline, acceptance criteria and stop conditions.
• Prepare the access, tests, logs, budgets, responsibilities and controls required for those cases.
• Pilot in a reversible scope while measuring net gain, quality, cost to serve and incidents.
• Decide whether to scale, adapt or stop, then change the organisation and pricing from the results.

---

What a competitor finds harder to copy

A vendor’s advantage comes from combining a useful product, a modernisable estate, developers able to supervise agents, credible governance and economics that remain sound as usage grows, rather than from the AI button in isolation.

• Treat code generation as an acceleration subject to the same quality evidence as the rest of engineering.
• Invest in the data, workflow, distribution and trust that give the feature its distinct value.
• Measure the result end to end so that speed, compliance and margin remain compatible.

To position your organisation and choose a sensible first project, the Junyr AI maturity audit is a free, no-commitment 30-minute video call followed by a one-page summary.

---

Sources

1. Liu, Widyasari, Zhao, Irsan and Lo, “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild”, arXiv, 30 March 2026.
2. Anthropic, “Introducing Claude Opus 4.8” and the Claude Opus 4.8 System Card, 28 May 2026.
3. KPMG International, “Global AI Pulse: Q1 2026”, April 2026, 2,110 leaders across 20 countries, territories and jurisdictions.
4. European Union, Regulation (EU) 2024/1689, especially Articles 3 and 50; European Commission, Guidelines on transparency obligations, updated 6 August 2026.
5. ISO, ISO/IEC 42001:2023 — Artificial intelligence management systems.
6. ANSSI, FAQ on starting the SecNumCloud qualification process.