Most founders picture the sale of their app ending with a signature. In practice the signature starts the part of the deal that is most mechanical and, oddly, most likely to stall. Neither side wants to go first: the buyer will not wire the money before they control the app, and you should not hand over the app before you are paid. Closing is the process that solves that problem, and knowing how it works keeps a done deal from drifting for weeks.
1. Escrow exists so nobody has to trust anybody
In most third-party app sales, the purchase price goes to an escrow service or an attorney-held escrow account rather than straight to the founder. The buyer funds the account, the escrow agent confirms the money is there, and only then does the founder start transferring assets. Once the buyer confirms they have received everything the agreement lists, the agent releases the funds. If a part of the price is held back for a period after closing, that portion stays in escrow under its own release terms.
2. The app is more than the store listing
Apple and Google each have a process for moving an app from one developer account to another, with their own conditions. The listing is only one piece. A buyer also needs the source code and repository, the backend (hosting, databases, a Firebase project or cloud account), the domain and website, the support email, and every third-party service the app relies on: RevenueCat or Stripe for subscriptions, AdMob or other ad networks, analytics, crash reporting, push notifications. Add any trademarks and the social accounts tied to the brand. A complete transfer list, written into the purchase agreement, is what the buyer will check off before approving release.
3. The usual order of operations
The details vary, but a typical closing runs like this. The purchase agreement is signed and the buyer funds escrow. The founder initiates the store transfers and hands over the code, the backend and the third-party accounts. The buyer gets an inspection period to confirm the app builds, the backend runs, revenue is flowing to their accounts, and nothing on the list is missing. Then the funds are released. One point deserves attention before signing: the revenue cutoff. App store payouts arrive in arrears, so the agreement should say plainly which period's revenue belongs to whom, and how any payout that lands in the wrong account gets settled.
4. What slows a closing down
The delays are almost always preparation problems. The developer account is in the founder's personal name and tied to their personal Apple or Google login. The app shares an account with other apps the founder is keeping. Backend services sit on a personal credit card, or nobody remembers which email owns the analytics account. A contractor wrote part of the code and never signed an IP assignment. Each of these is solvable, but each one found after the agreement is signed adds days, and a buyer waiting on a stalled transfer starts to wonder what else was missed.
5. The days right after release
Closing does not end your involvement. Most app sales include a transition period, often defined as a set number of weeks of support, during which the founder answers questions, helps with the first release under the new account, and introduces any partners. Rotate or hand over every credential so nothing still points at you. Then keep the paperwork: the purchase agreement, the transfer list, and the release confirmation from escrow.
The takeaway
The price is agreed in the negotiation, but the money moves at closing, and closing is a checklist. Map every account the app depends on, move them into a business name where you can, and agree on the transfer list and revenue cutoff before you sign. A prepared founder can close in days. An unprepared one spends weeks proving they own what they just sold.
