Most teams reach for SaaS first, and often that’s the right call. But “rent it” and “build it” aren’t a moral contest — they’re a tradeoff between speed today and control tomorrow. This is how we think about that tradeoff, where renting wins, where it quietly costs you, and how to decide without guessing.
What you’re actually renting
When you subscribe to a SaaS product, you’re not just paying for features. You’re renting the data model, the export format, the pace of change, the pricing curve, and the company’s continued existence. That bundle is fine when the tool sits at the edge of your business — payroll, helpdesk, email. You don’t want to build those, and a generic product fits a generic need.
The problem starts when a rented tool moves to the center of how you operate. The thing that makes you money, the workflow your staff lives in eight hours a day, the data your customers trust you with — those are not generic. A SaaS vendor optimizes for the average of all their customers, which means your specific edge becomes a backlog ticket you can’t prioritize and a “feature request” you can’t schedule.
The lock-in tax nobody quotes you
Vendor lock-in rarely shows up as a single bill. It shows up as a slow accumulation of constraints:
- Data you can read but can’t really move. Many tools offer a CSV export, but not the relationships, history, attachments, and permissions that make the data useful. Getting out is a project, and vendors know it.
- Integrations you built on their terms. Every webhook and API call you wire up is leverage for them, not you. Re-pointing it later is real engineering work.
- Process shaped around their limits. Your team learns to work around the tool’s quirks. Those workarounds become your actual process, and they don’t come with you when you leave.
- Price increases you can’t refuse. Once switching costs are high, annual increases and new per-seat tiers are easy for the vendor and painful for you. The renewal email is where lock-in gets cashed in.
None of this means SaaS is a trap. It means the exit cost is part of the price, and it’s worth estimating before you’re three years deep.
Total cost over time, honestly
The pitch for SaaS is “cheaper than building.” For a year or two on a small team, that’s usually true. Over five to seven years, the math changes, and not always in the direction you’d expect.
A subscription is a cost that grows with your headcount and your success — more users, more seats, more usage tiers. Custom software is a larger cost up front that then flattens. Somewhere between year two and year four, the lines often cross. Where exactly depends on your seat count, how central the tool is, and how much the vendor raises prices.
We’ll be honest about the other side: custom software has costs SaaS hides from you. You own hosting, maintenance, security updates, and the occasional rewrite when a dependency ages out. A vendor amortizes that across thousands of customers; you don’t. So the real comparison isn’t “subscription vs. zero” — it’s “rising rent plus lock-in” vs. “build cost plus ongoing upkeep you control.” For a tool at the core of your business, the second column usually wins over time. For a tool at the edge, it rarely does.
When bespoke actually beats renting
We tell clients to build when at least two of these are true:
- The workflow is your advantage. If your way of doing the work is part of why customers choose you, a generic tool flattens it into something your competitors also have.
- The data is sensitive or central. Customer records, health or financial data, anything you’d hate to see governed by someone else’s privacy policy and breach history. Owning the data and where it lives is the point.
- You’re paying for a fraction of a product. When you use 15% of a sprawling platform and pay full freight — and bolt on three other tools to fill gaps — a focused build you own can be smaller, faster, and cheaper to run.
- The vendor’s roadmap and yours have diverged. You’re waiting on features that will never come because they don’t serve the average customer.
This is the work we do — custom software development where you end up owning the code and the data, with a clean source handoff rather than a deeper subscription. The goal isn’t to build everything from scratch. It’s to build the part that’s actually yours and rent the rest.
A middle path most people skip
You don’t have to choose all-rent or all-build. The durable pattern is to keep your core — your data and your differentiating workflow — under your control, and rent the commodity layers around it. Own the system of record; subscribe to the email provider. Own the customer-facing app; rent the payment processor.
Local-first software leans into this: your data lives with you, syncs when it needs to, and keeps working when a vendor’s servers don’t. It’s not the right shape for every product, but when data ownership and offline reliability matter, it removes a whole category of lock-in by design.
How to decide
Before you sign or build, write down three things:
- The exit cost. If you had to leave this vendor in two years, what’s the real effort to extract your data and rebuild the integrations? If you can’t answer, that is the answer — the lock-in is large and invisible.
- The five-year cost, both ways. Project the subscription with realistic growth and price increases. Compare it to a build plus ongoing upkeep. Don’t compare year one; compare the curve.
- How central it is. Edge of the business: rent, almost always. Center of the business: be very deliberate, because that’s where lock-in compounds and where owning what you run pays off most.
If you go through that and the build case holds up, we’re glad to pressure-test it with you — including talking you out of a build when renting is genuinely the smarter move. You can tell us about your situation, and we’ll give you a straight read on whether to build, rent, or do a bit of both.