When buying SaaS is the wrong move

Buying SaaS can be the wrong move — fast

Many purchase decisions start with a single requirement — 'we need team chat', 'we need a shared workspace' — and end with a vendor contract that grows more costly and more rigid each year. Seat-based pricing, hidden renewal tiers and per-feature add-ons turn a seemingly inexpensive subscription into a recurring line-item that compounds as headcount or usage grows. If you recognise any of the signals below, buying a standard SaaS subscription is likely the wrong financial move for your organisation.

Four clear warning signs

Cost scales directly with staff or accounts. If the vendor charges per seat and your headcount is volatile or growing, your bill will compound predictably — and painfully. Vendors have made seat-based billing the default for collaboration tools. Our catalogue shows many seat-based products (for example Slack, Figma, Notion, Airtable, Trello). These are useful but expensive when every new hire adds a monthly fee.
Feature gating or storage limits force upgrades. Free plans often appear generous at first, then hide retention windows, API limits or collaboration features behind paid tiers. That makes the free tier a poor long-term choice for regulated or fast-growing teams.
Renewal pricing is a known step-change. Some vendors publish an ‘entry’ price and a higher renewal or enterprise price. If you see a significant renewal uplift in vendor docs, the math for years two and three is different from the sales pitch in year one.
The capability you need is non-differentiating. If the software solves a common operational problem (chat, task boards, file sync) and does not create competitive advantage, paying escalating recurring fees is worth questioning — commodity needs are often better met by lower-cost alternatives.

How these traps actually work — short, concrete examples

Seat-based billing is simple to sell and predictable to a vendor, but it transfers growth risk to buyers. Published vendor pricing pages make this explicit: most collaboration platforms list per-seat or per-user prices as their normal model, which means your bill moves in lock-step with headcount. When a vendor also restricts long-term message history, integrations or API rate limits to paid tiers, the only routes left are accept higher fees or accept degraded functionality. These are structural problems; they are visible on vendor pricing pages and in vendor announcements. For example, Figma and other vendors publish seat and billing changes on their pricing pages and update notes. figma.com

Four alternative strategies and when to pick each

1) Negotiate and redesign how you buy

When to use it: you want the vendor but not the runaway cost.

Ask for pooled or floating licences, not per-seat charges — this works when many users are occasional.
Lock renewal price and feature set in a multi-year agreement, or buy a larger annual block at a discount. Ask the vendor to map seat tiers to real usage metrics and include a quarterly reconciliation clause.
Buy only what teams actively use; force a quarterly 'license hygiene' review so dormant accounts are reclaimed before they auto-renew.

Negotiation may not remove the vendor’s long-term exposure, but it buys predictability — a legitimate goal when you are trying to budget for growth.

2) Substitute with low-cost or flat-rate alternatives

When to use it: your need is functional, not strategic.

If a task board, visual editor or shared workspace is not your secret sauce, choose a product with a flat-rate model or a very low entry price. Our catalogue contains examples you can compare directly — for some teams a flat-rate tool is cheaper at scale than a seat-based equivalent. Consider whether a feature parity trade-off is acceptable; often you only need a subset of the vendor’s capabilities.

3) Self-host open-source alternatives (or use a hosted community edition)

When to use it: compliance, long-term cost control, or predictable scale matter.

Open-source projects and self-hosted vendors let you pay once (hosting, maintenance) instead of per-seat forever. For team chat, projects such as Mattermost, Rocket.Chat and Matrix-based solutions are widely used as Slack alternatives; they let organisations retain message history, control retention policies and avoid per-user recurring fees. Community comparisons, vendor datasheets and multiple recent guides show teams still choose self-hosting for predictable costs and data control — but do not underestimate the engineering and operational burden. Self-hosting replaces vendor subscription spend with hosting, maintenance and upgrade work, and those costs must be budgeted and measured against vendor proposals. ossalt.com

4) Build a focused in-house solution (only when the functionality is core)

When to use it: the capability is a source of differentiation, or off-the-shelf options cannot meet critical security, latency or integration constraints.

Several consultancy and industry frameworks recommend treating build-versus-buy as a question of whether the software encodes competitive advantage; if it does, build. If it is a commodity, buy. Thoughtful frameworks from consulting and practitioner groups explain how to weigh total cost of ownership, time-to-market and vendor lock-in over a multi-year horizon. Building is expensive and slows you down initially, but it can reduce recurring fees and give you complete control over future changes. Use a five-year TCO model and include operations and upgrade costs — many organisations under-estimate the run-rate of an in-house product. gartner.com

How to decide, step by step

Measure: capture current usage — active users, integrations used, API calls, and storage. If 30–40% of seats are inactive or rarely used, you already have a negotiation lever.
Classify: is the capability strategic (differentiates you) or commodity (internal productivity)? If commodity, prefer the cheapest adequate solution.
Model: calculate five-year TCO for three options — buy, self-host, build. Include staff time, hosting costs, security/compliance and upgrade cadence.
Pilot: if self-hosting or building looks cheaper on paper, run a 3–6 month pilot to measure real support and ops effort before migrating everyone.
Decide with an escape hatch: when buying, insist on short pilot contracts, usage audits and a clear off‑ramp to avoid lock‑in surprises.

Practical examples — what companies actually do

Large organisations with strict data residency or retention policies often self-host chat and document platforms to remove per-seat line-items and to keep long-term archives; many independent guides and vendor comparisons from 2025–2026 document migrations from public SaaS to self-hosted alternatives for these reasons. For fast-growing startups, the common pattern is to tolerate a SaaS bill early, then re-evaluate at a defined headcount threshold (for example at 50–150 employees) and move to negotiated enterprise agreements or self-hosted solutions if costs balloon. These behaviours are seen in community migration guides and vendor case studies. techriseups.com

Checklist before you sign

Does the vendor publish renewal pricing or renewal terms? If not, ask for them in writing.
Can you get floating licences or a pooled user model?
Are integrations, APIs and data export available on the plan you are buying?
What is the true five-year cost if headcount doubles?
Is there an easy off‑ramp (data export formats, SSO disconnect) should you need to leave?

Conclusion: buying is rarely 'wrong' — it's about choosing the right buy

Buying SaaS is the correct choice most of the time, but the wrong plan, the wrong model or the wrong vendor can make that purchase costly. If your need is undifferentiated and your organisation is mature enough to manage the ops cost, a self-hosted or flat-rate alternative will often be cheaper over time. If the software encodes competitive advantage, build. And when you do choose to buy, negotiate terms that match how your teams actually use the product and keep a disciplined review cadence so the contract grows only when value grows.

“Treat SaaS purchases as ongoing operating decisions, not one-off projects.”

When buying SaaS is the wrong move — and what to do instead