Design the exit first

Most software is designed to make leaving hard.

Switching costs are a business strategy. Export your data, if you can find the button. Cancel, and watch your history disappear.

Some background: At AI4Love, we published the Raiser’s Edge chapter of our AI governance guide this week. The guide asks what an intelligence layer should be allowed to do with a nonprofit’s system of record.

Constituent records, gift history, event registrations. A database team built trusted processes around those records over years of careful work.

So the design question is not, “How much access does an AI system need?”

The better question is, “What stays out of reach, and how quickly does access end?”

The answers we committed to:

Read-only by architecture. OAuth 2.0, read access only. We never create, modify, or delete a record. Not a profile, not an action, not a gift, not a registration.

Payment data stays out of reach entirely. Gift entry and receipting work exactly as they do today.

Access ends whenever the organization revokes the connection. After a 90-day exit window, AI4Love deletes the working base. The organization keeps a nightly-synced copy of every record and insight, owned outright and retained after cancellation.

The design lesson: a promise under your control is worth more than a promise you have to take on faith.

Reversibility is the feature. Design the exit first.

The full guide is free. The guide includes the ten questions worth asking any AI vendor. Us included. Our answers are public.

What would your product look like if you designed the exit first?