Write the Exit Plan Before You Buy an Email Tool

Every email software exit plan before buying starts with a question most buyers do not ask until it is too late: if this tool disappeared in eighteen months, what would I actually lose? The answer is measurable during a free trial, in about an hour, and it decides whether you are buying software or a dependency.

This post walks the criteria that actually matter for portability, gives you a scoring table for any two finalists, works one example end to end, lists the red flags that outweigh a strong score, and closes with an honest recommendation — including where AI Emaily is the wrong pick.

We build AI Emaily. The verdict names the reader we are right for and, more usefully, the reader who should read the recommendation and buy something else.

The short answer#

Write the exit plan while walking away still costs nothing. That is the trial week, before the credit card renews and before you have taught the tool anything worth keeping.

Five things decide it, in this order. Where does the mail physically live — a provider you already control, or the vendor's own infrastructure. Does the export run without a support ticket, in a format some other tool can open. What lives only inside the vendor's layer, and would vanish with the app. Who holds the OAuth grant, and can you revoke it at your provider in one click. What the terms actually say about a wind-down.

If items one, four and five hold up, the worst case is a weekend rebuilding rules and snippets — you keep your mail. If item one fails, a shutdown is a migration with a deadline attached. The rest of this piece is the version of those five you can hand to a teammate.

The criteria that actually matter#

Feature lists are the wrong axis for an exit plan. Every tool in this category can eventually add a keyboard shortcut or a summarise button. Portability is structural — it comes from the shape of the product, and the shape is hard to change once shipped.

The primary criteria are the ones whose failure costs money you cannot recover with a switch. The secondary criteria affect how painful the switch itself is.

• Where the mail physically lives. Two shapes exist. Either the tool reads a mailbox you already own — Gmail, Microsoft 365, Exchange, or standard IMAP — or the vendor hosts the mailbox and its infrastructure is the only place that copy sits. The first is recoverable at any time. The second is a migration project on the vendor's clock.
• What the export actually contains, and in what format. Self-serve from settings, no support queue, and readable by something other than the vendor themselves. MBOX, EML, ICS and CSV are portable. Documented JSON is a distant second. An undocumented ZIP is an archive, not a migration path.
• What lives only in the vendor's layer. Rules, snippets, templates, drafts, snoozes, scheduled sends, AI tags, thread summaries, Personal Context. This is the stuff you built inside the app that never left it, and it is what dies first in every shutdown on record.
• Who holds the OAuth grant. A standard Google or Microsoft grant, minimum scopes, revocable in one click at your account without contacting the vendor. If revocation requires a support ticket, you do not own the key.
• What the terms promise about a wind-down. A stated notice period, a data-deletion date, and an assignment clause that survives an acquisition. Most vendors publish none of this, which makes it common, not acceptable.

Two secondary criteria decide the cost of leaving, not whether you can leave at all. Read them after the primaries pass.

• What happens to your money if you cancel mid-term. Pro-rated refund, remaining seats, and whether the plan drops to a read-only tier or terminates outright. Team plans with annual invoicing bury more of this than monthly per-seat plans.
• Whether onboarding created dependencies you cannot cleanly undo. Custom-domain MX changes, calendar bridges, sending-domain warmup, alias forwarding. Each one is easy to add and takes days to unpick — worth naming in the plan before you enable any of them.

The scoring table#

Score each item pass, partial, or fail rather than adding up a number. One fail on where the mail lives outweighs four passes elsewhere, and a spreadsheet total will hide that.

A worked example: two finalists at a twelve-seat agency#

A twelve-seat agency is choosing between two products for shared client inboxes. Tool A is an AI-first mail client that connects to each user's Google or Microsoft account. Tool B is a hosted collaborative inbox that provisions its own addresses on a subdomain the agency points at it, with a proprietary shared-thread model.

Feature-wise they look similar. On the exit plan they are not the same product at all.

The verdict is not that Tool B is worse. It is that the two carry structurally different exit costs, and the agency should price that difference in before the meeting.

Tool A fails item 3 partially and passes everything else — the worst case is a weekend rebuilding rules. Tool B fails items 1, 4 and 5 outright, and item 3 is the entire reason they bought it. If Tool B disappears, the agency is doing an MX cutover and telling every client their support address changed, on the vendor's clock. That may still be worth it for the collaboration model, but only if the plan for that day already exists.

Red flags worth more than the score#

Some signals outweigh whatever the checklist says, because they change the reliability of the answers themselves.

• The export is available on request. Anything routed through a support queue is not something you can rely on in the final week of a wind-down.
• The terms are silent on discontinuation. Silence is not a promise — it is what you will be holding when it matters.
• The mailbox is vendor-hosted with no IMAP or Exchange option. That is the expensive failure mode. No feature list on the marketing page compensates for it.
• An acquisition just closed and the roadmap went quiet. Postbox was acquired and discontinued in the same October 2024 announcement. Skiff was acquired in February 2024 and the service ended that August.
• The team's public attention has moved to a different product. That is not a shutdown and should not be reported as one, but it is exactly the signal a portability plan needs to catch early.
• The tool asks for a custom-domain MX change on day one. MX changes take an afternoon to make and days to reverse cleanly. Do not enable one until the rest of the plan is written.

What we'd pick and why (honest)#

AI Emaily is a genuine candidate on this exercise, and we are going to be specific about the reader it fits and the reader it doesn't. The whole point of the exit-plan discipline is that a recommendation is only useful if it names both.

On the seven-point table above, AI Emaily passes items 1, 4, 6 and 7, is partial on item 3, and is honest about item 5. Your mail lives in your own Gmail, Outlook, iCloud, Fastmail, Proton, or standard IMAP mailbox — we never host it. Disconnect us and every message is still with your provider that afternoon. The OAuth grant is a standard Google or Microsoft grant, revocable at your account in one click without contacting us. Export runs from Settings then Account and produces a downloadable JSON archive of settings, rules, templates, Context, and stored metadata. Cancellation is pro-rated. Onboarding does not ask for MX changes on day one — the mailbox stays where it is.

Where we are partial on item 3: our export is JSON, and no other client currently imports it. Rules and Context are a rebuild by hand if you leave. That is honest and it is a real cost. Item 5 is our honest one: we do not publish a specific wind-down notice period, and most tools in this category do not either — which makes it common, not acceptable. We are an independent, founder-led company; there is no parent that could retire us as a side bet, and none that could absorb us either. That is higher variance, not lower.

Where we are the wrong pick. If you want a fully local, offline-capable archive of every message in a native Swift or AppKit binary, a client like Mimestream will beat us on that dimension — we ship an Electron shell around the web interface and offline is partial by design. If your team has already built a Gmail-native shared-thread workflow around Missive or Front, our unified inbox is a different model and porting the assignments is real work; buy those instead. Compare packaging on aiemaily.com/pricing — free tier terms, per-seat tiers, and current numbers are all listed there — and start the export test on any trial before day seven if you want the exit plan complete before the card renews.

We build AI Emaily. That disclosure exists because a page that recommends us should say so plainly. The homepage is at aiemaily.com and the trial is on Pro or Autopilot for seven days, card required, zero charge if cancelled before day seven. There is no permanent free tier — we are a paid product with a trial, and a real exit plan should treat us the same way it treats every other paid option.

Turn the plan into a page a teammate can execute#

The last step is boring and the one that matters. Write the exit plan down in the same place your team keeps runbooks, before you sign anything. Six paragraphs is enough.

1. 1

   Where the mail lives, in one line

   State the provider or the vendor by name. A future teammate reading this in a hurry needs to know what disconnecting looks like without opening the app.

2. 2

   How to run the export

   The exact settings path, the file formats, roughly how long it takes, and where to save the download. Include a note on link expiry if the vendor's download URL is time-limited.

3. 3

   What the export does not contain

   The vendor-only layer, item by item. This is the rebuild list, and it is what people forget on the day.

4. 4

   How to revoke access

   The exact URL for your Google or Microsoft account, the entry name to look for, and a note on any IMAP app-specific passwords still to be removed.

5. 5

   What the terms promise

   Paste the relevant clauses — notice period, deletion date, assignment. If the terms change later, this snapshot is the version you agreed to.

6. 6

   The rollback

   One paragraph naming the fallback tool and the first three commands or clicks that get the team back to a working inbox. If it takes more than a paragraph, the rollback is not real yet.