---
title: "Build the exit before your first customer asks for it"
url: "https://xubris.com/blog/build-the-exit-before-your-first-customer-asks"
description: "Adding an exit to a mature product means unpicking years of shortcuts. Designed in from the first commit, it costs little. Where customer state usually hides."
---

# Build the exit before your first customer asks for it

October 8, 2026·3 min read·Editorial team

The rear panel of a matte black cube computer with empty ports and one cable with a green connector leading out of the frame

A young software company lands the customer it has been chasing for a year. Procurement sends a questionnaire, and one section asks how the customer would leave: what they would receive, in what format, how quickly and with what help. The team looks at what exists. There is a CSV download on two screens. Customer settings are stored as serialised objects only the application understands. Files sit in a storage bucket under random names. Every workflow references the vendor’s internal ids. The honest answer is “we would build something when you asked”, and the team spends the next month building it instead of the features the deal was supposed to fund.

## The real cause

Nobody designs a product to be hard to leave in its first year. It becomes hard to leave through ordinary shortcuts: storing whatever is easiest, using internal identifiers everywhere, keeping configuration wherever the screen that edits it happens to write. Each shortcut is reasonable. Together they scatter the customer’s state across places no export was ever designed to reach.

Retrofitting an exit means finding every one of those places and agreeing a format for each, on a live system with customers on it. Designing it in means making the same decisions once, while the system is still small enough to hold in one head.

## Where customer state hides

**In configuration.** Workflows, rules, permissions and templates often matter more to a customer than their records, because they encode how the organisation works. They are also the part least likely to be exportable.

**In identifiers.** If every reference uses the vendor’s ids, an export is a set of puzzles. Stable keys that mean something, or at least a documented mapping, are what make data usable elsewhere.

**In files without context.** Attachments stored apart from the records that own them, under names that mean nothing outside the application.

**In history.** Audit trails, versions and the reasons for changes, kept in a separate table, a logging service, or nowhere.

**In derived state.** Scores, classifications and anything computed from the customer’s data, including the output of AI features. If the customer depends on it, they need either the result or the means to compute it again.

**In integrations.** Connections to other systems, set up by the customer and stored by the vendor, which have to be recreated by hand on the other side.

## What to do instead

**Make the export a product feature, not a support ticket.** One action that produces everything a customer has created, in documented open formats, without asking anyone.

**Use the export in your own work.** Test fixtures, staging environments and demos built from exported data. A format the team depends on stays complete; one used only on the way out rots.

**Treat configuration as data.** Store rules and workflows in a structured, versioned form that can be exported and imported, not as state behind a settings screen.

**Publish the schema.** Field meanings, allowed values, relationships. If a competent stranger cannot load the export into a database and understand it, the export is not finished.

**Offer a self-hosted path, even if few customers take it.** A product that can run on a customer’s own infrastructure is forced to keep its state explicit, and that keeps every other exit honest.

**Write the exit into the standard contract.** Format, timeframe, assistance and confirmation of deletion. A promise is easier to keep when the product already does what it says.

These are the first things we look at in [anything we build or back](https://xubris.com/) — not as compliance, but because a company [whose customers could leave](https://xubris.com/blog/we-only-back-companies-you-could-leave) has to keep earning them, and that pressure tends to produce better products. The buyer’s side of the same question is in [an export you have never restored is not an exit](https://xubris.com/blog/an-export-you-have-never-restored-is-not-an-exit).

## A test you can run today

Create a fresh account in your own product and use it for an hour the way a real customer would: add records, change settings, upload files, connect another tool. Then export everything the product lets you export, and try to rebuild that account in an empty instance using only the export and your public documentation.

Write down every step that needed a database query, an internal tool or a developer’s memory. That list is the exit your customers do not have yet — and today is the cheapest it will ever be to build.

-   product design
-   data portability
-   architecture
-   startups

## Keep reading

-   [An export you have never restored is not an exit](https://xubris.com/blog/an-export-you-have-never-restored-is-not-an-exit)
-   [Lock-in is often a financing decision, not a product one](https://xubris.com/blog/lock-in-is-often-a-financing-decision)