The licence penalty on growth, and how ownership breaks it

You hire someone. On day one that person gets a mailbox, a chat account, a project tool, a CRM login, a design suite, a BI dashboard. Each of those accounts has a price per seat, per month. Multiply that by every new colleague and you see what happens: your software cost grows as fast as your team, whether or not that software does any more for you.

That seems logical until you add it up. A team that doubles doubles its licence cost. But a team that doubles does not suddenly use twice as much software. It uses the same software, with twice as many logins. You pay for seats, not for work.

Why per-user pricing punishes growth

The per-user model is comfortable for the seller and dangerous for you. For the vendor it is perfectly predictable: their revenue rises automatically with your success. If you grow, their invoice grows. You do the work, they collect the increase.

For you it works the other way round. The cost is tied to a number you actually want to see rise, namely your headcount. Every hire is good news for the business and at the same time a new line on ten or twenty invoices. Nobody makes that decision consciously. It is made by a renewal clause you signed at some point.

Ask finance and you rarely get a single figure back. The cost is spread across departmental budgets, small card payments and annual contracts that expire at different times. Each piece is defensible. The total is never discussed. That is not carelessness, it is the natural outcome of a model that makes buying easy and adding up hard.

Work it through. An employee quickly has access to ten to twenty paid tools, each with its own monthly price per seat. Those prices look small on a single invoice. Added up across all tools and all people they become one of your largest recurring line items, and that item scales linearly with your hiring plan. You are no longer buying software, you are subscribing to your own growth.

There is a time bomb here too. The longer a tool runs, the deeper it sits in your processes, and the more expensive it becomes to leave. The price per seat is the entry fee. The real cost is the dependency that grows with every month. A price rise on a tool your whole team uses is not something you can negotiate away. You swallow it, because the alternative is a migration you are no longer willing to take on.

The sprawl that nobody adds up

The problem is not one tool that costs too much. It is that nobody sees the total. Software is rarely bought centrally. Marketing takes its own suite, sales its own CRM, product its own roadmap tool, finance its own reporting package. Each of those is a reasonable decision at department level. Together they form a portfolio that nobody manages as a whole.

The figures are sobering. According to Zylo (2024), on average 44% of the SaaS licences in an organisation are wasted or underused, and roughly half of what a company buys is actually used. In other words, you pay for two seats to fill one. A typical company runs dozens of SaaS applications side by side, each one bought per department and billed per user.

For IT that is a second bill on top of the first. Every tool means its own account management, its own set of access rights, its own place where company data ends up. More seats means not only a bigger invoice, but also more surface to secure, to onboard and to shut down again. The licence cost is visible. The management burden underneath rarely is.

These facts reinforce each other. The more separate tools, the more overlap, and the more licences that are technically active but practically idle. The waste is not a one-off. It is baked into a model where every department buys separately and nobody accounts for the whole.

Where the money actually sits

If you want to know where it leaks away, do not look at the big contracts. Look at the details that run on autopilot.

• Automatic renewals. Contracts that renew themselves every year without anyone reviewing them again. The notice period is often just long enough to miss.
• Licences for people who have left. Someone leaves the company, but their seat in eight tools stays active and billed. Offboarding stops at the mailbox, not at the SaaS invoices.
• Three tools that do the same thing. Two teams each bought a project tool separately, a third came with an acquisition. You pay three times for the same function, plus the time to keep them running side by side.
• Seats bought just in case. Packages sold in tens or twenty-fives, half of which you never fill but do pay for.

None of these items is big enough to raise the alarm. That is exactly the point. They are designed to stay below the threshold at which someone steps in. Over a year, across all tools, across every department, they add up to a figure that leadership and finance rarely see in a single overview.

The first step is mundane and rarely taken: put all contracts, card payments and active accounts side by side on a single sheet, with who uses them and what they cost. Almost every company that does this exercise finds tools it did not know it was still paying for. Not through carelessness, but because the overview was on nobody's job description.

The real question: tied to value or to headcount?

Put the question differently. What should your software cost actually be tied to?

To value. To what the system does for you: processing orders, serving customers, automating processes, unlocking data. That value does not depend on how many people happen to have a login. An order is an order, whether five or fifty colleagues open the system.

The per-user model ties your cost to the wrong axis. It charges per head, while your value arises per process, per customer, per transaction. As long as those two run apart, you pay a penalty for hiring people, exactly the move that marks a healthy business.

This is not a fringe phenomenon. Worldwide SaaS spending grew by about 20% in 2024 to 247 billion dollars, and is heading towards nearly 300 billion in 2025 (Gartner, 2024). That curve is largely the sum of companies paying more per head, not getting more value per head.

What ownership changes

There is another way to fund software. Not renting per seat, but building and owning.

A platform you own runs on infrastructure that you manage yourself or buy on a usage basis. Its cost depends on what the system does: how much it processes, how much it stores, how much it computes. Not on how many people log in. If you hire ten people, those ten get access without ten licences being added. The marginal cost of an extra user drops to zero.

That decouples your growth from your software cost. Growth then costs capacity, and capacity has become predictable and cheap. You scale up on people without a renewal clause scaling with them. The graph of your team and the graph of your licence cost no longer run in parallel.

The second shift is in ownership. With a platform you own, the code sits in your own repository from day one. You are not a tenant renegotiating every year over a price the vendor sets. You own the system your business runs on, and with it the freedom to stop, to change, or to have someone else continue building it.

The objection is obvious: building costs more up front than renting. That is true on day one. The point is the slope after that. A per-user subscription starts low and rises with every head, every indexation, every new module. A platform you own asks for an investment up front and then flattens out. Somewhere those two lines cross, and from that point the owned model pays for itself again every month. Where that crossing point sits depends on your size and your rate of growth. For a company that is hiring, it lies closer than most people think.

Before you move a single euro, it pays to know what you are paying today. Work out the run rate across all your tools and users, and set it against a model where growth costs infrastructure instead of seats. Usually the difference is not in one expensive tool, but in the sum that never sat on a single sheet.

This is how YK Technologies works. We are a Belgian, founder-led company that builds one platform you own instead of selling a stack of subscriptions. The code sits in your repository, on EU cloud, with security at NIS2 level. We build in waves, with a go/no-go at every gate, so you are never locked into a choice that no longer fits. No licence per user. One system that replaces the scattered tools, and the lock-in with them.

The question is not whether software should cost money. Of course it should. The question is what that cost is tied to. As long as you pay per head, you pay a penalty on every success that grows your team. Decouple the two, and growth becomes again what it should be: a reason to build, not a line item that multiplies itself.