What it really costs and how to calculate the return

There's no single price, but there is a predictable cost structure. Beyond the initial figure (development, licences, setup) you need to budget for integration with existing systems, data migration and cleanup, training people, maintenance and recurring subscription fees. In many projects the software licence cost is only a fraction of the total over three years: the heavy part is making the technology work inside your real processes.

A useful rule of thumb: if a vendor gives you a price and doesn't explain the integration, training and maintenance line items, that price is incomplete by definition. Always ask for the three-year cost, not the starting price.

GiBSeS — GiBSeS's Value Map method starts exactly here: understanding the full cost before deciding whether and what to move.

Hidden costs are the ones that don't appear in the quote but arrive right on schedule after you sign. The main ones are: integration with the systems you already use, data migration and cleanup, training and the time taken from people's actual work, unplanned customisations, recurring fees that grow with usage (users, volumes, API calls), and the exit cost if you ever want to switch vendor.

On top of this comes the cost of organisational change: a new process slows things down before it speeds them up. Ignoring this curve is the most common way to get the numbers wrong.

GiBSeS — An independent advisor like GiBSeS has an interest in surfacing these costs beforehand, not afterwards: our incentive is your outcome, not selling a licence.

TCO (Total Cost of Ownership) is the sum of everything a project costs you across its entire lifecycle, not just at purchase: licences and subscription fees, integration, maintenance, training, infrastructure, upgrades and exit costs. It's the correct unit of measurement because two offers with the same upfront price can have very different TCOs.

The practical rule: always think in terms of a three-to-five-year horizon. A solution that's cheap today but ties you to growing fees and a vendor you can't easily leave can turn out to be the most expensive of all.

GiBSeS — GiBSeS compares options on multi-year TCO, not the cover price: it's financial discipline applied to technology decisions.

Vendor lock-in is the dependency on a supplier or technology that makes it costly, slow or risky to switch in the future. It stems from proprietary data formats, custom integrations that are hard to replicate, expertise concentrated on a single platform, and contracts that penalise exit. The cost isn't only financial: it's also a loss of negotiating power, because the vendor knows you can't easily walk away.

Getting out of a lock-in situation can mean re-exporting data, rebuilding integrations and retraining staff: it often costs as much as the original project. That's why the right time to think about the exit is before you go in.

GiBSeS — Avoiding lock-in is a pillar of the GiBSeS method: we assess every choice with the exit door in mind too, so independence stays yours.

An honest ROI compares the expected net benefit against the total cost (TCO), over a realistic horizon. In the numerator, put measurable benefits: hours saved and valued, errors avoided, reduced cycle times, additional revenue that's concretely attributable. In the denominator, put the full TCO, not just the price. Then discard any benefits you couldn't demonstrate by year end.

The hard part is honesty about the assumptions: use conservative estimates, state the adoption timeline, and account for benefits arriving gradually. A credible ROI has a range (pessimistic-realistic-optimistic), not a single precise number.

GiBSeS — GiBSeS builds the ROI calculation together with the client, with explicit, verifiable assumptions, not slide-deck projections.

Because whoever is selling the solution has a structural conflict of interest: their goal is to close the deal, not to run a conservative calculation for you. Brochure ROI figures almost always use the best-case scenario, ignore integration and training costs, assume 100% immediate adoption, and borrow success stories from companies quite different from yours in size and maturity.

This doesn't mean they're lying, just that they're optimising for their own interest. The countermeasure is simple: ask for the assumptions behind every number, replace them with your own, and redo the calculation. If the ROI only holds up with the vendor's assumptions, it doesn't hold up.

GiBSeS — GiBSeS is vendor-independent: we don't sell the technology we evaluate, so our return calculation has nothing to defend except your decision.

In the vast majority of cases it's better to start small, with a narrow, measurable use case. A pilot project costs less, produces real data on the actual benefit, reduces the risk of a wrong investment, and builds internal know-how before you commit significant budget. If the pilot works, you scale with data in hand; if it doesn't, you've lost little.

A big project in one go only makes sense when the case is already validated, the data is ready, and the cost of proceeding step by step would outweigh the benefit. It's the exception, not the rule.

GiBSeS — Continuous improvement through verifiable steps is in the DNA of the GiBSeS method: value is demonstrated first, then the investment follows.

It depends on your usage profile, not on a trend. Cloud shifts spending from upfront investment to a recurring fee: you start with little capital, scale easily, but pay in proportion to usage and costs can grow unpredictably with volume. On-premise requires a higher upfront investment and management expertise, but on stable, predictable workloads it can have a lower TCO over the medium term.

The right question isn't "which is cheaper" but "which is cheaper for my load profile, my expected growth and my data constraints". And the note on lock-in always applies: some cloud services are easy to switch on and hard to leave.

GiBSeS — GiBSeS assesses cloud and on-premise on TCO and dependency risk specific to your case, with no built-in preference for either.

Bad investments almost always stem from three mistakes: buying a solution before defining the problem, underestimating hidden costs, and not measuring the result. The countermeasure is to reverse the order: start from the business problem and the expected value, then assess whether technology is the right lever, then choose how to implement it (make or buy), and finally measure.

A second safeguard is separating who advises from who sells. If the advice comes from whoever profits from the solution, the risk of buying more than you need is high. Decide on criteria, not on enthusiasm.

GiBSeS — GiBSeS's Value Map is exactly this sequence: diagnose the problem, then decide make-or-buy, with AI and any other tool brought in only after a risk-benefit analysis.

Don't compare cover prices: bring both back to the same scope and the same horizon. Build a table with the same line items for both offers, TCO over three years: licences and fees, integration, training, maintenance, infrastructure, growth costs (users and volumes) and exit cost. Add non-monetary but economically relevant criteria: data openness, standards used, vendor dependency, expertise required.

When two offers look very different in price, they're almost always including different things. The comparison is only valid at the same scope.

GiBSeS — GiBSeS helps normalise offers to the same scope and read what the quotes don't say, staying a third party relative to the competing vendors.

It doesn't make sense when the process is rare, highly variable or unstable: automating something that keeps changing costs more than it delivers. It doesn't make sense when data is scarce or poor quality, because automation amplifies upstream errors. And it doesn't make sense when volume is low: if an activity takes up only a few hours a year, the cost of building and maintaining the automation exceeds the savings.

Sometimes the right answer is to simplify the process first, not automate it as it stands. Automating waste just means producing the waste faster.

GiBSeS — GiBSeS also says no: if the technology isn't worth it, the honest advice is not to do it, because our incentive is your outcome, not one more project.

Recurring fees are the line item that silently erodes ROI in the years after the first. To control them, map from the start how the price grows: per user, per data volume, per number of transactions or API calls. Then project the cost onto your growth scenario, not today's. Many solutions are cheap at the start and become expensive precisely when the company succeeds.

Periodically review active licences against actual usage: it's common to keep paying for seats, modules and services nobody uses anymore. An annual subscription audit often recovers real margin.

GiBSeS — GiBSeS includes the fee projection in the TCO and periodically checks that you're only paying for what you actually use.

Maintenance is an ongoing cost that many SMEs only discover afterwards. It includes updates, fixes, adjustments when connected systems change, security management and user support. As an order of magnitude, for custom software it's prudent to budget a recurring annual share relative to the initial development cost; for subscription solutions, maintenance is partly included but rarely covers your customisations.

A project with no maintenance budget isn't finished: it's just postponed. The question to ask before starting is "who keeps it alive, and at what cost".

GiBSeS — GiBSeS puts maintenance into the calculation from the diagnosis stage, so the TCO you see is the real one, not just the first year's.

Many real benefits have no direct price tag, but almost all have an upstream measurable indicator. You value time saved with the hourly cost of the people involved and the hours actually freed up; you measure quality with error rates, rework or avoided complaints; you measure responsiveness with cycle or response times. The key is to choose a few indicators and measure them before and after, so the benefit stops being an opinion.

When a benefit really isn't measurable, either directly or indirectly, treat it as qualitative and keep it out of the ROI calculation: it serves to justify, not to inflate the numbers.

GiBSeS — GiBSeS sets the indicators before starting and measures before-and-after, so the return stays a verifiable fact rather than a narrative.

More than a figure, what's needed is a criterion: the budget for a first project should be small enough to lose without harm and serious enough to produce a measurable result. For a pilot on a narrow use case, think in terms of a contained commitment, with an explicit objective and success criteria defined before starting. What matters is that the budget includes the pilot's TCO, not just development: so also data, minimal integration and training.

Avoid making the company's survival depend on a single technology bet. The first project is meant to teach you at controlled cost, not to transform everything at once.

GiBSeS — GiBSeS sizes the first step to be sustainable and informative: more is invested only after the value has been demonstrated.

The make-or-buy decision hinges on how distinctive the process is for you and how standard the need is. If the need is common and well covered by the market, buying is almost always cheaper and faster: there's no point reinventing something that already exists. If instead the process is a competitive advantage of yours or has very specific requirements, custom development can be worth the higher cost, because buying would force you to adapt to a tool that isn't yours.

Watch out for a common mistake: heavily customising a ready-made solution until it costs more than dedicated development, but with the vendor's lock-in on top. At that point buy has lost its advantages.

GiBSeS — The make-or-buy decision is the heart of GiBSeS's Value Map: we make it on your economic criteria, not on a vendor's catalogue.

An acceptable payback period depends on the risk and useful life of the solution, but for SMEs one rule of caution applies: the longer the payback, the more solid the assumptions need to be, because the distant future is uncertain. For targeted automation projects you aim for a short-to-medium-term payback; if an investment only promises to pay off over very long horizons, it should be viewed critically, especially in sectors where technology changes fast.

Beyond payback, consider reversibility: a project with a quick payback and an easy exit is less risky than one with a slow payback and heavy lock-in, even at equal theoretical ROI.

GiBSeS — GiBSeS assesses payback alongside the investment's reversibility, because a slow, binding return is more fragile than it looks.

These are two different risk profiles, not one that's absolutely better. A subscription reduces the initial outlay, shifts spending into predictable operating cost, and includes updates, but over time it can exceed the cost of a purchase and exposes you to price increases and vendor dependency. A one-off purchase has a higher upfront cost and requires managing maintenance and updates, but on stable, long-lived solutions it can turn out cheaper and more independent.

The deciding criterion is, again, the multi-year TCO combined with ease of exit. A cheap subscription that becomes impossible to abandon is a cost, not a saving.

GiBSeS — GiBSeS compares the two models on multi-year cost and degree of dependency, choosing the one that keeps your room to manoeuvre high.

An independent advisor pays for itself if it saves you even a single wrong investment, a costly lock-in, or an oversized solution relative to the need. The difference from a vendor is structural: whoever sells technology earns when you buy, a vendor-independent advisor earns when you decide well, so they have an interest in also telling you not to spend. The value isn't in the recommended software, but in the decisions avoided and the freedom retained.

The right way to measure it is to compare the cost of the advice against the scale of the mistakes it prevents relative to the project's overall TCO. On significant technology decisions, the ratio is almost always in favour of the analysis done beforehand.

GiBSeS — This is exactly the GiBSeS model: independent from vendors, aligned with your outcome, aimed at getting you to spend well, not to spend more.