SaaS prices rose 12.2 percent in 2024, a rate several times higher than general inflation across many developed economies. Most organizations signed those renewal contracts anyway. Here is why that happened, and what the alternative actually looks like.
Think about your office space. If you rent, you pay monthly, follow the landlord’s rules, and adapt when they raise the price or decide to renovate. If you own, you carry the maintenance burden, but you also control what happens inside the walls. You can knock down a partition. You can stay as long as you want. The building does not disappear when you stop writing checks.
Software works the same way. And a remarkable number of organizations, from early-stage startups to large institutions, are renting without fully understanding what they gave up to do so.
According to the Vertice SaaS Inflation Index, software prices increased 12.2 percent in 2024 alone, against a general inflation rate of around 2–3 percent across many developed economies.
SaaS costs now run roughly $9,100 per employee annually in many mid-size and enterprise organizations, up nearly 15 percent over two years. Software has grown from roughly 13 percent of IT budgets five years ago to about 21 percent today in many organizations. Vertice research found that in some companies, corporate software spending has surpassed employer contributions to employee healthcare.
Switching vendors, meanwhile, carries costs that often outweigh the financial case for moving. Lock-in accumulates contract by contract, renewal by renewal, until switching becomes more expensive than staying. For many organizations, that moment may already have arrived.
This piece is not a polemic against Software-as-a-Service (we ran our company this way for many years). SaaS tools are popular for genuine reasons, and for many organizations, renting is the right call.
But it should be a call.
A deliberate decision made with clear eyes, not a default that accumulates through inertia and peer recommendation matched with how the organization operates rather than forcing the business into predefined workflows.
What It Means to Rent
When you subscribe to most scheduling tools, CRMs, project management platforms, or event registration systems, you are renting. You are paying for access to a platform that someone else owns, maintains, and makes product decisions about. The advantages are real.
Low barrier to entry.
Most SaaS products are running in days, not months. Predictable costs, at least initially. Managed infrastructure, with security patches, uptime, and backups handled by the vendor. For organizations without dedicated technical staff, these are not trivial benefits.
The tradeoffs compound over time in ways that are not always visible at the point of decision.
Your data architecture belongs to someone else.
How your data is stored, structured, and exported is the vendor’s decision.
Migrating later is painful at best, particularly when data is held in proprietary formats that require specialized tools to extract.
Customization has a ceiling.
You can configure what the vendor allows, and if your needs fall outside their product roadmap, your options are limited.
Switching costs keep organizations from doing so.
Deep technical integration, data migration complexity, staff retraining, and contract penalties all create friction that routinely outweighs the financial case for moving.
According to Vertice, nearly three-quarters of software vendors raised prices in 2023. Salesforce’s Sales Cloud Unlimited tier has roughly doubled in price over the past five years. Some vendors bundle price increases with new AI features, which customers can’t always opt out of.
What It Means to Own
Open source software is publicly available code that anyone can use, modify, and distribute. When you implement it, you are not licensing access. You are deploying software that belongs to a community, not a corporation.
The structural advantages are significant.
Open source projects typically do not charge per-seat licensing fees.
You pay for hosting and implementation, not per-seat access. For organizations that scale up users or transactions over time, this is a fundamentally different cost curve.
You control your data and how it is structured.
Customization is real, not simulated within limits someone else set.
There is significantly reduced software lock-in.
If your implementation partner raises prices or closes, your software does not disappear. The code exists independently of any single vendor relationship.
The tradeoffs are equally real.
Implementation requires more upfront work.
Ongoing maintenance does not manage itself. Not all open source projects are equally healthy or sustainable, and evaluating a project before committing is its own skill.
Support looks different.
You are working from documentation, community forums, and your implementation partner rather than a help desk.
What the tradeoffs do not include is a quality problem.
The assumption that open source means lower quality has not reflected reality for decades.
Linux runs the vast majority of public cloud infrastructure. Android, the most widely used mobile operating system on earth, is open source.
WordPress powers approximately 43 percent of all websites. Kubernetes, PostgreSQL, and Apache underpin systems that handle billions of transactions daily.
The question is not whether open source can be enterprise-grade.
The evidence settled that long ago.
The question is whether the specific project you are evaluating is well-maintained.
There is also an irony worth naming.
Virtually all modern software, including the SaaS tools you are already paying for, contains open source components.
According to Black Duck, the overwhelming majority of applications today include open source components.
The vendor is packaging that code, adding a layer on top, and charging subscription fees for access.
In many cases, you are already depending on open source. You simply do not have the transparency or the ownership that comes with knowing it.
A Third Path Worth Understanding
There is a model that gets less attention than it deserves:
Open source software implemented by a vendor on your behalf.
An implementation partner deploys and manages an open source platform for you. You get the structural advantages of open source, no licensing fees, data ownership, real customization, significantly reduced software lock-in, while the partner handles the technical maintenance burden you may not have capacity for.
To be precise about what this is:
You are still paying a vendor, for implementation, hosting, and support. However, the software itself is not proprietary to that vendor.
If the relationship ends, you retain the software and your data.
Your customizations are built on a portable foundation, not locked inside a system that evaporates the moment you stop paying.
For organizations that want the structural advantages of ownership without requiring internal technical staff, this is often the most practical path.
| SaaS | Open Source (self-managed) | Open Source (vendor) | |
| Who controls pricing | Vendor | You | Partner (software cost is fixed) |
| Who owns your data | Vendor | You | You |
| Flexibility for customized features | Limited to vendor’s roadmap | Unlimited | Unlimited |
| Switching difficulty | High | Low | Low |
| Who handles maintenance | Vendor | You | Partner |
| Technical staff needed | No | Yes | No |
| Vendor dependency | High | None | Low |
| Cost to start | Low | Medium to high | Medium |
How to Think About Your Own Situation
There is no universally correct answer.
The right choice depends on your organization’s specific context.
A few questions worth sitting with before you decide.
What is your current technical capacity?
An organization with no technical staff and a 90-day timeline is in a different position than one with an internal engineering function. SaaS is often the right starting point. Open source becomes a more natural fit as operational complexity grows and internal capacity deepens.
How much does this software need to grow with you?
If you are evaluating a tool for a single program with stable requirements, SaaS is probably sufficient. If you are building infrastructure that will expand with your user base and integrate across systems, the ceiling on SaaS customization becomes a real constraint sooner than most people expect.
What does total cost of ownership actually look like?
Monthly subscription cost is not the right unit of analysis.
Total cost of ownership is, including the migration costs you would face if you ever wanted to leave.
That comparison changes the math in a significant number of cases, particularly for organizations whose user count or transaction volume is growing.
How important is data sovereignty to your operations?
Who owns the data generated by your programs?
Who can access it?
Can you export it completely and cleanly if you switch systems?
For some organizations these are governance questions as much as technical ones. They are worth asking before you are locked in rather than after.
Evaluating an Open Source Vendor
If you are exploring open source, evaluating the health of a project before committing is not optional.
Not all open source communities are equally active, well-maintained, or sustainable.
A few signals worth examining.
How recently has the codebase been updated?
Active projects show regular commits; stale projects may function but may not receive security patches.
How responsive is the community to reported issues?
The velocity of responses is a reasonable proxy for community health.
Is there a clear governance structure, a foundation, a lead maintainer, a sponsoring organization that has made a meaningful commitment to the project’s future?
What organizations are already using it, at what scale, and for how long?
One signal that is easy to overlook:
Does your implementation partner have actual investment in the open source project they are deploying?
A vendor who contributes to the community they are building on has aligned incentives. A vendor who is simply deploying someone else’s software without community involvement is in a more fragile position, and so are you.
A Decision, Not a Default
The data on SaaS pricing is not a reason to panic but it is a reason to pay attention.
Software inflation running well above the general rate of inflation appears to be a persistent trend. Organizations that evaluate their software decisions deliberately are often better positioned to manage that cost environment.
Many organizations do not design their software stack all at once. It often accumulates gradually, shaped by recommendations, search results, and the tools peers already use. The result can be infrastructure that reflects many small decisions rather than a single deliberate architecture.
Own or rent: either can be the right answer.
The difference is whether you decided, or it decided for you.