On 12 September 2025, the EU Data Act took effect and forced SaaS vendors serving European customers to strip switching barriers out of their contracts, honor a two-month exit notice, and hand over customer data in a usable format. For once, the fine print became the story. And it's a useful reminder that the clause most founders skim when they sign up, the exit clause, is often the one that decides years later whether they can commission something custom.
Stacking SaaS is pitched as flexibility. The reality, when a founder finally goes to leave, is a stack of assumptions that fall apart on contact. When Small Business Coach ran the numbers on subscriptions versus a custom build, the cost crossover was only part of the story. The exit terms buried in each contract shaped the answer just as much. Here are the myths worth breaking before your next renewal.
Myth: You Can Leave Any Time You Want
The subscription page says month-to-month. The signed order form says otherwise. Most SaaS agreements auto-renew on the anniversary date unless you give written notice inside a narrow window, and plenty of founders learn this the day after the renewal fires.
The right to leave is not the same as the ability to leave. Even when the contract permits termination, the operational cost of exiting, pulling data, retraining people, rewiring integrations, is what holds you in place. Read the notice window and the renewal cadence before you read anything else.
Myth: Your Data Is Your Data
Ownership and portability are two different things. You usually own your records. Whether you can pull them out in a form another system will accept is a separate question that the exit clause is supposed to answer, and often does not.
Watch for three specific things in the termination section:
- Export format. A PDF dump or a screenshot archive is not portability. You want structured, machine-readable output, CSV, JSON, or a documented API, that another tool can ingest without a rebuild.
- Access window. Some vendors give you thirty days after termination to retrieve data. Others cut access the moment the term ends. If your migration takes longer than the window, you're negotiating from a bad position.
- Deletion on request. A clear obligation for the vendor to erase your data after export protects you downstream, especially if the vendor is later acquired or breached.
Law firms that review these agreements for a living, like the team at Morgan Lewis, flag data retrievability and vendor deletion as the two provisions buyers most often let slide, and most often regret.
Myth: Stacking Subscriptions Keeps You Nimble
Each tool feels cheap on its own. The trouble is the connective tissue between them. Every time you add a fifth or fifteenth app to the stack, someone on your team writes, buys, or babysits the glue that makes it talk to the other four. That glue is a system, and nobody put it on the org chart.
The symptom founders feel is a monthly invoice that keeps growing while the work gets harder. Reports get exported and re-imported. Fields get mapped by hand. One person becomes the human API between two products that were supposed to save you time.
At some point, the per-seat, per-tool bill catches up with the fixed cost of owning something built for your process, and the switching friction baked into each contract makes the arithmetic worse.
Myth: Custom Software Locks You In Worse Than SaaS
This one has it backwards. When you own the code, the schema, and the hosting, you also own the exit. There is no anniversary date. There is no vendor deciding to sunset a product line, push through a renewal price hike, or route your data through a subprocessor you never approved.
Custom is not magic. It comes with its own maintenance bill and its own decisions. But the lock-in profile is fundamentally different: your dependencies are on infrastructure you can move and on engineers you can replace, not on a single vendor whose roadmap is now your roadmap.
Myth: A Build Is Only Justified When SaaS Gets Expensive
Cost is the easiest signal to see, so it's the one founders lean on. It's also the least reliable. A build is justified when the SaaS stack has stopped shaping itself around your business and started making your business shape itself around the SaaS.
Three questions cut through the noise:
- Is the workflow a competitive advantage, or a commodity? If the process is how you win, pricing logic, routing, an underwriting rule, a proprietary intake, you shouldn't be renting it.
- Are you paying to work around the tool? If the highest-value hours on your team go to reconciling exports and patching integrations, the tool is now a tax.
- Can you get your data out in a shape you can use? If the answer is no, the decision to leave will eventually be made for you, on the vendor's timeline.
None of this argues for ripping the whole stack out. Email, payroll, video calls, and the rest of the commodity layer belong in SaaS. The case for a build is narrower and sharper: the one or two workflows that are genuinely yours, that the vendor keeps almost fitting, and that you would rather own than rent for the next decade.
