Analysis · AI for Business
When all-in-one software becomes a tax on your operation
Portuguese SMEs are paying for software they do not use. The all-in-one suite was sold as the safe choice: one vendor, one contract, every module included. In practice, most companies activate a fraction of the licences, route the real work through spreadsheets and messaging apps, and renew the contract because leaving feels riskier than staying. The question is not whether the software is good. It is whether the software still matches the operation, and what the honest cost of the mismatch is.
Key takeaways
- Almost a third of large EU companies were using AI by 2023, according to Eurostat data cited by Compete 2030, but adoption does not mean the software is the right size.
- The clearest signal that a suite has failed is the growth of parallel spreadsheets and manual exports that hold critical data outside the system.
- A daily exception is not an exception: it is a business rule the current software cannot represent, as Devio's analysis of shelf software limits argues.
- Integration is usually the first step; replacement only pays when subscription plus manual work exceeds a one-off build, with break-even around ten months in one vendor's model.
- Compete 2030 notes that virtual factory technologies are not all-or-nothing, a principle that applies equally to CRM, helpdesk and ERP decisions.
The real cost of an all-in-one suite is not the invoice
The invoice is the smallest part of the problem. A company paying for a CRM, helpdesk and ERP suite is also paying for the work that happens around the suite: the exports to Excel, the copy-paste between systems, the approvals that run through WhatsApp because the workflow module was never configured. Devio's analysis of shelf software makes the point directly: when a commercial team logs opportunities in the CRM, calculates proposals in spreadsheets and requests approval in a messaging channel, the CRM remains active but no longer represents the real commercial operation. The licence is paid, the data is elsewhere, and leadership loses visibility over margin, response time and reasons for lost deals.
This is the hidden cost structure. The subscription is visible and predictable. The retrabalho is invisible and compounding. Every manual export is a small tax on the operation, and the tax grows as volume grows. Jestor's 2025 integration guide describes the same dynamic from the operations side: the main pain is no longer lack of technology but lack of integration between technologies that already exist, producing duplicated information, imprecise reports and rework. The suite was supposed to prevent this. Instead it has become one more silo among many.
The honest calculation therefore has three lines. First, the subscription cost of licences actually in use versus licences paid. Second, the hours spent moving data between the suite and the tools where work actually happens. Third, the cost of decisions made on stale or incomplete information because the system no longer reflects the operation. Only the first line appears on the invoice. The other two appear on the payroll and in the margin.
When the exception becomes the rule
The clearest signal that a suite has outlived its usefulness is not a complaint from a user. It is the repetition of exceptions. Devio puts it sharply: if the same exception needs to be handled every day, it is not an exception. It is a business rule that the current system cannot represent adequately. A pricing rule that lives in a spreadsheet because the ERP cannot model it. A customer history that lives in a support agent's head because the helpdesk cannot surface it. A commercial approval that runs through messages because the CRM workflow does not match how the company actually sells.
These repeated exceptions are the operation telling you something. The software was built for a generic version of your business, and your business has outgrown the generic version. The response is not to add another module. It is to ask whether the gap is in a configuration you have not done, an integration you have not built, or a capability that needs to be constructed from scratch. Those are three different problems with three different costs, and treating them as the same problem is how companies end up paying for customisations that make the next vendor update more expensive.
The test is simple. List every place where work leaves the suite to happen somewhere else. If the list is short and the exits are occasional, the suite is fine. If the list is long and the exits are daily, the suite is a shell. The operation has already built its own system out of spreadsheets and messages. The question is only whether you formalise it or keep pretending the licence is the system.
Adoption is not the same as fit
It is tempting to read adoption statistics as proof that the suite approach is working. Compete 2030, citing Eurostat, reports that almost a third of large EU companies were using AI by 2023, and that the trend is expected to continue as AI becomes more accessible and its use cases expand. That is real adoption. But adoption measures whether companies have bought or deployed technology, not whether the technology matches the operation. A company can be counted as an AI user while its commercial team still runs proposals through spreadsheets.
The same source makes a more useful point for SMEs. Compete 2030 notes that virtual factory technologies are not all-or-nothing: manufacturers can adopt parts to improve processes without committing to the whole. This is the principle that should govern CRM, helpdesk and ERP decisions. You do not need to replace the entire suite. You need to identify which parts of the operation deserve differentiated technology and which parts can stay on the shelf software. The all-or-nothing framing is a sales artefact, not an operational requirement.
For micro, small and medium enterprises, the same Compete 2030 piece points out that machine learning models improve over time with new data, reducing re-equipping costs and eliminating the need for extensive worker retraining. The implication for software is direct: a lean architecture built around your actual processes gets better as your data grows, while a bloated suite gets more expensive as your exceptions grow. The direction of improvement matters.
Integration first, replacement second
The default answer to software bloat is not to rip everything out. It is to integrate what you have and replace only what integration cannot fix. Powertrend's framework is explicit: integrating is usually the first step, and replacement only pays when the subscription plus manual work exceeds the one-off investment. Their model puts the break-even for replacement at around ten months, with first functional delivery in roughly thirty days and initial flows running within fifteen to thirty days. Those are vendor figures and should be read as directional, not as a promise. But the sequence is sound: connect first, then decide what deserves to be rebuilt.
The logic behind this sequence is that integration is cheaper and faster than replacement, and it preserves the parts of the suite that still work. Hablla's analysis of integrated CRM versus separate tools makes the same point from the other direction: in a fragmented structure, each tool can be excellent in isolation, but the company depends on integrations, manual processes and constant alignment to keep everything working. The cost of fragmentation is not in the tools. It is in the connective tissue that the company has to build and maintain itself.
Where integration stops being enough is when the suite itself is the bottleneck. Devio identifies the rupture point: when the company has to adapt strategic processes to fit the tool, rather than the tool adapting to the company. That is common in operations with specific commercial rules, complex logistics, dynamic pricing, regulatory approval or context-dependent service. In those cases, standardisation stops generating efficiency and starts reducing response capacity. The integration layer can move data around, but it cannot change what the suite fundamentally cannot represent.
What a lean architecture actually looks like
A lean architecture is not a smaller version of the suite. It is a different shape. Instead of one vendor owning every module, the company owns a small set of automations and integrations that connect the tools where work actually happens. Jestor's 2025 guide describes the pattern: platforms that connect ERP, CRM and operations in real time, allowing custom dashboards and automations without code, integrated with systems like Oracle, Salesforce, Omie and Conta Azul. The point is not the specific vendor. The point is that the architecture is built around the company's data flows, not around a vendor's module list.
The European Commission's guidance on third-party e-commerce platforms, published on Your Europe, reinforces the same principle from a different angle. When choosing a platform, the Commission advises looking for multiple integrations with software and marketing tools you already use or may add in the future. The official guidance treats integration capacity as a core selection criterion, not an afterthought. A suite that cannot connect to your existing tools is a suite that will force you to work around it, and the workaround is where the hidden cost lives.
The lean architecture also changes who controls the system. Powertrend's replacement path is explicit on this: in the replace scenario, the code and data are entirely yours, and the process is designed from scratch for your way of working. That is not always the right choice. It carries real cost and real risk. But for companies whose differentiation lives in their process, not in their product, owning the process layer is the difference between competing on execution and competing on how well you configure someone else's software.
The counter-case: when the suite is still the right answer
The steelman for the all-in-one suite is not weak. Shelf software exists because many companies share similar needs, and the advantages are real: faster implementation, predictable initial costs, and maintenance handled by the vendor. Devio acknowledges this directly: many companies grow supported by shelf software, and the decision to replace requires more rigour than comparing features or monthly fees. A shelf system can remain the correct choice even with some limitations.
Hablla's analysis adds the operational case for centralisation: in an integrated environment, communication, lead management, relationship history, automations and funnel visibility coexist in the same operation, reducing friction and letting the team respond with more context. For a company with simple processes, low contact volume and few channels, separate tools or a single suite can both work, and the suite has the advantage of one contract and one support line. The failure mode is not the suite itself. It is the suite applied to an operation that has outgrown it, or the suite bought at a scale the company never reached.
The honest position is that the suite is a stage, not a destination. It is the right choice for a company whose processes are still generic enough to fit the vendor's model. It becomes the wrong choice when the company's differentiation starts to live outside the model. The skill is not in choosing one side permanently. It is in knowing which stage you are at, and being willing to move when the evidence says the stage has changed.
How to run the calculation
The decision to integrate, evolve or replace should be a calculation, not a feeling. Start with the three cost lines: subscription cost of licences actually used versus paid, hours spent moving data between systems, and the cost of decisions made on stale information. Powertrend's framework offers a useful comparison across three paths: integrating reduces rework and avoids a large one-off project; integrating plus evolving cuts manual hours with returns in weeks; replacing eliminates the monthly subscription after break-even, which they estimate at around ten months. The table below lays out the three paths side by side.
The second step is to map where work actually happens. List every process that leaves the suite to run through spreadsheets, messages or manual exports. For each one, ask whether the gap is a configuration you have not done, an integration you have not built, or a capability the suite fundamentally lacks. Devio's rupture point is the test: if the same exception repeats daily, it is a business rule without representation in the system. That is the signal that configuration and integration have reached their limit.
The third step is to sequence the work. Integration first, because it is cheaper and preserves what works. Evolution second, where automations and AI agents take over the manual connective tissue. Replacement last, and only where the suite itself is the bottleneck. Compete 2030's observation that virtual technologies are not all-or-nothing applies here: you can adopt parts to improve processes without committing to the whole. The goal is not to win an argument about software philosophy. It is to stop paying for licences you do not use and stop losing margin to workarounds you never budgeted for.
Different perspectives
The optimistic case is that lean automations are now cheap enough and fast enough to beat the suite on both cost and fit. Compete 2030, citing Eurostat, shows AI adoption already reaching nearly a third of large EU companies by 2023, and the trend is toward accessibility. As the tools get cheaper and easier to connect, the advantage of the all-in-one suite shrinks. A company can now assemble a CRM, helpdesk and ERP layer from specialised tools and automations, connected around its actual processes, for less than the cost of the unused modules in a suite contract. The optimistic view is that this is a one-way shift: integration platforms and AI agents keep improving, while suite vendors keep charging for modules their customers do not activate. The gap between what you pay and what you use will only widen, and the companies that build lean now will be the ones with the data and the process control to compete later.
The sceptical case is that lean architectures simply move the cost from the licence to the payroll. A suite has one vendor, one support line and one upgrade path. A lean architecture built from integrations and automations has many moving parts, and someone has to maintain them. Hablla's analysis is honest about this: in a fragmented structure, the company depends on integrations, manual processes and constant alignment to keep everything working. That dependency does not disappear when you replace the suite with automations. It becomes your problem instead of the vendor's. The sceptical view also questions the break-even figures. Powertrend's ten-month break-even is a vendor estimate, and vendor estimates assume the build goes smoothly, the team adopts the new system, and the automations do not need constant adjustment. In practice, replacement projects run late, and the old suite keeps getting paid while the new system is not yet live. For a small team with no technical staff, the suite's predictability may be worth more than the lean architecture's theoretical savings.
Comparison
Three paths for bloated software
| Integrate | Integrate and evolve | Replace | |
|---|---|---|---|
| Financial impact | Reduces rework; avoids a large one-off project | Cuts manual hours; returns in weeks | Eliminates subscription after break-even, around ten months |
| Information flow | Same data visible in one flow | WhatsApp, sales and finance connected | Process designed from scratch for your way of working |
| Time to value | First flows in 15 to 30 days | AI agent responds 24 hours without human cover | First functional delivery in around 30 days |
| Control | You choose what to connect first | Evolves without external support dependency | Code and data entirely yours |
Our view
We have seen this pattern repeatedly in Portuguese SMEs, and we built A Batina as the proof. A 32-year-old family business was running its shop on a patchwork of systems: one for the point of sale, one for the online store, one for stock, and a set of spreadsheets holding the numbers that actually mattered. The suite approach had failed them, not because the software was bad, but because no single vendor's model matched how a traditional Portuguese retailer actually operates. We built one system across POS, online store and stock, with invoicing automated and the data feeding sharper marketing decisions. The result was not a smaller version of the old suite. It was a different shape, built around the operation instead of around a vendor's module list. The principle we apply to every client is the same: cut the busywork, build the system, keep the growth.
What to do
- List every process that leaves your current suite to run through spreadsheets, messages or manual exports, and mark each one as daily or occasional.
- For each daily exit, classify the gap as a configuration you have not done, an integration you have not built, or a capability the suite fundamentally lacks.
- Calculate the three cost lines: subscription for licences actually used versus paid, hours spent moving data between systems, and the cost of decisions made on stale information.
- Sequence the work: integrate what you have first, add automations where manual connective tissue is expensive, and replace only where the suite itself is the bottleneck.