The run-rate, not the project price: what software really costs over five years

Put two amounts side by side. One is set in bold under a quote: the price of the build, one-off, paid in the first year. The other appears nowhere on a single line, and yet it comes back every month for as long as the system runs. Executives sign off on the first amount and live with the second for years. That is the wrong order.

The amount that counts is called the run-rate: the fixed burden that returns every month until someone switches the system off. With software you rent per user, that burden grows along with your headcount. Hire ten people and the bill rises, whether those ten open the more expensive modules or not. The spend is tied to your size, not to what the software delivers for you. And size is exactly what a growing company has more of every year.

What per-user really costs over five years

Take a concrete rate. Microsoft charges 210 dollars per user per month for Dynamics 365 Finance, and 300 dollars for the Finance Premium variant. Put fifty people on it: 210 dollars, times fifty, times twelve months, and you land at 126,000 dollars a year, before a single euro of implementation is added. And the implementation itself typically runs from 250,000 to more than 1.5 million dollars. So that monthly amount is not the start of the bill. It is the part that never stops.

Stretch that over sixty months and the picture tips. Fifty users at 210 dollars is 630,000 dollars in licences over five years, without implementation, without indexation, without the new people you hire in the meantime. Every head that joins ticks its own monthly rate onto the meter. The one-off build price you found so high becomes, on that timeline, one of the smaller items.

The leak that is not yet in the sum

And then you also pay for seats that sit empty. The Flexera 2024 State of ITAM report calculates that organisations waste 20% to 30% of their IT spending, and that more than half of SaaS licences go unused. In a per-user model that is not an edge case but the core of the construction: the bill counts heads, not usage. Someone leaves, the seat stays in the count. A department buys licences for a project that stalls after a year, and the spend simply continues. You pay for access, not for value.

There is another layer beneath the licences: the maintenance of the systems you already run. Outdated systems carry technical debt, and that debt has a price. McKinsey (2020) estimates it at 20% to 40% of the value of your entire technology estate, and calculates that 10% to 20% of the budget for new products goes to clearing it. Every euro that goes there builds nothing. It pays a bill from the past. A platform you own reverses that logic: the cost follows the infrastructure you actually run, not the number of names on a user list.

The project price you pay once. The run-rate you pay until you switch the system off.

Where the money stands over five years

Be honest about the other side. Building a platform is a genuine investment up front. In the first year you pay more than a monthly licence costs, and that money is spent before the system has saved a single invoice. Anyone who pretends a build always comes out cheaper straight away is selling you something. The point is not the starting amount. It is where the money stands after sixty months.

So put the two timelines side by side instead of the two prices. Renting per user: a low start, then an amount that returns every year and rises with every head and every indexation. Building in ownership: a higher start, then a run-rate that follows the servers and the storage you actually use. When those two lines cross depends on how fast you grow, but cross they do, and from that point on the renter keeps paying every month while the owner mainly pays for infrastructure. We build that platform in waves with a go/no-go at each step, so the investment up front is not a bet on a single date, but a series of decisions that each demand their own proof.

• Your bill follows servers and storage, not the number of heads on the payroll.
• Growth loads the infrastructure, not every new user with their own monthly rate.
• The code sits in your own repository, transferable, without a licence that keeps ticking per seat.
• No empty seats in the count, because there is no per-seat count.

The first step is not building, and it is not signing either. It is calculating. Put three numbers side by side: what you pay for licences this year, how many of those seats are actually used, and what that same model becomes over five years if your headcount grows as you plan. Almost no one knows those three numbers by heart. An IT FinOps audit puts them on paper, at a fixed price and vendor-neutral, with a baseline that your own finance team signs off on.

Then compare not two prices but two timelines. The question is not what the build costs against next month's licence. The question is which model leaves you poorer after sixty months, and which model lets the cost move with what you run instead of with who you hire. Whoever stares at the project price sees the cheap option. Whoever adds up the run-rate sees the expensive one.