30 Days to Launch — What Prep Actually Looks Like

App Development

30 Days to Launch — What Prep Actually Looks Like

The app is getting close. Here's the actual checklist I'm working through — not the idealized version, but the real one, with the things I'm behind on and the things I'm cutting.

T
The Software Entrepreneur
6 min read
Share

30 Days to Launch — What Prep Actually Looks Like

I'm writing this with roughly 30 days until I plan to submit the app to the App Store and Google Play. That's the target. Whether it holds is a different question.

I want to document what this phase actually looks like, because most launch content is either "here's my polished launch strategy" written after a successful launch, or "here's what I wish I'd done" written after a failed one. This is the messy middle — written in real time, before I know how it goes.

What "Ready to Launch" Actually Means

I spent a long time with a fuzzy definition of launch-ready. "When it's good enough." "When the core features work." These aren't definitions, they're deferrals.

About three weeks ago I forced myself to write a specific list. Here's what I decided launch-ready means for this app:

Must have:

  • Feed loads in under 800ms on a 4G connection
  • Post creation works end-to-end without errors on iOS and Android
  • Onboarding completion rate above 65% in testing
  • Push notifications working on both platforms
  • Account deletion flow (required for App Store approval)
  • Privacy policy and terms of service live on the web
  • No crashes in 48 hours of internal testing

Nice to have, but not blocking:

  • Trending topics sidebar (probably cutting this — see previous post)
  • Direct messages (v1.1)
  • Web version (v1.1)
  • Advanced notification settings (v1.1)

The "must have" list is 7 items. I'm currently at 4 of 7. That's the honest number. Some of the gaps trace back to decisions I made earlier that I'd make differently now — I wrote about those in The Product Decisions I Got Wrong.

The Three Things I'm Behind On

Feed performance. I mentioned this in the mistakes post. The feed is loading at 1.2 seconds average on 4G. I need to get it under 800ms. I've identified the bottleneck — it's a combination of over-fetching on the initial query and a missing index on the posts table. I know how to fix it. I haven't fixed it yet because every time I sit down to do it, something else is on fire.

This week it gets fixed. It has to.

Push notifications on Android. iOS push notifications work. Android push notifications work in the emulator and on my personal device. They don't work on three of the five Android devices I've tested on. The issue is almost certainly FCM token registration timing, but I haven't been able to reproduce it consistently enough to fix it confidently. This is the thing I'm most worried about.

Account deletion. This is embarrassing to admit because it's not technically hard — it's just a settings screen and a backend endpoint. I've been putting it off because it feels like building the exit door before the entrance. But Apple requires it for App Store approval, and I'm not going to get rejected on a technicality. It's on the list for this week.

What I'm Cutting

The trending topics sidebar is gone. I wrote about this in The Product Decisions I Got Wrong — nobody uses it, it doesn't fit the product, and maintaining it is technical debt I don't need at launch.

Direct messages are moving to v1.1. I know this will disappoint some waitlist members who've asked for it. But DMs are a significant surface area — abuse vectors, moderation requirements, storage implications. Shipping a bad DM feature at launch is worse than not shipping one. I'd rather launch without it and add it properly in the first update.

The web version was always aspirational. It's not happening for v1.0.

Cutting things is psychologically hard. Every feature I cut feels like a failure. But shipping a focused product that works is better than shipping a broad product that doesn't. I keep reminding myself of this.

The App Store Submission Process

I've never submitted an app before. I've been reading everything I can find about the review process, and the picture that emerges is: it's unpredictable.

Average review time is 1–3 days, but rejections can add weeks. Common rejection reasons I'm preparing for:

  • Guideline 2.1 (App Completeness) — apps that feel unfinished get rejected. I need to make sure every screen has real content, not placeholder text.
  • Guideline 5.1.1 (Data Collection and Storage) — the privacy policy needs to accurately describe what data I collect. I'm having a lawyer review this.
  • Guideline 4.3 (Spam) — social apps get extra scrutiny. I need to demonstrate that the app has a clear purpose and isn't just another generic social network.

I'm building in a two-week buffer for App Store review and potential rejection. If I submit on day 30, I'm targeting a public launch on day 44.

The Launch Week Plan

Here's what I'm planning for the actual launch week:

Day 1 (submission day): Email the waitlist. Not "we launched" — "we submitted, here's what to expect." Manage expectations, build anticipation.

Day 2–3: Stream the waiting. Literally stream myself waiting for App Store approval, working on bug fixes, answering questions from the waitlist. The waiting is content.

Approval day: Email the waitlist with download links. Post on all channels. Go live immediately for a launch stream. The 4,800 people on that waitlist have been following this build for months — how that community formed before the product existed is its own story, but the launch is where it pays off.

Week 1: Daily streams. Answer every question. Fix every bug that comes in. Be visibly present.

The launch isn't the end of the build-in-public journey — it's the beginning of a new phase. The audience that's been watching me build it will now be watching me grow it. That's a different story, but it's still a story.

The Honest Uncertainty

I don't know if this is going to work. I don't know if 4,800 waitlist signups will convert to active users. I don't know if the feed algorithm will hold up under real load. I don't know if the App Store will approve it on the first submission.

What I know is that I've been building this for 14 months, in public, with a community that's been part of every decision. Whatever happens at launch, the process has been worth it.

Ask me in 30 days how it went.

If you want to be in the first wave of users, join the waitlist. If you want to follow the final stretch of the build, subscribe to the newsletter — I'm writing about this every week until launch. And if you want the honest accounting of what 14 months of bootstrapping this actually cost — time, money, opportunity cost — that's in The Real Cost of Building Without Funding.

Explore Topics

#launch#app#planning#build-in-public#indie-dev

Found this useful? Share it with your network.

T

Written by

The Software Entrepreneur

Content creator and writer sharing insights and stories.