TOMS - How Should a Desktop Application Make Money? Thinking Through Licensing, Add-Ons, Cloud Services and Localisation
As I move further into the development of my event-planning desktop application, I am reaching a part of the project that has nothing to do with C++ classes, Qt widgets or file formats.
I need to decide how the product could eventually make money.
That question sounds simple. Build software, choose a price and sell it.
In reality, the business model influences quite a few technical decisions: licensing, update delivery, account management, documentation, cloud infrastructure, downloadable content, localisation and possibly even how much server-side functionality I want to introduce.
There is also a principle I want to preserve from the beginning.
The user should be able to install the application, create an event, work on it locally and retain control of the resulting files.
That does not prevent online services from existing around the product. But the online services should add something useful rather than becoming an artificial requirement for using software that fundamentally does not need a permanent server connection.
The obvious model: buy the application once
The simplest commercial model is the traditional desktop-software licence.
A customer pays once and receives the right to use that version indefinitely.
Bug fixes and maintenance updates within that version would be free. At some point, however, a sufficiently substantial new release would become a paid upgrade.
Version 1
│
├── initial purchase
├── 1.0.1 bug fix ── free
├── 1.0.2 bug fix ── free
├── 1.1 improvements ── probably free
└── 1.x maintenance ── free
Version 2
│
└── substantial new release
│
└── optional paid upgrade
I like this model because the commercial proposition is extremely easy to understand.
You pay for software. The software continues working.
If I produce a future version with enough additional functionality to justify another purchase, the customer can decide whether that new functionality is worth the upgrade price.
If it is not, the existing version does not suddenly stop working.
For a desktop application dealing with files that may remain important for years, I find that particularly attractive.
The problem with perpetual licences
There is, of course, a business problem.
If I sell the application once and continue improving it for many years, the development effort continues while revenue from existing customers does not.
That creates a peculiar incentive.
The developer needs to manufacture sufficiently large releases to create upgrade revenue.
The customer, meanwhile, may prefer a continuous stream of smaller improvements.
Developer wants:
larger paid releases
│
▼
Customer often wants:
continuous improvements
There is also revenue unpredictability.
A successful new release may produce a strong year. The following year may produce considerably less income even though development, testing, support and infrastructure costs continue.
So although perpetual licensing is attractive from the customer's perspective, it is not automatically the easiest model from the developer's perspective.
What about a subscription?
The obvious alternative is a subscription.
Pay monthly or annually and receive every new version while the subscription remains active.
Initially I was inclined to dismiss this idea because the application is not SaaS.
But that is actually mixing two different concepts.
A subscription is a commercial model.
SaaS is principally a delivery and operating model.
A locally installed desktop application can absolutely be sold by subscription. Several major professional desktop products already work that way.
Subscription
│
├── may provide SaaS
│
└── may provide desktop software
The two concepts are not equivalent.
The real question is therefore different:
Would customers receive enough continuous value to justify continuous payment?
That is where I am less convinced.
I do not want to charge rent for a static executable
I can understand a subscription when the supplier continuously operates something expensive on behalf of the customer.
Cloud storage costs money every month. Servers cost money every month. Data transfer costs money. Managed collaboration, artificial intelligence services, live data feeds and technical support all have continuing operational costs.
A desktop executable sitting on someone's computer is different.
If a customer bought a working copy last year and I have provided nothing new this month, it is difficult for me to argue that another monthly payment has created meaningful value.
That does not mean I am opposed to subscriptions.
It means I think a subscription should correspond to something genuinely continuous.
A hybrid model may be more interesting
There is a third model that I find increasingly attractive.
The customer buys a perpetual licence, perhaps including twelve months of updates.
During those twelve months, every new release is available.
Afterwards, the customer can renew the update entitlement.
If they do not renew, the application does not stop working. They simply keep the newest version they were entitled to receive.
Initial purchase
│
├── perpetual right to use product
│
└── 12 months of updates
│
┌───────┴────────┐
│ │
renew don't renew
│ │
▼ ▼
new versions current version
continue keeps working
JetBrains uses a variation of this principle with its professional development tools. Continuous subscription provides current versions, while qualifying customers receive a perpetual fallback licence to an eligible version.
That model has an appealing balance.
The developer gets recurring revenue from customers who value continued development.
The customer never feels that their existing work has been taken hostage by a stopped subscription.
But software licences do not need to be the only revenue
The more I think about the application, the more I see another possibility.
The core software could remain relatively simple commercially while an ecosystem develops around it.
An event planner repeatedly creates things.
Floor plans. Table layouts. Seating charts. Printed materials. Backgrounds. Decorative elements. Templates.
Many of those things are reusable.
That creates an opportunity for what I would loosely call consumable content.
Ready-made event templates
The first possibility is probably not textures at all.
I suspect templates could be considerably more useful.
Imagine opening a library and starting with:
- a formal wedding layout;
- a corporate dinner;
- a conference banquet;
- a classroom arrangement;
- a theatre-style seating layout;
- a restaurant event;
- a gala dinner;
- a Christmas function;
- a graduation dinner;
- a large family celebration.
The customer is not buying functionality.
They are buying time.
Without template:
blank document
│
▼
build everything
│
▼
event
With template:
template
│
▼
adapt
│
▼
event
For professionals, reducing repetitive setup may be more valuable than adding another button to the application.
A visual asset library
Then there are the more graphical possibilities.
A content library might contain:
- floor textures;
- wall textures;
- carpet patterns;
- wood and stone surfaces;
- room backgrounds;
- venue backgrounds;
- decorative elements;
- table styles;
- chair styles;
- plants;
- stages;
- dance floors;
- bars;
- podiums;
- lighting symbols;
- event icons.
There is already plenty of evidence that asset ecosystems can be valuable around professional design software. SketchUp's 3D Warehouse, for example, has evolved into a large searchable collection of models and materials, including curated content and manufacturer catalogues.
My application obviously does not need anything approaching that scale.
But the principle is relevant.
Core application
│
▼
Content catalogue
│
├── free starter assets
├── premium template packs
├── texture packs
├── background packs
└── specialist event packs
Some content could be free.
Some could be sold individually.
Some could be bundled into themed packs.
Eventually there could even be a marketplace where other designers produce content and receive a share of the revenue.
Buying content may be better than subscribing to content
I also need to decide whether assets themselves should be subscription-based.
For this product, my first instinct is no.
If someone buys a wedding template or a texture pack, I would prefer them to retain it.
A credit or pack model may be more natural:
€5 small asset pack
€15 specialised template pack
€25 professional venue collection
Purchase once
│
▼
download
│
▼
keep using
This pattern already exists in the broader creative-software market. Adobe Stock, for example, offers both subscriptions and one-time credit packs because customer demand for creative assets is not always predictable.
That flexibility makes sense to me.
Cloud backup is different
Online backup is one area where recurring charging immediately makes sense.
If I store somebody's data every day, I have recurring costs every day.
Storage, transfer, monitoring, encryption, redundancy and recovery systems all have continuing operational costs.
So I could imagine a completely optional service:
Desktop application
│
│ automatic encrypted backup
▼
Cloud storage
│
├── current version
├── previous version
├── previous version
└── previous version
This could offer more than simple file copying.
It could provide version history.
A customer accidentally deletes twenty Guests, saves the Document and only notices the following morning.
Being able to restore yesterday's copy suddenly has considerable value.
Commercial backup services already charge specifically for this recurring value. Backblaze, for example, currently prices its personal computer backup as an annual service, while Dropbox sells extended version-history capabilities as an add-on on supported plans.
Would I operate the storage myself?
Probably not, at least initially.
There is an important difference between owning the service and owning every physical component behind the service.
I could provide an Event Backup service while storing encrypted objects in a public-cloud storage platform.
My application
│
▼
My backup service
│
▼
Encrypted object storage
on public cloud infrastructure
That would allow me to concentrate on application-level functionality instead of buying servers, managing disks and trying to build my own data-centre reliability.
I would still be responsible for security architecture, access control, encryption, backup policy, privacy and data-retention behaviour.
Using a public cloud does not outsource responsibility.
It outsources much of the infrastructure.
Cloud backup could eventually become cloud sync
Backup also creates a possible path towards something more interesting.
Suppose a user works on a Windows desktop in the office and a MacBook at home.
An optional cloud service could eventually synchronise the same Event Documents between them.
Windows desktop
│
▼
encrypted cloud
▲
│
MacBook
That would still not turn the main application into SaaS.
The application would continue working locally.
The cloud would simply provide a service that is impossible to provide purely locally: synchronisation between devices.
And perhaps later, collaboration
Once synchronisation exists, another possibility appears.
Perhaps two event planners eventually need to work on the same Event Document.
That is much harder than backup.
It introduces conflict resolution, locking, identity, permissions and perhaps real-time collaboration.
I would not put this into the first version simply to create another subscription feature.
But architecturally it is useful to recognise the progression:
Local files
│
▼
Cloud backup
│
▼
Version history
│
▼
Device synchronisation
│
▼
Team collaboration
Each step should exist because customers need it, not because a spreadsheet says recurring revenue would be nice.
Documentation is part of the product
Another business-model question I have been thinking about is documentation.
Good documentation should not be treated as a cost to be minimised.
For professional software, documentation reduces support costs and makes the product easier to learn.
I would like the application to have help available even when there is no Internet connection.
At the same time, maintaining a completely separate local manual and online manual creates duplication.
So an attractive model is:
Canonical online documentation
│
├── browser access
│
└── locally cached copy
│
▼
application help
The same source could therefore serve both online readers and the application's contextual help system.
Documentation would also need to be versioned.
A person running an older desktop release should not automatically receive instructions for buttons or features that only exist in the latest release.
Should users comment directly on help pages?
This idea initially appeals to me.
A user reads an article and notices something unclear. Why not add a comment underneath it?
The difficulty is that product documentation and community discussion serve different purposes.
Documentation should be authoritative.
Comments are not necessarily authoritative.
They may be outdated, incorrect, repetitive or related to an older version.
I therefore think a better structure would be:
Official help page
│
├── "Was this useful?"
├── report documentation problem
│
└── discuss / ask community
│
▼
moderated discussion
A discussion system could still become extremely valuable.
User questions, workarounds and answers accumulate into a searchable knowledge base. Platforms such as Discourse explicitly organise community discussions, questions and marked solutions in this way.
But I would keep the official answer visually and structurally separate from the discussion around it.
Documentation can reduce support costs
This also connects directly to the business model.
Every question answered clearly in documentation is potentially one fewer support ticket.
Every useful community answer may prevent the same question being sent to support another fifty times.
So documentation has an economic return even if nobody pays for the documentation itself.
Better documentation
│
├── easier onboarding
├── fewer mistakes
├── fewer support requests
├── faster adoption
└── happier customers
Localisation is not simply translating buttons
Then there is localisation.
If the application succeeds, I do not want English to be permanently baked into the architecture.
But localisation is broader than translating a menu.
A properly localised product potentially includes:
- application interface text;
- errors and notifications;
- default templates;
- online documentation;
- offline help;
- website and purchasing pages;
- emails;
- licensing text;
- date formats;
- time formats;
- numbers;
- paper sizes;
- postal conventions;
- sorting behaviour;
- possibly legal and privacy information.
This is why localisation needs architectural preparation before the first translation happens.
Apple's own developer guidance makes the same distinction: localisation means adapting an application to different languages and regions, not merely translating literal strings.
I would architect for many languages, but translate according to demand
I do not think the first commercial release needs twenty complete translations.
That would create a considerable maintenance burden before I even know where the customers are.
But the software should be written from the first day as though twenty languages may eventually exist.
Bad approach:
develop everything in English
│
▼
years later
│
▼
"let's make it translatable"
Better approach:
localisation-ready architecture
│
▼
English release
│
▼
add languages according
to customer demand
The translation sequence could then be driven by actual commercial evidence.
If a significant number of customers arrive from one country, that language becomes a rational investment.
If another market remains tiny, automatic or community-assisted documentation translation may be sufficient initially.
Could the community help translate it?
Possibly.
Open-source projects have demonstrated for years that users are sometimes willing to improve translations of software they care about.
A commercial application could potentially use the same principle while still maintaining central review and quality control.
But I would be careful about depending entirely on volunteers.
A badly translated professional application damages credibility very quickly.
A better model might combine:
Initial machine / AI translation
│
▼
native-speaker review
│
▼
community corrections
│
▼
maintained terminology database
Consistency would be particularly important. Terms such as Guest, Group, Seat, Table, Floor Plan and Seating Solution should not mysteriously change translation from one screen to another.
There may be professional and personal editions
Another option I need to consider is whether one licence should fit everyone.
A family organising one wedding has a very different willingness to pay from a professional event planner using the software every week.
That could eventually justify editions rather than forcing everyone into the same price:
Personal │ ├── core planning ├── limited templates └── lower price Professional │ ├── full functionality ├── import / export ├── advanced reports ├── automation └── professional support
I am not yet convinced that artificial feature restrictions are desirable, but market segmentation is worth considering.
An alternative could simply be a commercial licence and a lower-cost personal-event licence with essentially the same application.
Support itself can be commercial
Professional customers may also value support differently from casual users.
Basic community and email support could be included with the product.
Businesses might pay for priority support, guaranteed response times, deployment assistance or migration help.
Again, this represents real recurring work.
Charging recurring money for recurring human service is much easier for me to justify than charging recurring money merely because the executable checks the calendar.
What I currently think the model could look like
I am still exploring this, but a structure is beginning to emerge.
CORE PRODUCT
│
├── perpetual desktop licence
│
├── bug/security fixes
│
└── optional future upgrades
│
└── paid major release
or update plan
OPTIONAL CONTENT
│
├── templates
├── textures
├── backgrounds
├── event packs
└── visual assets
OPTIONAL ONLINE SERVICES
│
├── encrypted backup
├── version history
├── device sync
└── perhaps later collaboration
DOCUMENTATION
│
├── online canonical help
├── cached/offline help
├── version-specific documentation
└── moderated community discussion
OPTIONAL PROFESSIONAL SERVICES
│
├── priority support
├── migration
└── business deployment
LOCALISATION
│
├── architecture ready from day one
└── translations added according to market demand
This feels more attractive to me than trying to extract all future revenue from the licence alone.
The principle I want to keep
The central rule I am arriving at is quite simple:
Recurring payment should correspond to recurring value.
If somebody pays once for a desktop application, I am comfortable with the idea that the version they bought should continue working.
If they want major new functionality, that can justify an upgrade.
If they want continuous cloud storage, that can justify a subscription.
If they want new professionally designed assets, those assets can be sold.
If they want priority human support, that can be a service.
Different sources of value do not necessarily need to be forced into one billing mechanism.
That also seems healthier commercially.
A customer who only wants the application can buy the application.
A professional user who wants backups, content libraries, continuous updates and support can spend considerably more because they are receiving considerably more.
And perhaps most importantly, the commercial architecture remains aligned with the technical philosophy of the product: a capable desktop application first, with useful services around it rather than a server dependency hidden inside it.
This is still a business model in development, just as the software itself is still being reconstructed and designed.
But I am increasingly convinced that the best answer will not be choosing between “perpetual licence” and “subscription”.
It will probably be deciding which parts of the product naturally belong to each model.
Comments
Post a Comment