Escrow for app deals, explained (and why a screenshot isn't proof)
Vibes Crow3 min read
Two strangers on the internet have agreed on a price for an app. Now comes the genuinely hard part: who goes first? The buyer doesn't want to wire money for a repo they can't see yet. The seller doesn't want to hand over the keys before the money lands. This standoff is where most small app deals quietly fall apart — or worse, where one side gets burned.
Escrow exists to dissolve that standoff. Here's how it actually works.
What escrow is
A neutral third party holds the buyer's funds. The seller can see the money is committed and real, but can't touch it yet. Only when the agreed conditions are met does the escrow release the funds to the seller. Neither party has to trust the other — they both trust the process and the held funds.
It's the same mechanism that makes buying a house possible between strangers. App deals are smaller and faster, but the trust problem is identical, and so is the fix.
Why a screenshot isn't proof
Most informal app sales run on screenshots: a Stripe dashboard, an analytics graph, a bank statement. The problem is that every one of these can be fabricated in a browser's developer tools in under a minute — change the text, screenshot it, undo. Even when the numbers are completely real, the format is one a scammer uses too, so it carries no trust.
Proof isn't an image of a number. Proof is a live, read-only connection to the source of truth — the actual subscription data, the actual analytics — that the buyer (or an automated check) can verify directly. "I connected my revenue" and "I screenshotted my revenue" are worlds apart, and experienced buyers treat them that way.
What a verified handover checks
Escrow for software is only as good as the conditions it releases on. A wire transfer is a single yes/no event; transferring an app is a sequence, and each step should gate the release of funds:
- Repository transfer — the code is actually in the buyer's account, not just promised.
- Domain push — the domain moves to the buyer's registrar/control.
- Account and API-key rotation — credentials are rotated so the seller no longer holds the keys to what they just sold. This is the step casual deals forget, and it's the one that matters most.
- Working-deploy check — the app still runs after the move. A pile of files that doesn't deploy isn't the business the buyer paid for.
Funds release when the handover is verifiably complete — not when someone says "all done." That removes the messiest, most dispute-prone part of small deals: the gap between "paid" and "actually have a working product."
Who escrow protects
Both sides, which is the point:
- The buyer can't lose money to a seller who vanishes after the wire, or who "forgets" to rotate the credentials and keeps a backdoor.
- The seller can't get strung along by a buyer who takes the repo and stalls on payment, and gets the security of knowing the funds are real and committed before they hand over anything.
The friction escrow removes isn't paperwork — it's fear. When neither party has to go first on faith, deals that would have died in the standoff actually close.
The bigger idea
Escrow is one instance of a principle that runs through every safe app transaction: replace "trust me" with "here's the verifiable proof, and the money moves only when it checks out." Verified revenue, a real diligence report, and an escrowed, condition-gated handover are the same idea applied at three points in the deal — so that buying or selling an app stops being a leap of faith and starts being a transaction you can actually reason about.