The choice between licensing software and owning it affects your operational costs, your flexibility, your data, and your strategic options — often for years. It's worth understanding before you're locked in.
Every piece of software your business depends on sits somewhere on a spectrum from "fully rented" to "fully owned." Most businesses have a mix across their stack, often without having made deliberate decisions about where each tool falls or what the long-term implications of those positions are.
This post maps the spectrum, explains what you actually control at each point on it, and provides a framework for evaluating where different tools in your stack should sit.
The spectrum from rented to owned
Software arrangements don't fall neatly into two buckets — they exist on a continuum with meaningfully different characteristics at each point.
Pure SaaS subscription — You pay a recurring fee to access software hosted and operated entirely by the vendor. You have no access to code, no infrastructure responsibility, and no ability to modify behavior beyond what the vendor's configuration options allow. Examples: Salesforce, HubSpot, Slack, QuickBooks Online.
Licensed software (on-premises) — You purchase a license to run software on your own infrastructure. You own the right to use the software, but not the underlying code. Updates may require additional licensing. You're responsible for hosting, maintenance, and operations. Less common than it used to be, but still prevalent in certain industries and enterprise contexts.
Open-source software, self-hosted — Software with freely available source code that you run on your own infrastructure. You can modify the code, but you're responsible for hosting, security, and operations — and for maintaining your modifications over time as the underlying project evolves. Examples: WordPress, Nextcloud, many database systems.
Custom-built software, owned — Software written specifically for your business, owned entirely by you. You own the code, you control the infrastructure, and you have complete flexibility to modify it. You're also entirely responsible for maintenance, hosting, and operations — or you contract those responsibilities to a partner.
Hybrid arrangements — Custom code built on top of platforms or frameworks that have their own licensing, hosting arrangements with vendors where you own the application but not the infrastructure, or SaaS products with data export capabilities that give you meaningful but not complete ownership. Most real-world software stacks involve hybrid arrangements.
What you actually control in each model
Control matters across several dimensions:
Feature development. With SaaS, you get what the vendor builds on their roadmap. Influencing their roadmap may be possible (through feedback, a large enough account, or a formal partner relationship), but it's not guaranteed. With custom-owned software, you build what you need when you need it.
Configuration and workflow. SaaS products offer configuration within whatever options the vendor has built. Some are highly configurable; others aren't. With custom software, the system can be designed around your actual workflow rather than adapted from a generic template.
Pricing. With SaaS, the vendor controls pricing. Per-user pricing scales with your team; feature tiers can force you into higher price points as your needs evolve; annual price increases are common. With owned software, your costs are infrastructure and ongoing development — they don't scale linearly with user count.
Availability. With SaaS, your software is available when the vendor's infrastructure is available. Outages, scheduled maintenance, and deprecations are outside your control. With owned software, you control the infrastructure and make availability decisions.
Integrations. SaaS products expose APIs and integration options within the limits the vendor chooses. Some are extensive; others are deliberately restrictive. Custom software can be integrated with any system that exposes an API, without those limitations.
Total cost of ownership: the comparison that matters
Upfront costs favor SaaS almost always. There's no development project, no infrastructure setup, no migration effort. You sign up, configure, and start using.
The comparison changes materially over time.
SaaS cost trajectory: Licensing fees continue indefinitely. Per-user fees increase as your team grows. Price increases occur at renewal. Feature requirements may force tier upgrades. Integration needs may require additional paid connectors. After several years, the cumulative spend on a SaaS product often significantly exceeds what custom development would have cost — with nothing to show for it as an asset.
Custom software cost trajectory: Higher upfront cost for development. Ongoing costs for hosting, maintenance, and ongoing development. But the cost structure doesn't scale linearly with users, the product evolves to match your needs rather than the vendor's roadmap, and the software is an asset on your books rather than an ongoing expense.
A simplified example: a SaaS CRM at $150/user/month for 20 users is $36,000/year. Over five years, that's $180,000 — plus any price increases plus any professional services costs plus any implementation consultant time. A custom CRM built for $80,000 with $20,000/year in ongoing maintenance and hosting costs $180,000 over five years — with an owned asset, no per-user pricing, and the ability to build exactly what your process requires.
The crossover point varies by organization size, the specific tools involved, and the complexity of customization needed. But the calculation is almost always worth doing with real numbers before defaulting to "SaaS is cheaper."
Vendor lock-in: what it is and how it accumulates
Vendor lock-in is the condition where switching away from a software product becomes disproportionately difficult, expensive, or risky — typically because of how deeply the product is embedded in your operations, how your data is structured, or how your processes have been adapted to work within the product's constraints.
Lock-in accumulates through several mechanisms:
Data format dependency. Your data is stored in the vendor's proprietary data model. Exporting it in a form that can be used elsewhere may be possible but requires significant transformation work — or may not be possible for certain data types at all.
Process adaptation. Over time, your team has adapted workflows to fit the software's constraints. When evaluating replacement options, you're not just comparing features — you're accounting for the cost of un-adapting those processes and adapting them to something new.
Integration dependencies. The software is connected to other systems in your stack. Replacing it requires rebuilding every integration, not just finding a replacement product with equivalent core features.
Institutional knowledge. Your team knows how to use this system. Switching requires retraining — and the institutional knowledge about edge cases, workarounds, and configuration details disappears with the platform.
Lock-in isn't inherently bad — strong products that are deeply embedded in operations often provide genuine value. The problem is when lock-in prevents switching even when a product is no longer serving you well. Evaluating lock-in risk upfront — and specifically evaluating data portability before you're in a situation where it matters — is the mitigation.
Data ownership and portability
Data ownership is distinct from software licensing but deeply entangled with it. A few principles worth understanding:
You almost certainly own your data contractually. Most SaaS agreements explicitly state that customer data belongs to the customer. This is different from data being practically accessible and portable.
Practical portability varies enormously. Some products make data export easy and complete — you can pull a full export in a standard format at any time. Others make it technically possible but operationally painful. Others have "export" features that produce incomplete data or formats that require significant transformation to be useful.
API access is not the same as data portability. Many SaaS products offer APIs that allow you to read your data programmatically. Building an export pipeline from an API is possible but requires engineering resources and ongoing maintenance as the API evolves.
What happens to your data when the vendor disappears. Startups fail. Products get discontinued. Large companies deprecate products that don't meet growth targets. What is the plan if the vendor you're relying on ceases to operate? For tier-one products like Salesforce or QuickBooks, this risk is low. For smaller vendors, it's worth understanding.
A framework for evaluating where a tool should sit
For any significant software tool your business depends on, these questions frame the decision:
How unique are your requirements? If your needs are standard — the kind served well by any tool in the category — SaaS is probably appropriate. If your requirements are specific to how your business works, the configuration limits of SaaS become more consequential.
How does the cost compare over a realistic time horizon? Model three to five years of SaaS costs against the fully-loaded cost of a custom alternative, including development, hosting, maintenance, and ongoing feature development.
What is the data portability situation? Before committing to a SaaS product for critical data, test the export process. Understand what format data comes out in and what it would take to migrate to another system.
What are the integration requirements? The more heavily integrated a tool needs to be with your other systems, the more the integration architecture matters — and the more switching costs accumulate over time.
How central is this tool to your competitive differentiation? Software that is directly tied to how you deliver value to customers is a stronger candidate for custom ownership than commodity back-office tools.
Written by
Chris Coussa
Founder, Day2 Innovative Technical Solutions