When I first started looking at software products from the perspective of someone who might actually build and sell one, I assumed the biggest decision would be what to create. I thought mainly about features, design, audience and the problem the product should solve. Another question appeared much earlier than I expected: should the software be something customers install themselves, or should it run as an online service that I manage?
At first, the difference seemed mostly technical. A self-hosted application runs on the customer's own server, while a SaaS product runs on infrastructure managed by the provider. One requires installation, while the other usually requires little more than opening a browser and creating an account. It looked like a decision about deployment.
The more I explored it, the less accurate that explanation felt. I was not really comparing two ways of putting the same software online. I was comparing two different relationships between a product, its creator and the people using it.
That distinction is often lost in discussions about self-hosted software and SaaS. They are sometimes presented as competing technologies, as though one model must eventually replace the other. In practice, they tend to suit different customers, create different expectations and require very different kinds of businesses behind them. The more interesting question is not which one is better, but why both continue to make sense.
Two Similar Products Can Hide Very Different Businesses
Imagine two project management applications with almost identical interfaces. Both include tasks, dashboards, team members, reports and notifications. From a user's point of view, there may be little to distinguish them during a quick demonstration.
One product is sold as downloadable software that customers install on their own server. The other is available through a monthly subscription and requires nothing more than an account. The features may look similar, but the assumptions behind them are not.
The self-hosted company is usually selling a licence, a software package or access to source code. The SaaS company is selling continued access to a service that remains under its control. One transaction transfers a product into the customer's environment. The other begins an ongoing relationship.
That difference affects several parts of the business:
- how revenue is generated;
- how updates are delivered;
- who pays for hosting and infrastructure;
- who is responsible when the application becomes unavailable;
- how customers think about long-term costs;
- how dependent the customer remains on the original provider.
The software may look almost identical. The business rarely is.
Why the Difference Is Often Oversimplified
A common explanation says that self-hosted software is something you install, while SaaS is software somebody else hosts for you. That is technically true, but it leaves out much of what makes the choice significant.
The more revealing questions begin after the software is already running:
- Who performs the updates?
- Who creates and tests the backups?
- Who responds when the server fails?
- Who handles security issues?
- Who decides whether an old feature remains available?
- Where is the data stored?
- How easily can the data be moved elsewhere?
- Can the application continue running if the vendor closes or changes direction?
These are not mainly questions about programming languages or deployment scripts. They are questions about responsibility, access and expectations. They also reveal why two products with similar features can create very different long-term relationships with their users.
The comparison is sometimes similar to buying a home and renting one. Both provide somewhere to live, and the daily experience may not always feel dramatically different. Yet ownership, maintenance, flexibility and long-term costs are structured in very different ways. Software can follow a similar pattern, although the boundaries are not always as clear as the analogy suggests.
What Self-Hosted Really Means
The term self-hosted naturally draws attention to hosting, but the location of the server is only one part of the model. A self-hosted product usually becomes part of the customer's own technical environment rather than remaining a service controlled by the original developer.
The customer may install it on:
- a shared hosting account;
- a virtual private server;
- a dedicated server;
- an internal company network;
- a local machine or small private server.
The exact infrastructure can vary widely. What matters is that the customer, rather than the software vendor, generally controls where the application runs.
That control often extends beyond hosting. Depending on the product and licence, the customer may be able to:
- decide when updates are installed;
- choose how backups are organised;
- control where application data is stored;
- keep the application running for as long as the infrastructure supports it;
- modify the software for a particular workflow;
- connect it to internal systems or third-party services.
Self-hosted software does not automatically mean unrestricted ownership. Some products provide readable source code but limit redistribution. Others allow internal modifications but restrict resale or use across multiple client projects. Open-source software, commercially licensed source code and closed-source self-hosted applications can all sit under the same broad label while offering very different rights.
The meaning of ownership depends on the licence. A customer may own the installation and control the data without owning the copyright or having the right to redistribute the software.
Even so, the basic relationship remains similar. The software runs inside an environment controlled by the customer, and much of the operational responsibility moves with it.
For some organisations, that is a major advantage. They may have privacy requirements, unusual internal processes, strict infrastructure policies or concerns about depending too heavily on an external platform. A self-hosted application can give them more control over data, integrations and long-term availability.
That control has a cost. Someone still has to maintain the server, install updates, monitor security and restore backups when something fails.
Owning software does not remove maintenance. It changes who performs it.
SaaS Is Less About the Cloud Than the Relationship
Software as a Service is often described simply as software in the cloud. The description is familiar and broadly accurate, but it does not fully explain what customers are paying for.
With SaaS, the provider does not merely deliver an application. The provider continues operating it. That ongoing service may include:
- hosting and server management;
- monitoring and availability checks;
- automatic software updates;
- security patches;
- database backups;
- technical support;
- infrastructure scaling;
- continued product development.
This arrangement removes a large amount of responsibility from the customer. There is usually no server to configure, no update package to download and no database migration to perform manually. The customer signs in and expects the product to work.
For many businesses, this is not a compromise. It is the main benefit. A company choosing a CRM, accounting platform or collaboration tool may have no interest in maintaining another application internally. It may prefer predictable access, automatic updates and support from a provider that already understands the system.
Paying for that ongoing service can be entirely reasonable. It also explains why comparing a one-time self-hosted price with a monthly SaaS subscription is not always straightforward. A SaaS fee is not only payment for the software interface. It may also cover the infrastructure and labour required to keep the product available.
Recurring revenue is clearly attractive to SaaS companies, but recurring costs are real as well. The product must remain available every day, not only on the day it is purchased. As the user base grows, the provider may need more infrastructure, more support and more attention to security and reliability.
The work does not stop after version 1.0. In many ways, that is when it becomes permanent.
The Question That Changed How I Looked at Software
When I began creating my own products, I was not trying to take a side in a debate between self-hosted software and SaaS. I was trying to understand what kind of product business I could realistically manage alone.
I work independently and also have a full-time job. That affects how much time I can give to support, server monitoring, urgent fixes and continuous product updates. A business model that might be manageable for a team can become something very different when one person is responsible for every part of it.
My first commercial project,
The same thinking later influenced Captain's Toolkit and the wider direction of Cordinant. It was not based on a belief that SaaS was bad or that subscriptions were inherently unfair. I use SaaS products myself, and many of them make far more sense as continuously managed services than they would as applications I had to install and maintain.
My decision was more practical than ideological. Running a SaaS product would mean taking responsibility for:
- application uptime;
- hosting and infrastructure;
- database backups;
- security updates;
- customer access;
- support requests;
- unexpected failures and urgent fixes.
If something failed at an inconvenient time, it would still be my problem. Customers would reasonably expect the service to remain available regardless of what else was happening in my life. That is a serious promise for a solo creator.
A self-hosted product does not remove every ongoing obligation. Documentation still matters, bugs may still need fixing and customers may still ask questions. Future versions may still require development. The responsibility is simply divided differently.
Selling source code allows the customer to install, control and adapt the product within the terms of the licence. It allows me to concentrate more of my limited time on creating the application itself rather than operating a permanent online service around it. For the kind of business I am building, that feels more realistic.
Self-hosted software is not maintenance-free software. The difference is that hosting, backups, updates and infrastructure are no longer entirely the vendor's responsibility.
I do not see this as proof that self-hosting is the better model. It may not suit customers who want immediate setup, automatic updates or a service someone else maintains. It may also be the wrong choice for products built around real-time collaboration, shared networks or constantly changing data.
I am not certain that every future product I create will follow the same approach. Different ideas may require different models. For now, self-hosted software fits both the products I want to build and the level of ongoing responsibility I can honestly accept.
That is perhaps the first useful distinction in the self-hosted versus SaaS discussion. The technical architecture matters, but it is only part of the decision. Behind every deployment model is a business deciding what it can promise, and a customer deciding what it is willing to manage.
The Economics, Trade-Offs and Why Neither Model Is Free
It is easy to compare self-hosted software and SaaS by looking only at the price tag. One might cost a single payment, while the other asks for a monthly subscription. At first glance, the comparison seems straightforward.
In reality, software pricing tells only part of the story.
A one-time purchase does not necessarily mean the software will cost less over its lifetime. Likewise, a subscription is not automatically expensive simply because payments continue every month. Much depends on what is included, who carries the ongoing responsibilities and what happens after the software has been installed—or activated.
The business model behind a product often explains its pricing better than the technology itself.
Selling Software Is Very Different from Running Software
When people compare self-hosted products with SaaS, they often focus on the customer's experience. Equally important is what happens on the creator's side.
A company selling self-hosted software usually spends most of its effort creating the product itself. New features, bug fixes, documentation and occasional support remain important, but once a customer installs the application, much of the day-to-day operation becomes their responsibility.
A SaaS business has a different rhythm. Building the application is only one part of the work. The service must also remain available every hour of every day. Servers need monitoring, databases require maintenance, security patches cannot wait until next week and unexpected outages demand immediate attention.
Neither approach is inherently easier. They simply distribute the work differently.
The contrast becomes clearer when looking at where responsibility typically sits.
| Area | Self-Hosted | SaaS |
|---|---|---|
| Hosting | Customer | Vendor |
| Infrastructure | Customer | Vendor |
| Automatic updates | Usually customer | Vendor |
| Backups | Usually customer | Vendor |
| Application availability | Customer | Vendor |
| Software improvements | Vendor | Vendor |
The table represents the most common responsibilities. Some self-hosted vendors provide managed hosting or automatic updates, while some SaaS platforms allow customers to manage parts of their own infrastructure. There is no universal rule.
Even so, the overall pattern remains remarkably consistent. Self-hosted software transfers much of the operational responsibility to the customer, while SaaS keeps that responsibility with the provider.
Revenue Is Predictable for One Model and Less So for the Other
The financial side of the comparison often dominates online discussions.
SaaS companies are frequently associated with recurring revenue. Customers subscribe, payments arrive every month and, if enough customers stay, income becomes more predictable. Investors often favour this model because future revenue is generally easier to estimate than one-time software sales.
A self-hosted business usually works differently. Revenue depends on new customers, licence renewals or paid upgrades. Some months may be excellent, while others are much quieter.
From the outside, the SaaS model can appear obviously superior. The reality is more complicated.
Predictable revenue is valuable, but predictable expenses come with it. Every active customer increases the amount of infrastructure, storage, monitoring and support that may be required. Growth can increase income, but it often increases operational costs at the same time.
Self-hosted software has a different balance. Income may fluctuate more, yet infrastructure costs usually grow much more slowly because customers operate their own installations.
Neither model guarantees a healthier business. Both require enough customers to justify the work involved.
Customers Also Face Different Long-Term Costs
A similar difference exists from the customer's perspective.
Buying a self-hosted application often means paying once and then deciding how long to keep using that version. There may be optional upgrades, maintenance contracts or future licence renewals, but the customer generally has more flexibility over when additional spending happens.
SaaS works differently because the cost is closely tied to continued access. As long as the subscription remains active, the service continues. If payments stop, access may become limited or disappear entirely, depending on the provider.
Neither approach is automatically cheaper.
- A small business may spend very little on a SaaS platform while benefiting from continuous improvements and support.
- A larger organisation with hundreds of users may eventually find that a self-hosted solution becomes more economical.
- A niche business may value ownership more than convenience.
- A rapidly growing startup may prefer simplicity over infrastructure management.
The answer depends less on the pricing page than on how the software will actually be used over the coming years.
Every Convenience Comes with a Trade-Off
One reason debates about self-hosted software and SaaS rarely end is that both models solve genuine problems.
SaaS removes many technical responsibilities. Customers do not usually need to think about operating systems, web servers or database upgrades. They simply expect the application to be available whenever they need it.
That convenience, however, comes with a degree of dependence on the provider. Subscription prices can increase, features can disappear, usage limits may change or the provider might eventually discontinue the service altogether. These situations are relatively uncommon among established platforms, but they remain possible.
Self-hosted software shifts those risks in a different direction. Customers gain greater control over their own environment, but they also become responsible for tasks that someone else would normally handle.
| Self-Hosted | SaaS |
|---|---|
| Greater ownership and control | Greater convenience |
| Flexible customisation | Automatic updates |
| Control over data location | No server administration |
| Independent from vendor infrastructure | Continuous support |
| Responsible for maintenance | Dependent on the provider |
Neither column contains only advantages, and neither contains only disadvantages. Each simply reflects a different set of priorities.
Why I Never Planned to Build a SaaS Business
When I started working on My Budget Tracker, I was already thinking about these trade-offs, although I probably would not have described them in quite the same way at the time.
I knew I would be building the product alone. I also knew I would continue working full-time while developing it. That meant every promise I made to future customers had to be realistic.
Running a SaaS product is not simply about writing code. It also means accepting responsibility for everything surrounding that code. If the server becomes unavailable on a Sunday morning or a database problem appears during the night, customers are unlikely to care whether the issue comes from the application or the infrastructure. From their perspective, the service simply is not working.
I realised I could not honestly guarantee that level of continuous availability. That was not because I doubted the SaaS model itself. It was because I understood my own limitations.
Choosing self-hosted software allowed me to build products that customers could genuinely own while avoiding promises that I might struggle to keep over many years.
Looking back, I think the decision was less about technology than about honesty. I wanted the business model to reflect what I could realistically support rather than what seemed fashionable or commercially attractive.
My choice reflects the way I work as an independent creator. A larger company with a dedicated team could reasonably arrive at the opposite conclusion and still make the right decision for its business.
Different Products Naturally Lead to Different Models
There is another reason these discussions rarely produce a single answer. Some software is naturally suited to SaaS, while other applications work perfectly well as self-hosted products.
Products that often benefit from the SaaS model include:
- collaboration platforms;
- communication tools;
- online document editors;
- large CRM systems;
- services that rely on continuous synchronisation.
On the other hand, self-hosted software is frequently chosen for:
- internal business applications;
- reporting systems;
- client portals;
- documentation platforms;
- finance applications;
- custom business tools.
The same feature set can sometimes be delivered using either model. The more important question is not whether the application can be self-hosted or offered as SaaS, but whether one model creates a better long-term relationship between the software, its creator and its customers.
That relationship is often more influential than the technology itself.
Why Self-Hosted Software Is Becoming Interesting Again
For a long time, it seemed as though SaaS would eventually become the default model for almost every kind of software. Faster internet connections, reliable cloud infrastructure and the growing popularity of subscriptions made that prediction seem entirely reasonable. Many products genuinely became easier to use because customers no longer needed to install or maintain anything themselves.
Yet over the past few years, self-hosted software has quietly become more visible again. It has not replaced SaaS, nor does it appear to be doing so. Instead, it has found renewed interest among organisations and individuals who value ownership, privacy and long-term control over convenience.
Several developments have contributed to this shift. Docker and container-based deployment have made self-hosted applications easier to install than they were a decade ago. Open-source projects continue to attract active communities, while businesses have become increasingly aware of data ownership, compliance requirements and the risks of depending too heavily on a single provider.
Another factor is subscription fatigue. Many businesses now rely on dozens of online services, each charging a monthly fee. Individually those subscriptions may seem reasonable, but together they can become a significant operational expense.
None of these trends suggest that SaaS is disappearing. They simply explain why more people are asking whether every application really needs to be a hosted service.
The renewed interest in self-hosted software does not represent a return to the way software was distributed twenty years ago. Modern self-hosted applications often include automatic installers, Docker support, REST APIs, responsive interfaces and cloud integrations. The distinction between traditional desktop software and modern self-hosted web applications is much smaller than it once was.
AI May Blur the Boundary Even Further
Artificial intelligence may become another reason why the distinction between SaaS and self-hosted software becomes less clear.
Today, many AI-powered applications depend on cloud services because large language models require substantial computing resources. Sending requests to external APIs is often the simplest and most economical approach.
At the same time, local AI models are improving rapidly. Smaller language models can already run on modern desktop computers and increasingly capable servers. As hardware becomes more powerful and software becomes more efficient, more organisations may choose to process sensitive information within their own infrastructure rather than sending it to external providers.
That does not necessarily mean cloud AI will become less important. Large hosted models will almost certainly remain attractive because they continue to improve quickly and remove the need for organisations to maintain their own AI infrastructure.
It seems entirely possible that many future products will combine both approaches rather than choosing one exclusively. A self-hosted application might rely on local AI for sensitive tasks while using cloud services for more demanding workloads. Likewise, a SaaS platform may allow customers to connect their own AI providers instead of depending entirely on the vendor's infrastructure.
The discussion may gradually move away from choosing between self-hosted and SaaS towards deciding which parts of a product belong in each environment.
Some Products Are Better as SaaS
After spending much of this article discussing self-hosted software, it would be easy to assume that I believe it is the better model.
I do not.
Many of the services I use every day would lose much of their value if they were distributed only as downloadable software. Products built around real-time collaboration, shared workspaces, communication, cloud storage or continuously synchronised data often benefit enormously from being centrally managed.
Services such as email platforms, team collaboration tools, customer support systems or large CRM platforms depend on thousands or even millions of users working within the same continuously maintained environment. Their value often comes from the service itself rather than from the software alone.
In those situations, SaaS is not simply a convenient delivery model. It is frequently part of the product's core design.
The software itself does not determine the best business model. Two applications with similar features may legitimately be offered in completely different ways depending on the customers they are designed for.
Other Products Naturally Fit the Self-Hosted Model
The opposite is also true. Some products do not rely on continuous shared infrastructure. They solve problems for individual organisations, internal teams or developers who prefer to keep complete control over their own environment.
Typical examples include:
- internal business systems;
- client management tools;
- financial applications;
- documentation platforms;
- developer tools;
- white-label products;
- industry-specific business software.
These applications may continue running successfully for years with only occasional updates. They can often be customised more extensively than SaaS products because the customer controls the entire environment.
That flexibility is one of the reasons I chose the self-hosted model for my own products. My goal was never to compete with SaaS platforms. I wanted to create applications that people could adapt, extend and integrate into their own infrastructure without depending on my servers remaining online indefinitely.
Perhaps the Debate Is Asking the Wrong Question
Discussions about self-hosted software and SaaS often become surprisingly emotional. Supporters of one model sometimes describe the other as outdated, expensive or fundamentally flawed.
After spending time building products and thinking about how they fit into a realistic business, I have become less convinced that there is a universal winner.
The more interesting question is not whether self-hosted software is better than SaaS.
It is whether the chosen model matches the promises the creator can realistically make and the expectations the customer reasonably has.
A large software company with dedicated infrastructure engineers, customer support teams and around-the-clock monitoring may be perfectly suited to operating a SaaS platform. An independent developer working alone may be better served by building software that customers can own and operate themselves.
Neither approach is more honest or more modern. They simply solve different problems.
The technology may be similar. The relationship between creator and customer is what truly changes.
Looking Beyond Self-Hosted vs SaaS
When I first started thinking about this topic, I assumed I was choosing between two ways of delivering software. Over time, I realised that I was really choosing between two different kinds of businesses.
Self-hosted software and SaaS can sometimes produce applications that look almost identical. Customers may click the same buttons, complete the same tasks and achieve the same results. What differs is everything happening behind the interface: who operates the infrastructure, who accepts the ongoing responsibility and how ownership is shared between creator and customer.
That is why I do not think the discussion needs a winner.
SaaS has transformed the software industry because it removes enormous amounts of complexity for customers and enables products that simply could not exist without continuous online services.
Self-hosted software remains equally relevant because ownership, flexibility and independence continue to matter for many organisations, developers and independent creators.
My own products follow the self-hosted path because it reflects the kind of business I can realistically build on my own. Someone else, working with a different team, different customers and different goals, may reasonably reach the opposite conclusion.
In the end, that may be the most useful distinction of all. Self-hosted and SaaS are not opposing technologies fighting for the future of software. They are different answers to the same question:
What kind of relationship should exist between the software, the person who builds it and the people who depend on it?
