Buying software, renting it, or owning it

There are three ways to pay for the software a business runs on. You can buy it once, rent it by the month, or have it built and own it. Most businesses never choose between them deliberately. They rent whatever was recommended, keep renting it, and only think about the model when the price goes up or the product changes under them.

None of the three is the right answer in general. Each one is the right answer for a particular kind of problem, and it is worth knowing which kind you have before the bill becomes a habit.

The three ways to pay

Buying means a one-off licence. You pay once and use that version for as long as it runs. This was how most software worked twenty years ago, and it has nearly disappeared. Where it survives, it is usually for desktop tools, and the catch is that “once” tends to mean “until the next major version stops supporting your operating system”.

Renting is the subscription model, often called software as a service. You pay monthly or yearly, usually per user, and the provider runs everything: the servers, the updates, the backups, the security. Accounting packages, CRMs, booking tools and Microsoft 365 itself all work this way.

Owning means software built for you. You pay for the build, then a smaller ongoing amount to host and look after it. The code, the data and the accounts belong to the business, if the contract says so.

What each one gives you, and what it costs you

Renting is cheap to start and someone else carries the work. You get a mature product that thousands of other businesses have already tested. In exchange, you live with how it works, you pay for as long as you use it, and the provider decides the price, the features and the future. If they raise the price by a third, or are bought and wound down, your choices are to pay or to move.

Owning costs more to start and fits exactly. Nobody can raise your licence fee, because there is not one. In exchange, you are responsible for it. Someone has to keep it updated, keep it running, and still be there to change it when you need it to do something new. Ownership is not the absence of cost. It is a different shape of cost, mostly up front and then much smaller.

Buying sits in between and suits less and less. It is worth considering for a tool a few people use offline, and rarely for anything shared.

The comparison worth doing

The usual mistake is comparing the first month of rent with the full cost of a build. The rent always looks smaller, because one month is a small number.

Compare over three years instead, at your real headcount, including the price rises you can reasonably expect. A tool at €25 a user a month, for eight people, is €2,400 a year and €7,200 over three, before any increase. Set that against what a build would cost plus three years of hosting and care. Sometimes the rent still wins comfortably. Sometimes it does not, especially when the headcount grows and the build would not care how many people log in.

The other half of the comparison is fit. A rented tool that does eighty percent of what you need, with the other twenty done by hand in a spreadsheet alongside, has a hidden cost in staff time that never appears on an invoice.

When renting is the right answer

Most of the time. If the problem is common, somebody already sells the answer, and the case for buying the twenty euro tool instead of starting a project is strong. Invoicing, payroll, scheduling, email marketing and bookkeeping are solved problems, and building your own would be paying to recreate something worse.

Renting is also right when you are not sure yet. A subscription you can cancel in a month is a cheap way to learn what you actually need, and that knowledge makes any later build smaller and better.

When owning is the right answer

• The way you work is the thing that makes you money. If your process is genuinely different, a tool built for everyone else will push you towards working like everyone else.
• Per-user pricing has stopped making sense. Thirty staff who each open a tool twice a week cost the same as thirty who live in it all day.
• You are stitching several subscriptions together to do one job, and the joins are where the errors happen.
• Customers or partners need to use it, and rented tools charge for every outside login or do not allow them.

Even then, there are good reasons a custom build can be the wrong call, and they are worth reading before anyone is asked for a quote.

What owning actually means

Owning software is four things, and a build can give you some of them without the others:

• The code, stored somewhere you can reach, with the right to use and change it written into the contract.
• The data, in a database you can export from in a normal format.
• The accounts for hosting, domain and any services it relies on, in the business’s name.
• The knowledge of how it works, written down well enough that another developer could pick it up.

A build where the developer holds the code and the accounts is closer to renting from one person than owning. That is a fair arrangement if everyone knows it, and a risk if nobody does. What happens when the person who built it moves on is covered separately, and it is worth settling before the build rather than after.

The question nobody asks: how do you leave?

Every model has an exit, and the cost of the exit is part of the price.

For a rented tool, the exit is the export. Can you get all your data out, in a format another product can read, without paying for a special service? Some providers make this easy. Some make it possible in theory and painful in practice. It takes ten minutes to check before signing up, and it is much harder to fix years later.

For an owned build, the exit is the handover. If the code, the accounts and the notes are yours, another developer can take over. If they are not, you are starting again.

Three situations, worked through

A six-person accountancy practice wants better client document handling. Practice management software built for accountants already does this, with the compliance features they need. Rent it. Building would cost more and deliver less, and the vendor carries the regulatory changes.

A cleaning company with forty staff schedules jobs in a rented tool charged per user. Most staff only check their rota and tick off jobs. The subscription has crept up each year and the scheduling still needs a spreadsheet alongside. Over three years, a small scheduling app that fits their exact rota rules costs less, and the headcount can grow without the bill following it. Owning is worth pricing properly.

A shop owner bought a desktop stock program years ago and it no longer runs on new computers. The one-off licence was cheap at the time and now traps the data in an old format. The move is to a rented stock system with a proper export, and the lesson is to check the exit on whatever comes next.

Five things worth doing

1. List what you rent, with the per-user price and the number of users. The yearly software audit is a good moment to do it.
2. Multiply each line out over three years at the headcount you expect, not the one you have.
3. Check the export on every tool that holds important data. Try it once, so you know it works.
4. Note where you work around a tool, with a spreadsheet or a manual step. That is where the hidden cost lives.
5. If you commission a build, get ownership in writing: code, data, accounts and documentation.

Common misconceptions

• “Custom software is always more expensive.” Up front, usually. Over several years at a growing headcount, not always.
• “Once it is built, it is free.” It needs hosting, updates and someone to call. Those costs are smaller than rent, but they are real.
• “Our data is in the subscription, so it is safe.” Safe from loss, mostly. Not necessarily easy to take with you.
• “If we paid for it, we own it.” Only if the contract says so. Paying for a build and owning the result are not automatically the same thing.

The honest summary

Rent for common problems, which is most of them. Own when the way you work is genuinely different, when per-user pricing stops matching how the tool is used, or when outside people need access. Buy once only for small, standalone tools, and expect “once” to have an end date.

Whichever you choose, compare over three years rather than one month, and know how you would leave before you arrive. If you want to see what owning would cost against a subscription you already pay for, the costs of a small custom app are set out plainly, and you are welcome to send the subscription and the headcount for a straight comparison.