Launch Your First Product Publicly

Proof required

Share your GitHub repository. The first commit must be the launch definition document — verified by commit history. The repository must contain no product code at the time of this milestone submission. Write 150 words on why you chose this specific success metric and what you would do differently if you hit it vs missed it.

What gets checked

• Launch definition document is the first commit — verified by git log; if product code exists in the same commit, the document was written after the build started
• Success metric is a single number with a specific threshold ('10 paying customers in 30 days') not a vague goal ('get traction' or 'see if people like it')
• Three channels are named specifically — not 'social media' but 'post in r/SideProject, submit to Product Hunt, cold email 20 people in [specific community]'

Common mistakes

• Starting to build before the document is written — the commit history is the proof; a document added after code commits is not this milestone
• Setting a success metric you cannot measure — 'people enjoying the product' or 'positive feedback' cannot be counted; pick a metric that produces a number

Resources

What a verifier looks for

• Check the repository's git log. What is the timestamp of the first commit? What files does it contain? If product code exists in the first commit alongside the document, the document was written after building started.
• Read the success metric. Can it be measured with a specific number on a specific date? If the metric requires subjective judgment ('good feedback', 'people seem interested') ask the submitter to restate it as a count.
• Read the three channels. Are they specific enough to act on right now? 'Post on Reddit' is not specific. 'Post in r/SideProject and r/[relevant subreddit] on Monday at 9am EST' is specific.
• Ask: 'What will you do if you miss your success metric?' If they have a clear answer (pivot, kill, try a different channel) they have thought seriously about the metric. If they say 'try harder,' the metric is not meaningful to them.

Proof required

Share the public URL of your live product. Share a 3-minute screen recording showing a complete user journey from landing page to core action completed — narrate what you are doing and why each step is necessary. Write 200 words on what you cut from your original plan to ship on the committed date and whether, with hindsight, cutting those features was the right decision.

What gets checked

• Product is live at a public URL — not localhost, not a Replit preview, not a Figma mockup; a stranger with the URL must be able to use the core feature without instructions
• Screen recording shows the complete user journey narrated — the verifier must be able to follow the journey without asking what any step does
• The 'what I cut' reflection names specific features by name, not 'some things' — and gives an honest assessment of whether cutting was right

Common mistakes

• Shipping a landing page with a waitlist and calling it a launch — a waitlist is pre-launch; launch means the product does the thing it promises and users can do it right now
• Adding features after the launch date is set because 'just one more thing' — every added feature moves the launch date; the launch date in the document is non-negotiable

Resources

What a verifier looks for

• Visit the URL without any help from the submitter. Try to complete the core action as a new user. Time yourself. If you cannot complete the core action in under 3 minutes without instructions, the onboarding is broken — report every friction point to the submitter.
• Watch the screen recording. Does the submitter narrate WHY each step is there, or just WHAT they are clicking? Narrating why reveals whether they have thought from the user's perspective.
• Check the launch date against the Milestone 1 document. Did they ship on the committed date? If not, ask what caused the delay — the answer reveals their relationship with scope creep.
• Ask: 'What is the one thing a user can do on your product right now that they cannot do anywhere else?' If the answer takes more than one sentence, the value proposition is not clear enough.

Proof required

Share your analytics dashboard showing 25+ unique users who completed the core action (not just visited). Share evidence of the channel posts that drove them (screenshots of the Reddit post, Product Hunt listing, Twitter thread, etc). Write 200 words on which channel produced the most users, why you think that channel worked better than the others, and what you would do differently in the first 48 hours of the next launch.

What gets checked

• Analytics show 25+ completions of the core action — not 25 page views, not 25 signups; the core action as defined in Milestone 1
• Channel evidence is shown — not just the analytics; the actual posts, listings, or outreach that drove traffic must be visible
• The channel analysis names the best-performing channel with its specific number and gives a hypothesis about WHY it worked — 'Reddit drove 18 users because the post title framed the problem, not the solution'

Common mistakes

• Counting page views as users — a visitor who lands and leaves is not a user; the metric is completion of the core action, which requires analytics that track events, not just page loads
• Personally inviting people and counting them — the stranger standard is the whole point; if your mother is in your analytics, her usage does not count toward the 25

Resources

What a verifier looks for

• Look at the analytics dashboard. Is it tracking an event (core action completed) or just page views? If it is a page view dashboard, ask the submitter to show the event tracking — page views are not the metric.
• Ask for the usernames or anonymised IDs of 3 users from the analytics. Can the submitter point to where they came from in the channel evidence? If they cannot trace individual users to channels, the attribution is not real.
• Read the channel analysis. Does it name a specific number for the best-performing channel with a hypothesis for why? 'Reddit worked best' is not sufficient. 'Reddit drove 18 of the 25 users because the title described the problem not the product' is sufficient.
• Ask: 'If you had to get to 250 users in the next 30 days using only one channel, which would you pick and why?' Their answer reveals whether they extracted signal from the launch or just recorded the numbers.

Proof required

Share a metrics dashboard or spreadsheet with the three metrics measured over 30 days. Show the raw numbers — not just percentages. Write 250 words on your retention number: what it is, what it means about the product, and what the most likely explanation is for why users did or did not come back. If retention is below 20%, this is not a failure — document specifically what you think users found missing.

What gets checked

• All three metrics are measured with real numbers from real analytics — not estimates; the dashboard or spreadsheet must show raw counts, not just percentages
• Retention is measured correctly: of users who activated in week 1, what percentage returned in week 2 — not total week 2 users divided by total week 1 users
• The retention analysis is honest — if retention is 0%, it is reported as 0% with a specific hypothesis about why, not hidden or reframed

Common mistakes

• Measuring retention as 'total users this week vs last week' — this is not retention; it mixes new users with returning users and hides churn; cohort retention (same users over time) is the only honest measure
• Not talking to churned users — the most valuable information in early-stage products comes from people who tried it and left; if you have their email, contact them

Resources

What a verifier looks for

• Ask the submitter to show the cohort retention calculation — specifically, the number of users who activated in week 1 who also returned in week 2. If they cannot show this calculation, they measured rolling totals, not cohort retention.
• Check whether the retention number is honest. A startup with 0% day-30 retention that reports 'strong early engagement' is not being honest with itself. The submission must state the actual number.
• Ask: 'Why do you think your retention is what it is?' A founder who says 'people forgot about it' hasn't thought about it. A founder who says 'the product solved the problem once and there was no reason to return' has identified a fundamental product question.
• Check whether revenue is measured. If the product is free, revenue is $0 — that is a valid number. If it is paid, the revenue number must match the payment records, not estimates.

Proof required

Share the public URL of your published retrospective. It must be publicly accessible without a login. Write 150 words on why making this retrospective public matters — not for Powstik, but for your own next launch.

What gets checked

• Retrospective contains all six required sections with real numbers — the original success metric must be quoted exactly from the Milestone 1 document and the result stated precisely
• One thing that failed is described honestly — not softened into 'room for improvement' but named as a failure with a specific hypothesis for why it happened
• Published at a public URL accessible without login — a private Notion doc does not count; Indie Hackers, a personal blog, or a public GitHub README all count

Common mistakes

• Omitting the success metric result because you did not hit it — the retrospective is more valuable when you missed the metric than when you hit it; what went wrong is the learning
• Publishing internally and calling it public — a document that requires a password, a login, or an invitation is not public; the URL must work for a stranger

Resources

What a verifier looks for

• Visit the retrospective URL without logging in. Does it load? A URL that requires a password manager, Google login, or invitation is not public.
• Check that the original success metric from Milestone 1 is quoted in the retrospective. The exact metric — not a paraphrase. And the result — did they hit it or not?
• Read the 'one thing that failed' section. Is it honest? 'Distribution was harder than expected' is not honest. 'My Product Hunt launch got 4 upvotes because I launched at 3pm EST on a Friday with no hunter and no community' is honest.
• Ask the submitter: 'Would you show this retrospective to a potential co-founder or investor on a first meeting?' If yes, it is honest and specific. If they hesitate, it is not honest enough.