Custom software vs off-the-shelf in 2026: costs & decision

In 2026, the question is no longer simply whether to build or buy. Between an unchanged SaaS product and a complete custom build sit configuration, integration, low-code and, increasingly, composable systems. AI changes both the available components and parts of the delivery effort, but it does not fix a poor process, unclear data or missing ownership.

The short answer: Buy capabilities that are common, stable and well served by the market. Build only the smallest layer that creates measurable differentiation, margin, speed or data advantage. If value or user behaviour is still uncertain, run a bounded experiment first. In many situations, a modular hybrid is more economical than pure buy or full custom development.

Data cut-off: 30 June 2026 · Regulatory cut-off: 2 August 2026. All price ranges in this article are transparent t-next planning assumptions for early budget discussions. They are neither market statistics nor a quotation.

The decision in 60 seconds

This map does not replace an evaluation. It tells you where to begin the assessment, rather than which answer a supplier would like to sell.

Off-the-shelf software is therefore a sensible default for commodity capabilities, but not a doctrine. Custom software makes sense when the specific capability is economically important and the organisation can own it over time.

Why the question is different in 2026

Investment cases face greater scrutiny while cloud and AI have become normal parts of the technology landscape. Four current signals matter in particular:

These percentages refer to different populations and definitions. They must not be combined into a synthetic trend line. Their shared implication is narrower: organisations increasingly assemble standard components, while expecting a more specific business contribution and greater control of dependencies.

Seven options, not a binary choice

A credible shortlist starts with more than two supplier proposals.

1. Simplify or remove the process. If a workflow produces no measurable value, software merely digitises the waste.
2. Adopt standard SaaS unchanged. This is a strong starting point for mature, widely shared capabilities such as basic accounting, payroll or collaboration.
3. Configure an off-the-shelf product. Adapt roles, fields and approvals using supported mechanisms without creating a fork that blocks future upgrades.
4. Integrate several standard services. Each product remains responsible for its domain; an integration layer connects data and events.
5. Use low-code or no-code. This can work well for bounded workflows if governance, scaling and exit are designed from the outset.
6. Compose a custom differentiating core. Identity, CRM, payments, hosting or the AI model remain standard; proprietary logic and user experience are custom.
7. Build a complete custom system. This can be justified by high strategic value, weak market fit, rapid domain change or unacceptable vendor dependency.

Where uncertainty is high, add an eighth outcome: experiment. Discovery, a technical spike or a user pilot buys knowledge before the organisation commits to a large architecture and contract.

What does custom software cost in 2026?

There is no credible universal average. An approval tool, customer portal, integration layer and business-critical platform are all custom software, but they are not comparable investments.

External rates provide only a lower-level market anchor. The 2026 studies from freelance.de and freelancermap report mean freelancer rates around €100 per hour. An hourly rate is not a project price. It does not, by itself, include product management, architecture, quality assurance, security, continuity, warranty, adoption or operations.

Indicative planning ranges, not fixed-price packages

For early planning, t-next models a blended external delivery person-day at €950–€1,350. These intentionally broad ranges have to be refined through discovery, a defined system boundary and real project evidence.

These are not packages or quotations. They exclude internal client effort, VAT and, unless explicitly modelled, third-party licences, cloud and model usage. Unusual regulatory, availability, offline, real-time or migration requirements can move an initiative beyond the ranges. The largest cost driver is often not the visible interface, but uncertainty in data, integrations and decisions.

What drives the investment

• data migration and poor data quality,
• the number and reliability of integrations,
• roles, permissions and approval paths,
• security, auditability and regulatory evidence,
• parallel operation or retirement of a legacy system,
• offline, real-time and high-availability requirements,
• AI evaluation and human oversight,
• limited availability of domain decision-makers,
• adoption across many teams, countries or operating units.

Year one is not a fair comparison

Compare realistic options over at least five years:

Off-the-shelf TCO
= licences + implementation + configuration + integration + migration
+ operations + training + process compromises
+ price escalation, switching and exit risk

Custom software TCO
= discovery + delivery + adoption + operations + ongoing development
+ internal security and compliance responsibility
+ technology, team and handover risk

Model a best, base and worst case for every viable option. The most useful question is not which base case looks nicest, but which assumption changes the decision? Common swing factors are user count, licence inflation, rate of business change, internal capacity, transaction volume and exit cost.

Qualitative concerns should not be converted into invented euro values. Keep them visible in the decision scorecard unless the organisation can defend the underlying financial estimate.

How AI changes the decision

AI can accelerate prototypes, boilerplate, test drafts, documentation, refactoring, migration scripts and parts of defect analysis. It is less able to resolve the right problem, conflicting business goals, access to reliable data, integration, adoption, approvals and accountability.

That is why “50% cheaper with AI” is not a credible proposal without a baseline and comparable evidence. The 2025 DORA report describes AI as an amplifier of its surrounding system: respondents perceived substantial productivity gains, but not an automatic gain in quality or stability. A McKinsey survey found workflow redesign to have the strongest association with economic GenAI effects among the attributes studied. This is an association, not proof that a redesign causes higher EBIT.

AI creates new cost categories

• representative evaluation cases and acceptance thresholds,
• model and prompt versioning,
• quality, cost and latency monitoring,
• guardrails, permissions and data filters,
• human review and escalation,
• protection against prompt injection and data leakage,
• provider abstraction, fallback and model switching,
• documentation for data protection and the EU AI Act.

In 2026, the valuable custom layer often lies not in training a foundation model, but in process design, context, data access, evaluation, user experience and controlled integration. For regulatory classification, see our separate guide to the EU AI Act and GDPR.

Which decision models actually help

A generic pros-and-cons list hides trade-offs. A robust assessment combines several perspectives:

These methods are not included for academic decoration. Each prevents a common error: confusing year one with the lifecycle, hiding weights, ignoring lock-in, mistaking internal peculiarity for customer value or scaling an uncertain AI use case too early. Methodological foundations include Williamson’s Transaction Cost Economics, Barney’s Resource-Based View, Cynefin, ISO/IEC 25010:2023 and the Software Engineering Institute’s COTS evaluation process.

The t-next Build–Buy–Compose framework

We combine these perspectives into a decision process that does not automatically arrive at “build” after five leading questions.

1. Put the problem before the software

Which measurable outcome should change? What does the current state cost? Could the process be removed or improved organisationally? Without a baseline and an accountable process owner, there is no defensible software decision yet.

2. Classify uncertainty

• clear: proven process and stable requirements — test standard products first;
• complicated: several plausible solutions — use fit-gap analysis, quality criteria and a pilot;
• complex: value or behaviour emerges only in use — run a small experiment;
• chaotic: acute disruption — stabilise first, transform later.

3. Test strategic specificity

Does the customer experience the capability? Does it demonstrably improve margin, speed, quality or data advantage? Is it hard to copy, or merely unusual because of history? Which components are commodities that should not be built?

4. Create a real option set

Compare process change, SaaS, configuration, integration, low-code, a hybrid and custom development. A supplier proposal is not yet an option: every candidate needs the same system boundary and planning horizon.

5. Apply non-negotiable gates

Reject an option regardless of its total score if critical data cannot be exported, the security or compliance model is not viable, essential requirements depend on uncontrolled workarounds, required availability cannot be achieved, or no one owns the product and its operations.

6. Weight, evidence and calculate

The following weights are a starting point for discussion, not an industry standard:

Score each option from one to five, but record evidence, uncertainty, an owner and the next validation step beside every number. A score without a rationale is just an opinion with a decimal point.

7. Invest in stages

Give discovery, a technical spike, a user pilot, the production core and scaling their own goal, budget cap and evidence required to continue. Stopping then becomes an intended decision rather than a late admission of failure.

The result may be buy, configure, integrate, compose, build, experiment or stop. Compose is often a strong 2026 pattern: commodity components around a small differentiating core.

Three worked examples

1. Expenses and leave approvals

The process is common, stable and rarely differentiating for customers. Mature SaaS products exist. Local variation is often process debt rather than an advantage.

Likely direction: buy or configure. Consider custom software only where the regulatory or technical environment is genuinely unusual.

2. Quotation logic for a specialist manufacturer

Product and operational knowledge directly affect margin, speed and conversion. The ERP remains the system of record but cannot represent the differentiating logic well. AI may extract documents and suggest values, but should not issue an uncontrolled quotation.

Likely direction: compose. Keep ERP, CRM and identity as standard services; build the quotation and workflow core; use an external AI model with evaluation and human approval.

3. AI customer service without a reliable knowledge base

Interest is high, but demand and answer quality are unknown. Knowledge sources contradict one another; incorrect statements and personal data present material risks.

Likely direction: do not commission a large platform yet. Improve knowledge quality, run a bounded assistant pilot and measure answer quality, escalation rate and user acceptance. Then revisit buy, compose or build.

Red flags in software proposals

• a narrow fixed price while the problem, data and integrations remain unknown,
• productivity or AI claims without a baseline and measurement method,
• a polished demo instead of a documented evaluation on representative cases,
• no complete data export or plausible exit route,
• “unlimited customisation” that prevents upgrades,
• no named accountability for operations, security and dependencies,
• unclear rights to data, prompts, evaluation sets and outputs,
• no model-switching, fallback or response to quality deterioration,
• a total score that offsets a single unacceptable risk,
• maintenance priced as an arbitrary percentage without capacity or service levels.

Twelve questions for your buying committee

1. Which measurable outcome should change, and by when?
2. What does the current state cost, including workarounds and legacy systems?
3. Is the capability valuable to customers, or only unusual internally?
4. Which option provides the smallest defensible increment of value?
5. Which data, integrations and migrations determine functional fit?
6. Which requirement is a hard gate and must never be averaged away?
7. What do five-year TCO and the best, base and worst cases look like?
8. Which assumption would change the decision?
9. How completely and quickly can data and processes be migrated?
10. Who owns product, operations, security and compliance after go-live?
11. How will AI quality be evaluated, and who approves consequential outputs?
12. What would it cost to stop or switch supplier after twelve months?

Frequently asked questions

Is off-the-shelf software always cheaper?

It often is in year one, but not necessarily over the lifecycle. Implementation, configuration, integrations, process compromises, licence growth and exit belong in the same comparison as custom delivery and operations.

How much does custom software cost?

There is no meaningful average without a system boundary. For early planning, our ranges begin around €15,000 for a focused discovery and extend from roughly €200,000 for a production-ready business application to seven figures for platforms and regulated, business-critical systems. These are planning assumptions, not fixed prices; data, integration, quality and change requirements determine the actual case.

When does custom software pay back?

When cumulative measurable benefit exceeds the investment and additional lifecycle burden. There is no universal break-even. Process volume, delay and error costs, margin, rate of change and user count usually matter most.

Is an unusual process automatically a reason to build?

No. A process may be unique because it grew historically or is unnecessarily complex. Its difference must create demonstrable value.

Does AI make custom development much cheaper?

AI can accelerate well-bounded implementation work. The complete initiative also contains problem framing, data, integration, evaluation, adoption, governance and operations. A general percentage promise is not credible without comparable internal evidence.

Is low-code an alternative to custom software?

It can be, particularly for bounded departmental workflows and fast learning. Evaluate governance, testing, integration, platform limits, licence development and exit with the same discipline as any other option.

Who owns custom software?

The contract decides. Source code, usage rights, documentation, infrastructure, data, build pipelines and handover obligations should all be explicit. “Built for you” does not automatically mean fully and exclusively assigned to you.

How do we reduce vendor lock-in?

Not through the illusion of complete independence, but through deliberate system boundaries: structured export, documented APIs, replaceable models, standard infrastructure, clear termination and handover terms, and a realistically priced exit option.

Conclusion: buy what is replaceable; build what makes the difference

This is not a contest between technology preferences. It is a portfolio decision for each capability and component. The custom core may be small. Year one is not a fair cost comparison. Under high uncertainty, the ability to learn is worth more than an ambitious fixed-price commitment.

t-next therefore does not begin with a build recommendation. We first establish the outcome, system boundary, options, risks and a realistic budget range — and develop custom software only where it creates defensible value. Learn more about our work in custom software development, AI and LLM applications and legacy modernisation.

Methodology and sources

This guide synthesises official statistics, institutional research, established decision models and supporting market studies. Strong quantitative claims link directly to their source; commercially interested sources serve only as market anchors. Correlation is not presented as causation. The t-next cost ranges and scorecard weights are disclosed planning assumptions and will be calibrated as our own project evidence grows. Regulatory notes are not legal advice; each use case requires its own assessment.