Lesson 5: After Launch - What Actually Matters
Course: Ship Your First AI App
Estimated time: 25 minutes
Difficulty: Beginner Builder
The week after launch is disorienting. You went from full-speed building to waiting. You refresh your analytics dashboard every hour. You're not sure what the numbers mean. Someone left a harsh comment on your Product Hunt post. Someone else emailed saying this is exactly what they've been looking for.
Here's what to do with all of that.
The Signals That Matter vs. the Noise
Most analytics in the first week are noise. You need to know which ones to actually act on.
Vanity metrics (mostly noise):
- Page views and visitor count from launch day
- Social media impressions and likes
- Signups from Product Hunt (lots of tire-kickers, not your real users)
- Number of upvotes on Product Hunt
These numbers feel good and they have some value as benchmarks, but they don't tell you if you built something people actually want.
Signal metrics (actually useful):
- Activation rate: of people who signed up, what percentage actually used the core feature?
- Return rate: of people who used the core feature, how many came back in the next 48 hours?
- Conversion to paid: if you have a paid tier, what's the conversion rate from free to paid?
- Direct feedback: any email, DM, or comment from a user saying specifically what was useful or frustrating
If 500 people signed up and only 15 used the core feature, that's a problem with either the onboarding or the value proposition. If 15 people used it and 12 came back the next day, that's a strong retention signal even though the number is tiny.
The ratio matters more than the raw numbers at this stage.
The metric that cuts through everything:
Ask people who used it once: "Would you be genuinely disappointed if this product disappeared tomorrow?"
If more than 40% say yes, you have something. If fewer than 20% say yes, you have a problem, even if the signup numbers look decent. This is the Sean Ellis test, and it's a better early signal than any dashboard metric.
How to Talk to Your First Users
The default first-time founder move is to avoid talking to users because it's uncomfortable. Don't do this.
Your first 10-20 users are the most valuable people you'll ever talk to. They found your product in its roughest state and chose to try it. They have opinions. Getting those opinions is more important than any feature you could build this week.
Who to reach out to:
- Users who activated (used the core feature) but haven't returned
- Users who activated and came back multiple times
- Users who signed up, tried to do something, and left immediately (if you can tell from your analytics)
Don't just email people who seem to like it. The users who bounced are often more informative.
How to reach out:
Short, honest, direct. Don't send a newsletter blast. Send a personal-looking email.
Template:
Subject: Quick question about [Product Name]
Hi [name],
I'm [your name], I built [product]. I saw you signed up [X days] ago and [used/didn't use] [core feature].
I'm trying to understand what's working and what's not. Would you be up for a 15-minute call or just replying to this email with your honest thoughts?
Specifically: what were you hoping it would do, and did it do that?
Either way, thanks for trying it.
[Your name]
The response rate to that email is genuinely high. People who tried an indie product are often happy to help the builder who made it.
What to ask on a call:
- Walk me through what you were trying to do when you first tried it.
- Did it do what you expected?
- What was confusing or frustrating?
- Is there something you wanted to do that you couldn't?
- Are you paying for anything similar to this right now? What is it?
Don't defend your product during these calls. Don't explain why something works the way it does. Just listen and take notes.
Iterating Fast with AI
You get feedback. Users want something changed or added. Here's how to turn feedback into shipped code quickly.
Triage feedback first:
Every piece of feedback goes into one of three buckets:
- Bug: The product isn't doing what it's supposed to do. Fix these immediately.
- UX friction: The product works but it's confusing or awkward. Fix these soon.
- Feature request: Users want something new. Evaluate, don't auto-build.
The mistake is treating feature requests like bugs. A feature request from one user is a data point. A feature request from 10 different users, unprompted, using the same words - that's a signal.
Bug fixes with AI:
This is where AI coding tools shine. Users report a specific error, you find the relevant code, you paste the error and the code into your AI editor and ask it to fix it. Most common bugs get resolved in 15-30 minutes.
Be specific: "Here's the error a user got [paste error]. Here's the API route they hit [paste code]. Fix the bug."
Feature iteration with AI:
Use the same spec-first approach from Lesson 3. Don't just ask the AI to add a feature in chat. Write a spec. What's the user flow? What does the API need to do? What's the UI change?
The iteration loop after launch should be tight: 1-2 day cycles. A cycle looks like:
- Day 1 morning: read feedback, decide what to build
- Day 1 afternoon: write spec, build feature, test it
- Day 1 evening or Day 2 morning: deploy, email relevant users that it's done
Users who complained about something and see it fixed within 48 hours become advocates. It's the single best thing you can do for early retention.
When to Keep Going vs. When to Move On
This is the question nobody wants to ask after launch, but you need to have a framework for it before you're in the middle of the emotional reality of it.
Signs to keep going:
- Users are coming back without prompting
- Users are paying (or saying they would)
- Users are referring other users
- You're getting "when can I use this for [related use case]" questions, meaning they see broader value
- The activation rate is improving as you iterate on onboarding
Signs to pivot:
- Users sign up but almost none activate
- Users activate but virtually none return
- You've talked to 10 users and can't find consistent pain around the problem you solved
- The users who like it describe using it for something different from what you built
A pivot isn't a failure. It's a data-driven decision to aim the product at a problem people actually have.
Signs to move on:
- You've been at 0 paying users for 2-3 months despite active iteration and user conversations
- The users who activate the most are using your product as a workaround for their real problem, and that real problem isn't one you want to solve
- You've lost interest and can't honestly tell yourself why this is the right problem to be working on
Moving on is not the same as failing. Knowing when to stop is one of the most valuable skills a builder can have. The worst outcome isn't an unsuccessful launch - it's spending a year on something that should have ended at month three.
Building Momentum Post-Launch
If the signals are positive and you're keeping going, the post-launch period is when you shift from "launch mode" to "growth mode."
What that means practically:
- Write about what you built. A blog post about how you built the product, what you learned, what tech you used - these drive traffic, build credibility, and are cheap to produce with AI assistance.
- Build in public. Share your MRR updates, your user milestones, your hard lessons. The builder community responds to transparency.
- Find your distribution channel. Product Hunt gave you a spike. What gives you consistent inflow? For most B2B products, it's SEO, community, or direct outreach. Pick one and go deep.
- Talk to users weekly. Not once and done. Make it a standing practice. One 15-minute user call per week will teach you more than any analytics dashboard.
Exercise: Write Your Week 1 Post-Launch Plan
Before launch day ends, write this document. Keep it short.
# Week 1 Post-Launch Plan
## Daily check-in (5 min each morning)
- [ ] How many new signups?
- [ ] How many activated (used core feature)?
- [ ] Any error alerts from production?
- [ ] Any feedback in email or comments?
## User outreach (by Day 3)
Reach out to: [list 5 specific users you'll email]
Template: [paste your outreach template]
Goal: 3 responses
## Feedback triage by Day 4
Sort all feedback into: Bugs / UX friction / Feature requests
Bugs to fix: [list]
UX friction to address: [list]
Feature requests to evaluate: [list]
## One thing I'll ship this week
[specific feature or fix based on the top feedback]
## Decide-by date
By [date 3 weeks from launch], I'll decide: keep going / pivot / move on
Criteria for keep going: [your specific signals, e.g. "5 paying users"]
Criteria for pivot: [your specific signals, e.g. "0 conversions after 3 weeks"]
Having the decide-by date and criteria written down before you're emotionally invested in the outcome is what makes the decision possible to actually make. Without it, you'll keep going indefinitely on hope alone.
Key Takeaway
Activation rate and user conversations tell you more about your product in week one than any other metric - and the only way to improve both is to ship fixes fast and talk to users honestly.
What's Next
You've completed Course 1. You have a framework for going from idea to shipped to iterating. Course 2 goes deeper into the tool that makes all of this fast: AI coding assistants. If you're still fumbling with Cursor or Claude Code, the next five lessons will change how you work.