Launch Day Checklist for Solo Developers

Launching solo means every job is yours: the deploy, the posts, the replies, the bug that shows up at 11am. You can't add hands on launch day, but you can move almost everything off launch day. That's what this checklist is for — a boring week before, so the exciting day is mostly just talking to people.

The week before

Make the product survivable by strangers.

• Run your entire signup-to-value flow in a private window, on your phone, on a bad connection. You're looking for the step where a stranger with no context gives up.
• Kill or hide anything half-finished. A smaller app that works beats a bigger one with a broken corner someone will screenshot.
• Check the empty states. Launch visitors see your app with zero data in it — make that first screen point clearly at the first action.
• If there's a paid tier, do a real test purchase and a real refund. Discovering a broken checkout mid-launch is a classic solo-dev wound.

Set up your eyes and ears.

• Error tracking wired up and actually alerting you (email, phone, whatever you'll genuinely see).
• Analytics enough to answer "where did people come from and where did they stop?" Page views and a couple of key events are plenty.
• A way for users to reach you that you'll see in real time — a visible support email at minimum.

Pre-write everything.

• Your launch posts, one per channel, each written in that community's native register — not one blast pasted five times. (If you haven't picked channels, Where to Post Your App in 2026 is the realistic list.)
• Answers to the questions you know are coming: how is this different from X, what's the pricing, is my data safe, what's the roadmap.
• Screenshots and a short demo GIF or video. Every platform asks for them; making them at midnight before launch is how they end up mediocre.

Line up your first supporters. Message the friends and testers who already like the app: "I'm launching Thursday — if you've got two minutes that morning, an honest comment or share would help a lot." Asking beforehand is organizing; asking in the moment is scrambling. If you've been trading favors in a builder community, this is the day to call them in.

Clear the decks. If client work pays your bills while you build, wrap the week's deliverables and send your invoices before launch week starts — billable.dev keeps billing clients for dev work from eating an evening you need. A launch day shared with a client deadline goes badly for both.

Settle the name. If you're still on a subdomain or a placeholder, fix it before you post anywhere — every link you earn on launch day points at whatever URL you used, and moving later costs you all of it. 199.domains is a curated marketplace of names at $199 or less if you'd rather buy a decent one than settle for the fourth-choice spelling.

If you're shipping to an app store, work backwards from review

Web apps launch when you decide. Mobile apps launch when a reviewer says so, and solo developers routinely discover this two days before a date they've already announced.

The official numbers, from the platforms themselves:

Platform	Official guidance	What to actually plan for
Apple App Store	90% of submissions reviewed in under 24 hours	24–48h for updates; several days for a first submission or a sensitive category
Google Play	Production review typically 7 days or less	Up to 7 days, longer for a brand-new developer account

Two details that wreck schedules more than the review itself:

• Apple's 90% is an average, not a commitment. First submissions, finance/health/kids categories, and high-volume periods all sit in the other 10%. Never announce a date that assumes the fast path.
• Google Play's new-account testing requirement is the real deadline. Newly created personal developer accounts must run a closed test with at least 12 testers, opted in continuously for 14 days, before they can even apply for production access. That's a two-week prerequisite that runs before the review clock starts — and it's the single most common reason a first Android launch slips by a month.

So the backwards plan for a mobile launch: pick your launch date, subtract a week for review, subtract another two weeks if it's a new Play account, and submit then. Rejections happen, and a rejection eats the buffer you didn't leave.

Launch day

Morning, before posting anything:

• Deploy the version you're launching — then stop deploying. No new features today; you want a stable target. Fixes only.
• Click through signup-to-value one more time in production.
• Confirm error tracking and analytics are reporting from prod.

Then post, in your planned order. Stagger your channels rather than firing everything at 9:00 — it spreads the incoming attention into something one person can actually handle, and lets you fix anything the first wave finds before the second wave hits it.

Spend the rest of the day on replies. This is the part that's actually your job today. Answer every comment and every support email, fast and honestly. "Good catch, fixing it now" is a great look in a launch thread. Solo developers get a warmth premium — people root for one person shipping — but only if that person shows up in the thread.

Triage like a medic. Blockers that stop signups get fixed now. Everything else gets a "thanks — noted" and a line in the list. Do not disappear for three hours to polish something cosmetic while your thread goes quiet.

Two more notes for the day:

• Eat. Seriously — put lunch in the calendar. Frazzled replies read worse than late ones.
• Screenshot things as they happen: kind comments, milestones, weird bugs. Useful for the retrospective, and for remembering that this was fun.

The 48 hours after

The launch isn't over when the day ends; the follow-through is where lasting users come from.

• Reply to the stragglers. Comments arrive for days. Late replies to late comments still count — the thread is public and future visitors read it.
• Thank your supporters individually. One sentence each, naming what they did. It's the difference between a network and a contact list.
• Fix the top recurring issue and announce the fix where people reported it. Shipping a fix 24 hours after launch signals the product is alive, which is half of what early adopters are evaluating. Not sure which feedback deserves action? The Beta Tester Checklist has the filter.
• Write the retrospective while it's fresh: what each channel sent, what people misunderstood, what broke, what you'd repeat. Fifteen minutes now saves your next launch a week of guessing.
• Keep the door open. Launch traffic decays fast, so give stragglers somewhere durable to land — your listing pages, directories, and posts keep working after the spike. (TryMy.App listings are free to submit, while we're on the subject.)

The one-screen version

Week before: stranger-proof the flow · kill broken corners · test checkout · wire error tracking + analytics · pre-write posts, answers, media · brief your supporters.

Day of: deploy, then freeze · verify prod · post staggered · reply all day · fix blockers only · eat.

After: thank people by name · fix and announce the top issue · write the retro · keep durable listings live.

A solo launch done this way is genuinely calm — not because less happens, but because almost everything that could go wrong was handled on a quiet Tuesday the week before.

Sources

• Apple, App Review — review time guidance
• Google Play Console Help, App testing requirements for new personal developer accounts