Frictionless SaaS Chapter 10: Data Lock-In and Network Lock-In

This is the tenth post in the Frictionless SaaS blog series. In Chapter 9 we covered the experiential retention levers — friction, consistency, speed, and information ergonomics. This chapter shifts from experience to structure: how to build retention moats that make leaving expensive even when users are mildly dissatisfied.

The Quiet Retention Weapon Most Teams Underuse

There are two kinds of retention. The first is the kind you earn every session — fast pages, clear UX, useful notifications, habits that stick. The second is the kind that accumulates silently in the background while users go about their work: Structural switching costs. When structural switching costs are high, a user can be mildly frustrated, actively shopping competitors, and still not leave, because the cost of leaving exceeds the cost of staying.

Chapter 10 is about two mechanisms that create these costs ethically: the Data Gravity Effect and the Network Lock-In Model.

The Data Gravity Effect

The more data a user has stored in your product, the harder it becomes for them to leave. A user with one month of data might migrate to a competitor for a compelling feature. A user with two years of data, custom schemas, historical trends, and business logic wrapped around that data will measure the switching cost in days of engineering work and the very real risk that something breaks in the process.

The key insight: data gravity isn’t a contract. It isn’t a cancellation penalty. It’s pure physics — the friction and risk of moving something heavy. That’s why it’s the ethical form of lock-in. Users stay because leaving is genuinely hard, not because you trapped them.

But data gravity only works when the data meets a specific bar. The chapter is explicit: trivial, generic, easily-recreated data creates weak gravity. Unique, business-specific, enriched, accumulated data creates strong gravity. The book breaks down exactly which categories of data qualify and which don’t, with examples from CRMs, analytics platforms, project management tools, design systems, and knowledge bases.

It also tackles the uncomfortable question every honest product team wrestles with: where’s the line between sticky and sleazy?

The book’s answer: users have a right to their own data. You should offer real export in real formats. But you are not obligated to build automated one-click migration tools for your competitors. That’s the ethical sweet spot — portability is possible, but the effort of actually moving is a legitimate retention lever.

The Network Lock-In Model

If data gravity creates personal switching costs, collaboration creates collective switching costs — and collective costs compound exponentially.

A solo user can churn with a single decision. A team of ten has to agree collectively, migrate shared data, retrain everyone, accept the disruption, and absorb the productivity hit of losing tribal knowledge. This is why collaborative products are structurally more retentive than single-player ones, and why enterprise software is sticky enough to survive years of mediocrity.

The chapter covers how network effects form inside a product and how they feed your retention engine for free:

• Shared activity creates return triggers. A designer changes a file → the PM is notified → they review and comment → the designer returns. Single-player products have to manufacture return reasons. Multiplayer products generate them as a byproduct of real work.
• Team investment dwarfs individual investment. A solo user might build a workflow. A team builds shared templates, automations, processes, permission structures, and institutional memory. When one person leaves the company, the team’s investment stays with your product.
• Frictionless invites are non-negotiable. If adding a teammate requires forms, approvals, or a setup dance, your product never crosses the solo → team threshold — and you never get the network moat. The chapter explains exactly how low that friction has to be.

The book also covers the design difference between products that are used by teams and products that are designed for teams. A document editor with a “share” button bolted on is not the same as a canvas designed from day one for simultaneous contribution. The retention difference is enormous.

Moats Are Measurable — If You Instrument for Them

Most teams don’t know how strong their switching costs are because they never measure them. The chapter introduces the specific metrics to instrument so you can see your moats forming (or eroding) in real time:

• Average data volume per account — and its growth curve over tenure.
• Active team members per account versus seats purchased.
• Custom configurations, templates, workflows, and automations created per account.
• Integrations connected per account — and which complementary tools in the user’s stack are connected.
• Percentage of the customer’s total team actually active in your product.

Why this matters: a customer with two years of data, seven active seats, and twelve integrations is structurally harder to lose than a customer with two months of data and a single user — even if the second customer has a higher NPS. Moat metrics are leading indicators of churn that NPS misses entirely.

Integrations: The Multiplier on Both Moats

Integrations amplify data gravity and network effects simultaneously. A standalone CRM is replaceable. A CRM wired into your email, calendar, support tool, accounting system, and data warehouse is a civil engineering project to remove. Every integration adds to the switching cost and every integration also makes your product more central to how work actually happens.

This is why successful platforms invest disproportionately in API design, integration marketplaces, and developer experience. It’s not just a developer-relations play — it’s one of the highest-leverage retention investments available. The chapter breaks down which integration categories create the most durable lock-in and which are essentially cosmetic.

Warning Signs: When Moats Are Eroding

Moats don’t fail suddenly. They erode quietly. The book calls out the specific early-warning signals that should fire alerts to your customer success team before churn is inevitable:

• A sudden drop in data input volume — often means they’ve started entering data somewhere else.
• Team member activity declining while seats stay constant — they’re moving specific workflows to a competitor.
• Integration counts flat or declining on accounts that should be expanding.
• A long-tenured customer whose custom-configuration count is unusually low — they never built the moat in the first place, and they’ll churn to the next shiny thing.

— Sho Shimoda

Based on Frictionless SaaS: Designing Products Users Discover, Adopt, and Never Leave (2026).