اشتراك أم ترخيص لمرة واحدة؟ التكلفة الحقيقية للنموذجين

In a subscription the seller commits to keeping the product running and current, and the buyer pays for as long as they use it. In a one-time licence the seller delivers a specific version, and keeping the product alive afterwards is the buyer's job. The difference between the models is not price but where responsibility sits — and when that is not made explicit, both sides sign with the wrong expectation.

The most common objection on the buyer's side is that a subscription 'never ends'. In truth a one-time licence does not end either: servers, backups, security updates, version upgrades and support costs sit in the buyer's budget from that day on. The difference is between the cost appearing on one line or being scattered across four. An invisible cost is not an absent one.

The only meaningful ground for comparison is total cost of ownership over three years. On the subscription side the arithmetic is easy: monthly amount times thirty-six, plus setup and migration. On the licence side four lines are added: servers or hosting, backups and monitoring, the technical time to apply updates, and a support agreement. Without those four, a licence always looks cheaper.

There is also a risk line: the cost of the hours the system is down. In a subscription that risk largely sits with the seller; with a licence it sits with the buyer. Whatever a day of downtime costs a business, that figure belongs on the licence side. Most organisations, seeing that line for the first time, realise the gap between the models is smaller than they assumed.

Finally, the value of time: a subscription starts working on day one, while a licensed installation usually requires a setup project. The value of starting three months earlier varies by business but is never zero. Once these three lines — operations, risk, time — enter the calculation, the decision often points somewhere other than the up-front price difference suggests.

A subscription is right for organisations that have no system administrator and do not want one — the vast majority of small and mid-sized businesses. They want to use the product, not operate it. Selling a one-time licence to such an organisation turns, by the third month, into 'the system is slow, who looks after it', and that question usually comes back to the seller anyway — this time without a contract.

An on-premises installation is right where data cannot leave the organisation or where the organisation runs its own data centre: public sector, defence, finance, healthcare and large enterprises. The discussion there is about jurisdiction more than security — under which law, which network and which backup policy the data sits. In those organisations, proposing a subscription is usually a waste of time.

We offer our products in both models, and the important thing to make clear is this: both run on the same core, and the on-premises version is not a limited edition. Without that clarity a buyer assumes a local installation means a second-class product, and hesitates for good reason.

A subscription model gives the seller predictable revenue but demands uninterrupted responsibility in return. Running, updating, backing up and monitoring the product is now your job; without an operational discipline to do it, subscription revenue melts into support cost. The question to ask before moving to subscriptions is operational rather than commercial: who keeps this system up around the clock?

The second difficulty is the cancellation and suspension flow. If you sell subscriptions, the product must recognise the state 'payment not received': how is access restricted, how long is data kept, what happens when a customer returns? If you do not build that flow into the product from the start, the first cancellation is handled by hand — and that manual handling becomes a habit.

The third is price change. Unlike a one-off sale, a price increase in a subscription concerns the entire customer base at once. Announcing it in advance, explaining the reason and holding the old price for existing customers for a while looks like lost revenue in the short term but is cheaper than a wave of cancellations.

For a buyer the most important assurance is not the name of the model but the portability of the data. In both a subscription and a licence the question is the same: can I take my data out, in full and machine-readable, on any day I choose? A subscription with a provider who answers that clearly is safer than a licence from one who does not.

That is why we treat export as a basic capability rather than a 'feature'. If a customer can take their data whenever they want, the reason they stay with us is satisfaction rather than being locked in. That is a healthy pressure on the product team too: what keeps a customer should be the quality of the product.

The second decision in a subscription model is billing frequency, and it concerns cash flow more than price. Annual up-front billing is working capital for a small software company: a year's revenue arrives today and funds development. In return the customer gets a discount, and that discount is the present value of the money — framing it that way stops the discount from being arbitrary.

Monthly billing's advantage is a low barrier to entry: the customer starts with a small commitment and continues if satisfied. The disadvantage is that leaving is just as easy — annual customers stay a year, monthly ones decide again every month. That creates healthy pressure on the product team but makes revenue forecasting harder.

In practice offering both is the common solution: a monthly price on the list and a clear discount for annual payment. The customer chooses by their own cash preference. The one thing to watch is that cancellation and refund terms for the annual plan are explicit — if what happens to a customer who paid for a year and quits in month three is unwritten, that conversation always goes badly.

A subscription ends; the data does not. How long data is kept after cancellation, in what format it can be exported and when it is deleted must be defined explicitly. The answers should be both written in the contract and implemented as a mechanism in the product; 'we can pull it from the database if needed' is a promise, not a process.

Our approach is designing cancellation as suspension rather than deletion: the account closes, access stops, and data is kept for a defined period. If the customer returns within it, nothing is lost — and in practice returns are not rare at all. When the period expires, deletion happens automatically and on the record.

If you sell a one-time licence, the real relationship is formed by the maintenance agreement rather than the licence. After delivery, security updates, framework upgrades and regulatory changes continue; unless who does them, how often and at what price is answered up front, the customer is left two years later on an unsupported version.

A maintenance agreement should have at least three headings: the window for applying security patches, the scope of version upgrades, and the response time for faults. It also helps to add an 'out of scope' list — new feature development, data corrections and third-party integrations are usually outside maintenance, and arguing about that later damages the relationship.

One: are updates included? In a subscription usually yes, in a licence usually no — but when that assumption is unwritten, an argument follows a year later. Two: what is the scope of support and the response time? 'Support included' means nothing on its own; at what hours, through which channel, within what time.

Three: how is data exported, and how long is it kept when the contract ends? Four: in an on-premises installation, whose responsibility is a version upgrade and under what terms? Five: how are price changes announced, and for how long is an existing customer protected?

Having those five in writing makes the relationship predictable rather than legalistic. Our experience: detailing the contract is not a sign of distrust but the opposite — when both sides know what to expect, the relationship lasts.

The choice between subscription and licence is about where responsibility stays, not about how payment is made. For an organisation that does not want to operate the system, a subscription; for one whose data cannot leave, a local installation. When deciding, calculate three-year total cost, operational burden and downtime risk together — the up-front price alone is misleading.

We offer both models and give the same core in each; the only difference is who operates it. If you want to discuss which fits you, let us start with who would keep the system running on your side — the decision is usually hidden inside that answer.