AStarted by AXIS Editorial
The purchase agreement gets the attention; the transition terms determine whether your next three months are a handover or a hostage situation. What buyers of micro AI apps actually expect after the wire clears, what's negotiable, and where sellers get surprised:
The standard shape at micro scale
A defined support period — commonly 30-90 days of seller availability for questions, handover sessions, and "where does X live" archaeology, at a stated intensity (hours-per-week caps are your friend and absolutely standard to request). Transfer execution — the item-by-item asset movement the structure thread described, which happens during transition: accounts, domains, credentials, customer notifications, the DNS cutover. And knowledge transfer — walkthroughs of the runbook, the deployment path, the support patterns, and (per the AI-authorship reply in the Investors category) the development process itself: for AI-built apps, teaching the buyer your prompting-and-review workflow is now routinely a named transition deliverable.
What buyers are actually buying with the transition
Continuity insurance. Their nightmare is the asset degrading in the gap between your knowledge and theirs — customers churning at the ownership seam, the deploy that only you knew was fragile, the model-provider quirk your muscle memory routed around. Every transition term traces back to that fear, which is the negotiating insight: documented operations shrink the transition ask, because the runbook, fact sheet, and build log this forum prescribes are the continuity insurance, pre-purchased. Sellers with the artifact stack negotiate 30-day/low-hours transitions; sellers without negotiate 90-day/on-call ones — the documentation discount, again, now denominated in your post-close weeks.
The negotiable dimensions, with market-normal ranges
Duration and intensity: state both — "up to 5 hours/week for 45 days, then best-efforts email for 45 more" beats "reasonable assistance" (undefined assistance expands to fill buyer anxiety). Compensation for overage: the base period is priced into the deal; hours beyond it should have a stated rate — this single clause converts scope creep from your problem into their invoice. Channel and response expectations: async-first with defined response times; standing calls only if scheduled; no pager. The consulting-agreement upgrade: buyers sometimes want more — months of part-time involvement, feature completion, growth handoff. That's employment wearing transition clothes: price it separately, paper it separately, and decide whether you want it separately (many sellers' honest answer post-close is no, and the deals accommodate that when it's said early).
The non-compete, which travels with the transition
Expect one; at micro scale the reasonable shape is narrow — the app's specific niche, 2-3 years, defined geography-or-market — protecting what they bought without foreclosing your career (you're an AI-app builder; you'll build again — the clause should let you). The overbroad ask ("anything in AI") appears regularly and negotiates down routinely; counsel review is the red-flags-thread advice at its most applicable. The subtle one: non-solicitation of the customers — near-universal, fine in principle, check that its definition doesn't accidentally cover your next product's organic overlap.
The seller's transition checklist, before closing
Credentials inventoried for handover (the password-manager migration is a closing-day task — rehearse it); customer-notification draft agreed with the buyer (who says what, when — the ownership announcement is a churn-risk event both sides should stage-manage); your personal dependencies unwound (the app's accounts off your personal email, phone numbers, 2FA devices — the transfer-blocker audit); and the escrow schedule's interaction with transition milestones understood (some agreements tie releases to transition completion — know your definition of "complete").
Sellers who've been through the seam: what did the transition ask that nothing warned you about? A field report starts a thread on GitHub Discussions (the link is at the foot of this page).
Follow-up question: "The customer-notification event — what does good stage-management actually look like? My users bought from me, and I'm dreading the announcement."
The churn-risk mechanics first, so the staging has a target: ownership-transition churn concentrates in the announcement fortnight and correlates with surprise and service anxiety, not with the fact of the sale — users leave when the announcement reads as ending ('the founder is gone') rather than continuity ('the product persists, improved'). Stage-management that works, per marketplace transition guides: (1) joint announcement, seller's voice leading — your name carries the trust; spend it on the buyer's behalf ('I chose them because...'), with the buyer introduced as continuation, not replacement; (2) timing after transfer stability — announce once support, billing, and the product are demonstrably steady under new operations, never during the cutover itself; (3) concrete continuity commitments in the announcement — pricing honored, data handling unchanged (or changes stated), support channel identical: the specific anxieties, pre-answered; (4) the personal-relationship tier handled personally — your handful of oldest/largest customers get individual notes or calls before the broadcast; they're the churn risk with names, and they remember being told first. And the honest reframe for the dread: the announcement done well is your last act of service to those users — the sellers who ghost at transition (it happens) are the ones whose users' trust was actually betrayed.
Follow-up question: "'Best-efforts email for 45 more' — what happens when the buyer pings me in month 8 with a production emergency? Where does obligation actually end?"
Legally: where the agreement says — which is why the defined-endpoint drafting matters ('transition assistance concludes [date]; thereafter seller has no support obligation') and why the overage-rate clause should survive the transition window (month-8 emergency, at your stated consulting rate, at your discretion — the clause converts awkward into optional-and-priced). Practically, plan for month-8 pings; they split three ways: the two-minute answer (where's the config for X — most sellers just answer; goodwill is cheap and the reference call the buyer gives your next sale is real), the real engagement (scope it at the rate, or decline — both are clean under the drafting above), and the pattern (recurring emergencies signal the transition failed or the buyer under-resourced — engaging further is rescuing their purchase unpaid, and the kind reframe is pointing them at hiring: 'you need an operator; here's the runbook section and what to look for'). The drafting principle underneath: obligations end by date, relationships end by choice, and the agreement's job is making sure only the second one is open-ended.
One transition step specific to this platform worth documenting: the verification handover. The PAID connection and its accumulated Passport history transfer with the app (the history describes the app's revenue — it's part of what was bought), which means the buyer inherits a live verified-history clock already running — and their incentive to keep routing revenue through the verified rail is the same one you had: their eventual exit. Two consequences sellers should know: first, your verified history survives you as evidence — the app you sell with 30 months of Passport data remains a more-provable asset in the buyer's hands, which is part of what they paid your premium for; second, the transition checklist gains a line — the PAID account handover is a first-class transfer item with its own authorization steps, not an afterthought under 'misc accounts.' We've made that handover a documented path on the PAID side for exactly this reason. The platform's compounding thesis, completing its loop: verifiable history isn't just how apps sell better — it's part of what gets sold.
Follow-up question: "The consulting-agreement upgrade — the buyer wants me 10 hours/week for six months to 'finish the roadmap.' The money's actually good. What's the trap I should be seeing?"
Three traps, in the order they usually spring: (1) the earnout-in-disguise problem — check whether any deal consideration is contingent on the consulting period's outcomes ('completion bonuses' tied to roadmap delivery are earnout mechanics with your continued labor as the trigger, and micro-scale earnouts have a deservedly bad reputation: you'd be betting deal value on execution inside someone else's company, without control — the red-flags-thread instinct applies fully); (2) the motivation cliff — six months of roadmap work for a product you no longer own, after the psychological completion of a sale, is a documented burnout-and-resentment shape; sellers consistently report the work feeling different on the far side of the wire, so price it at rates that respect that, not at your pre-sale founder-passion rates; (3) the next-thing crowding — the opportunity cost isn't the hours, it's the divided head: your next build (or the non-compete-shaped rest) starts six months late. None of these makes the answer no — good money for defined work with a clean endpoint is sometimes exactly right — but the clean version has: separate agreement, fixed scope with acceptance criteria (not 'the roadmap' — named deliverables), no deal-consideration contingency, your rate honestly loaded, and an exit clause both directions. If the buyer resists that structure, what they wanted wasn't consulting — it was a retained founder at consultant prices, and that product isn't for sale.