The decision between building custom software, buying a standard solution, or integrating what you already have isn't resolved by comparing features or prices: it's resolved by identifying which part of your operation is truly different from your competitors'. What differentiates you is built. What doesn't differentiate you is bought. And what already works is integrated instead of replaced.
The most costly mistake isn't choosing the wrong option among the three. It's not realizing that the third one exists.
Because they arrive at the committee framed as a choice between two products, when in reality they are a question about the company's operating model.
When an operations manager says, «We need a CRM,» they’ve already implicitly made three decisions: that the problem is with the tool, that the tool must be new, and that the correct category is CRM. All three could be wrong. The problem might be that customer information lives in four different places; the tool might already exist and be underutilized; and the category might actually be an integration problem between the ERP and the billing system.
There is market data that supports this. In August 2026, Reuters analyzed why established European companies—SAP, Capgemini, Sopra Steria, OVHcloud—have emerged as unexpected winners in the AI cycle: the challenge for businesses is no longer choosing the best model, but making it work with the software, data, and processes they already have. The value has shifted from acquisition to integration.
|
Ask |
If the answer is yes |
If the answer is no |
|
Is this process a competitive advantage or just a requirement for operating? |
Custom build |
Buy standard |
|
Is there a standard solution that covers 80% without forcing your process? |
Buy and integrate |
Build or integrate what already exists |
|
Do the systems you already have cover the function but not communicate with each other? |
Integrate |
Evaluate build or buy |
The first question is the one that is skipped the most. A consultancy firm doesn't need custom accounting software: accounting is a regulated and identical requirement for everyone. But a shipping company might need a custom CRM, because shipping operations—routes, customs documentation, port calls, incidents—don't exist in any CRM on the market. That's precisely why we built NaviCRM instead of configuring a standard product, and why the result was a 60% reduction in management time: there was no configurable version of that process.
The second question has a common trap. The "80% covered" is measured in features during the demo, but is paid for in the remaining 20% over the following three years. That 20% is where your competitive advantage lies, and it's precisely what the standard tool will force you to abandon or solve with parallel development, fragile integrations, and spreadsheets. Before accepting an 80%, it's wise to identify exactly what's included in the 20%.
The third question is the one that saves the most money and the one that is asked the least. In many companies, the functionality already exists, distributed across systems that don't share information. The right project isn't to buy another system; it's to build the integration layer that makes the existing systems work as one. It costs a fraction of the cost, doesn't require massive data migration, and doesn't require retraining anyone.
Buying standard is the right decision more often than a development company would like to admit. These are the clear signs:
If all four conditions are met, custom building almost always destroys value.
This last point is the most underestimated. Buying software means delegating the pace of evolution of a part of your business to the commercial priorities of another company.
Integration is the least flashy of the three options and the one that yields the highest return per euro invested, precisely because it doesn't require replacing anything that already works. We've discussed this in more detail in our analysis of ERP, CRM and AI as a new business architecture
In none of the three columns, and that's the answer you should internalize. AI isn't a fourth option: it's a capability that can be added to any of the three.
In June 2025, Gartner published a forecast that should be considered in any purchasing process: more than 40% agentic AI projects will be canceled before the end of 2027 due to rising costs, unclear business value, or inadequate risk controls. In the same analysis, Gartner estimated that of the thousands of vendors presenting themselves as agent specialists, only about 130 truly are. They called this phenomenon "agent washing.".
The practical implication for a purchasing committee is straightforward: when a proposal is presented as an "AI solution," it must be brought back to the original question. What process does it solve? Is it a differentiated or standard process? Does the required data exist and is it reliable? Who is responsible when it makes a mistake?
If you can't answer those four questions, you're not evaluating a solution. You're evaluating a demo.
The structural problem with these decisions is that the information is provided by the candidates themselves. Each supplier defines the problem in terms of how their product is the solution.
A clean process has four steps:
When we participate in these processes, we do so as an independent party: we draft the RFP, evaluate the bids, and negotiate the contract based on technical criteria, without presenting ourselves as candidates for the tender we are evaluating. This is the only way the board can treat the recommendation as a criterion and not as a disguised commercial proposal.
Before making your next software purchase decision, it's worth answering one question: Is this capability a reason why a customer chooses us, or simply something we need to operate?
The former is built and owned. The latter is bought and integrated. Confusing the two categories is the origin of most software projects that cost twice as much and are half as useful.
When the process is a real competitive advantage, when no market solution covers it without forcing you to change the way you work that makes you competitive, when the cost of licenses per user grows with the workforce, or when you need ownership of the code and data for compliance or valuation.
It involves connecting the systems you already have instead of replacing them. It's often overlooked because no software vendor offers it: there are no licenses to sell. It's usually the option with the highest return on investment when the data already exists within the organization but is scattered.
Evaluating the 20% that it doesn't cover, not the 80% that it does. All mature tools cover the core functionality; the difference lies in the edges, and those edges usually coincide with what differentiates your company. That 20% is paid for over the following years in parallel development and spreadsheets.
The standard solution has a lower initial cost and a recurring cost per user that grows with the workforce; custom development has a higher initial cost and no per-user licenses. The break-even point depends on the number of users, the expected lifespan, and how much parallel development the standard solution would require.
Defining the process and weighted evaluation criteria before viewing the first demo, and incorporating an independent technical component that is not competing in the bidding process. If the criteria are written after the demos, they are written to justify a pre-existing preference.
In none of the three cases: AI is a capability that can be added to any of the options, not a fourth alternative. When faced with a proposal presented as an "AI solution," it's best to return to the original questions: what process does it solve, is that process differentiating, does the data exist, and who is responsible for errors?.
|
Do you have a software purchase decision on the table? We can draft the RFP, evaluate the bids, and negotiate the contract with independent technical expertise—without presenting ourselves as candidates. Two hours of analysis of your case, no obligation. Let's talk → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
