The 30-Day Pre-Listing Checklist for Non-Technical App Sellers

You decided to sell. Good call.

Most pre-listing checklists for app sellers compress everything into a frantic final week. This one uses the full 30 days strategically.

If you need to move fast, the 14-day checklist covers the urgent sprint. But if you have a full month, that window is worth using to actually improve the asset. Thirty days is enough time to fix churn, build a revenue trend, create a proper transfer package, and list with the kind of clean metrics that push you into the 3x-5x SDE multiple bracket instead of the 2.5x floor. On a $1,500 MRR app, that gap is roughly $15K in sale price.

Here is the week-by-week plan.

Why the 30-Day Window Is Not Just About Cleanup

Most pre-listing guides treat the period before listing as damage control: rotate keys, write docs, take screenshots. That is the minimum.

The founders who get premium multiples use the full 30 days to actually improve the asset. AI-enhanced apps with strong retention are fetching 3x-5x annual SDE on Acquire.com in 2026. Standard micro-SaaS lands at 2.5x-4x. The difference is mostly observable metrics: churn rate, revenue trend, owner time per week. You can move those numbers in 30 days, if you start with the right things.

The plan below runs as four weekly sprints. Do them in order. Weeks 1 and 2 do the financial work; weeks 3 and 4 package it for buyers.

Week 1: Audit Your Numbers and Fix the Easy Wins

Start by getting honest about what your metrics look like to a buyer. Not to you, to a buyer.

Snapshot your revenue baseline. Export 12 months of Stripe data. Note your MRR for each of the past three months and write it down. A buyer looks at the slope, not just the number. A flat $1,200 MRR is more credible than a spike to $1,800 that just reversed. You want the trend you hand them to be stable or rising, so start measuring now.

Fix involuntary churn first. On average, 0.8% of annual revenue disappears from failed payments alone. Turn on Stripe Smart Retries if it is not already running. Set up the built-in Stripe dunning email sequence that catches failed payments at Day 1, Day 3, and Day 7. This is a one-hour setup that can recover 5-10% of churned MRR. You will see the impact in your Week 4 metrics snapshot, and buyers will see a 30-day trend that moved in the right direction.

Push one annual plan conversion. Offer your active monthly users a 15-20% discount to switch to annual billing. Even three to five conversions changes your churn picture. Buyers weight the annual-versus-monthly split heavily because annual contracts lock in revenue and reduce visible monthly churn. One outreach email to your most active monthly users is all it takes.

Reconcile your numbers. Pull your user count from the database, your MRR from Stripe, and your active user count from your analytics tool (Plausible, PostHog, Vercel Analytics, wherever). They should tell the same story. If they do not, find out why before a buyer does. Discrepancies during due diligence trigger doubt faster than small numbers do.

Kill stale users. Remove test accounts, dev users, and anyone on a frozen free trial from your active counts. Inflated user numbers that do not reconcile to paying customers destroy credibility faster than honest small numbers do. A listing with 47 real paying users beats a listing with "312 users" where 265 are test accounts.

Week 2: Technical Transfer Prep

The technical handoff is where deals stall. Not because the code is bad, but because the accounts, keys, and credentials are tangled with the founder's personal identity. Do this work now, before a buyer is waiting on you.

Supabase. Navigate to Project Settings > General > Transfer Project. You do not need to execute the transfer yet, just confirm the option is available and your project is eligible. More important: check that Row Level Security is enabled on every table that holds user data. RLS being missing or broken is the most common critical vulnerability found in AI-built app audits, and buyers are now aware of this. If RLS is off on any user-facing table, fix it this week.

Vercel. Go to Settings > General > Transfer Project. Vercel transfers deployments, environment variables, domains, and cron jobs with the project. It does NOT transfer third-party integrations (Vercel's own integrations marketplace items). Make a list of every integration you have installed so the buyer can re-add them after transfer. Note any env vars you defined in vercel.json rather than the dashboard, as those also do not transfer automatically.

Stripe. This is the most complex piece and worth understanding early. In an asset sale where the buyer creates a new legal entity, you cannot transfer a Stripe account directly. The practical path: the buyer creates a new Stripe account, and you migrate customers and payment methods via Stripe's Customer Data Copy feature. Active subscriptions must be recreated in the new account. Services like MoveMRR can handle this migration. Budget 2-3 hours and a brief buyer conversation to plan this before you list, because discovering it at LOI signing causes delays.

GitHub repo. Confirm you own the repo outright and can transfer it via Settings > Transfer repository. If the repo lives under a GitHub organization rather than your personal account, verify you have owner-level access to initiate the transfer. This is a five-minute check that can save an awkward conversation with a buyer at close.

Rotate your most sensitive keys. Generate fresh OpenAI API, Supabase service role, and Stripe restricted keys. Deploy them. Confirm the app still runs correctly. You will rotate again at closing, but doing it now catches any hardcoded keys in your codebase, which is a critical finding in most AI-built apps. We see this pattern repeatedly: sellers discover a Supabase key hardcoded in a Bolt-generated frontend component only when a buyer's technical reviewer flags it.

Week 3: Build the Documentation Bundle

A buyer's first question after "does it make money" is "can I operate this without the seller." Three documents close most of that gap.

Operations runbook. One page, not ten. What does the app do when you are not looking? What breaks when the OpenAI API goes down, and how do you handle it? What does a normal maintenance week look like? The most valuable sentence you can write is an honest answer to "what does the owner spend time on each week." If the app runs on under 5 hours per week of your time, write that explicitly. Buyers pay a premium for low owner-time assets, and most sellers never quantify this.

Customer support log. Go back through your last 60 days of support emails, Discord messages, or Intercom tickets. Pull out the five most common questions. Write one-paragraph answers for each. This becomes the support FAQ in your handoff doc, and it tells buyers exactly what customer service burden they are inheriting. Most Cursor-built and Lovable-built app listings skip this entirely. A seller who shows up with a support FAQ already written is a different kind of counter-party.

Growth notes. Three bullets: the acquisition channel you never fully tested, the pricing tier that feels underexplored, and the feature request that comes up most often. Buyers value this section because it tells them where the easy wins are after closing. The ColdDM app that sold on Microns.io for $6K came with explicit notes from the seller on growth tactics; the buyer used them to grow the app to $2K MRR and flip it again.

For a full breakdown of what belongs in the documentation bundle and how buyers use it during review, the preparing your app for sale guide has the complete checklist.

Week 4: Write the Listing and Do a Dry Run

You now have four weeks of cleaned-up metrics, transfer-ready infrastructure, and documentation. The listing should take a day, not a week.

Write the financials block first. ARR, MRR, monthly expenses, net profit, customer count, churn rate. No decoration. A buyer scans this block in 30 seconds and decides whether to keep reading. If your MRR improved over the last 30 days (and it should have, given weeks 1-3), make the trend visible: note what your MRR was at the start of your prep sprint versus today.

Write the stack section. Front end, backend, auth, database, AI layer, integrations, monthly costs per service. No technical depth required, just accuracy. "Cursor-built React app, Supabase auth and database, Stripe for payments, OpenAI for generation, Vercel for hosting, $95 per month in fixed costs" is enough. Buyers who want more depth will ask. Your job is to make the picture clear enough for them to ask the right follow-up questions.

Add a transfer section. List exactly what transfers: domain, GitHub repo, Supabase project, Stripe migration path, Vercel project, social handles, email lists. Buyers respond well to seeing this spelled out, because most listings leave them guessing. The phrase "transfer-ready" in a listing signals you have done the operational thinking; it is one of the clearest trust signals a non-technical seller can offer.

Do a dry run. Share the draft listing and documentation bundle with someone who has not seen your app before: a friend, a family member, a fellow founder in a Slack group. Ask one question: "If you were buying this, what would you still be unsure about after reading this?" Fix whatever they flag. We have seen deals where a single ambiguous sentence about the Stripe transfer killed a $25K offer, not because the seller was hiding anything, but because no one had read the listing with fresh eyes before publishing.

For the full walkthrough of listing structure, positioning, and pricing, the first listing step-by-step guide covers everything from title format to closing CTAs.

Pre-Listing Checklist: The 30-Day Sprint at a Glance

Where Most Vibe Coders Get This Wrong

The most common mistake is treating the 30 days as documentation theater: writing docs that look thorough but describe how the app worked six months ago, or how you wish it worked.

Buyers test what you write. If your runbook says "deploy by pushing to main, Vercel auto-deploys," they will push a change and watch. If your support FAQ says average response time is 4 hours, some buyers will send a test message before signing an LOI.

Write what is true, not what looks good. A listing that accurately describes a rough onboarding and flags it as an upside opportunity for the buyer beats a polished listing that oversells a clean operation and creates friction at due diligence. Every serious buyer expects to find something; the ones who become actual buyers are the ones who feel like the seller was honest about it.

Start With Week 1, Not Week 3

Thirty days of focused work can shift your listing from the floor multiple to the premium bracket. Start with the metrics, not the docs. The financials are what buyers look at first, and 7-10 days of churn recovery work shows up in your numbers before you hit publish.

If you are already past 30 days and need to move faster, the 14-day sprint checklist covers the compressed version with one deliverable per day.