When a company compares several solutions, the amount of the initial project naturally occupies the center of the discussion. However, an application is not purchased only once. It must be hosted, monitored, secured, updated, adapted to usage, and sometimes transferred to another team.
The total cost of ownership, or TCO, allows for comparing options over a consistent period. It is not meant to predict every expense down to the last euro. It makes assumptions visible, prevents omissions, and reveals the items that will cause the budget to vary.
Why the initial quote is not enough
Two proposals can show a similar price while covering very different scopes. One includes scoping, testing, migration, and operations. The other assumes that these tasks will be handled by the client or billed later.
Conversely, a low-cost solution at the start may come with increasing licenses, customization limitations, or a high exit cost. A custom application usually requires more initial investment but can offer better control over data, integrations, and evolution.
The TCO therefore requires comparing equivalent services and separating certain costs, probable costs, and risk.
The twelve positions to fill
1. Framing and design
This phase transforms a need into an achievable scope. It includes workshops, journeys, business rules, priorities, architecture, risks, and acceptance criteria. Artificially reducing it shifts the cost towards corrections and late compromises.
2. UX, design and integration
You have to account for the design of interfaces, error states, responsiveness, accessibility, the component system, and integration. A nominal screen represents only a part of the work: permissions, absent data, loading, and exceptions must also be designed.
3. Development and configuration
The cost depends on the number of business capabilities, the complexity of the rules, the integrations, the expected quality, and the non-functional constraints. The choice between configuring an existing product and custom development strongly influences this item.
4. Data and migration
Importing data is not about copying rows. You need to analyze the sources, clean, match the identifiers, manage attachments, preserve the history, test integrity, and organize the migration. The older and more heterogeneous the data, the more important the preparation is.
5. Testing and acceptance
Unit, integration, security, performance, and end-to-end tests reduce the cost of regressions. Business acceptance testing requires data sets, scenarios, available users, and tracking of anomalies. This work exists even when it is not visible in a line item of a quote.
6. Production deployment and change management
Environments, domains, certificates, deployment, training, documentation, launch support, and rollback plan are part of the delivered product. A gradual commissioning may require temporary coexistence with the old system.
7. Accommodation and technical services
Servers, databases, storage, backups, network, CDN, emails, search, observability, and non-productive environments constitute the recurring foundation. The cost must be related to volumes and availability commitments, not chosen at random.
8. Licenses and usage-based pricing
SaaS, low-code, and API solutions often charge per user, transaction, document, storage, or call. It is necessary to simulate growth and plausible changes in the pricing grid. Open source components reduce licenses but do not eliminate integration and operation.
9. Corrective maintenance
A live application encounters anomalies related to code, browsers, third-party systems, or data. The budget depends on criticality, service level, and initial quality. A launch guarantee does not replace long-term maintenance.
10. Security and updates
Systems, frameworks, and libraries evolve. Vulnerabilities must be monitored, patches applied, certificates renewed, access reviewed, and upgrades tested. Postponing this work creates a higher and less predictable expense.
11. Product developments
Users, regulations, and processes change. An application without an evolution budget functionally deteriorates even if it remains available. TCO must distinguish between maintenance and the creation of new value.
12. Reversibility and cost of risk
Changing providers, exporting data, or replacing a component may require documentation, transfer, migration, and dual operation. It is also necessary to estimate the impact of interruptions, data errors, and critical dependencies.
The diagram presents four complementary layers. The initial construction includes framing, design, development, migration, and launch. Recurring operations cover licenses, hosting, support, maintenance, and security. Product evolution finances adaptations and new functions. Risk and reversibility make the potential impact of interruptions and the cost of an exit visible. The following table provides an equivalent textual representation.
| Component | Nature | Representative positions | Temporality |
|---|---|---|---|
| Initial construction | Initial investment | framing, UX, development, migration, testing, training, go-live | launch |
| Recurring operations | Operation | licenses, hosting, support, maintenance, security, updates, tooling | every year |
| Product evolution | Value creation | improvements, new features, adaptation to usage and regulations | planned in the lifecycle |
| Risk and reversibility | Distinct exposure | interruption, data loss, transfer, exit migration, dual operation | probable or conditional |
Build three comparable scenarios
A useful comparison can consider three categories:
- a standard SaaS solution, quickly available but limited by its model; - a highly configured low-code platform or CMS; - a custom application built on open technologies.
For each scenario, use the same timeframe, the same number of users, the same security requirements, the same level of support, and the same volumes. Document the uncovered functions: a low price is not comparable if part of the process remains manual.
Working with forks
Precise estimates give a false impression of certainty. For uncertain items, use a low, central, and high assumption. The differences between scenarios then become more informative than the single total.
Sensitivity shows which assumptions drive the result. If the ranking depends almost entirely on the number of users, negotiating the license or reviewing the access model will be more valuable than optimizing a few days of development.
Integrate the value, not just the cost
The cheapest scenario is not automatically the best. A solution can reduce processing time, limit errors, enable a new service, or prevent a critical interruption. These benefits must be measured separately to calculate a return on investment.
We can track: hours saved, new revenue, conversion rate, error reduction, time to market, user satisfaction, and risk avoided. Benefits must be attributable and tracked after launch.
Example of reasoning over five years
Let's imagine a business portal with multiple profiles, validation rules, documents, and integrations. The SaaS offers a quick start, but charges for each user and requires workarounds. The low-code covers workflows but requires extensions. The custom-made solution requires more design, then allows concentrating costs on useful functions.
The first year can favor SaaS. As the number of users, integrations, and specific requests increase, the curves come closer together or intersect. The result depends less on a general truth than on documented assumptions.
Common mistakes in an application budget
The first is to forget the time of internal teams: workshops, testing, data cleaning, training, and support. The second is to count maintenance only in case of an incident, while preventive updates are essential. The third is to ignore the development and testing environments.
It is also necessary to avoid treating technical debt as an unpredictable item. A recurring budget for modernization and upgrades is more economical than an emergency migration every five years.
Use TCO as a management tool
The model must not disappear after signing. Each year, replace the assumptions with the actual expenses, update the volumes, and reassess the risks. The gaps explain the decisions to be made: optimize an infrastructure, renegotiate a service, automate an operation, or strengthen the testing.
This transparency also makes the relationship with the service provider easier. The parties distinguish the cost of the base, operations, and developments, instead of mixing all the requests into a package that is difficult to understand.
A decision based on the life cycle
A custom application can be the best investment when the process is differentiating, complex, durable, and highly integrated. It can be excessive for a standard or temporary need. The five-year TCO allows this decision to be made without ideology.
Partitech supports companies from framing to operation. We can challenge assumptions, compare architectures, and build a budget that includes quality, maintenance, security, and reversibility from the outset.
To go deeper into the comparison, find out how to choose between SaaS, low-code, open source, or custom and frame the maintenance and service commitments. See all the Partitech services and our reference for financial business software.
Official reference
Reference checked on August 17, 2026: