Launch Week Retro Template for Solo Developers

A launch retro for a solo developer is a one-hour document, not a meeting. Write it seven days after launch day, alone, with your analytics open. Pull four numbers first (visits by source, people who tried the app, people who did the core action, people who came back), then answer five questions: where people actually came from, where they stopped, what they said in their own words, what ate your time for nothing, and what you would repeat unchanged. The retro is finished when it ends in exactly two decisions, one about distribution and one about the product, each with a date. The copy-paste template is below.

Most retrospective formats were built for a team of six with a facilitator, a whiteboard and a round of sticky notes. You have none of those, and you do not need them. What you need is a way to look at a week that felt like a blur and come out knowing what to do on Monday.

Why do solo makers skip the retro?

The launch felt like a verdict. If launch day was quiet, reopening it feels like reading a bad review of yourself. If it went well, it feels unnecessary. Both feelings skip the useful part, which is working out which part of the launch produced the result.

There is nobody to meet with. A team retro happens because it is on the calendar and people show up. Solo, nothing schedules it, so it drifts into "I'll think about it" and then into the next feature.

The formats don't fit. "What went well, what didn't, what to try" is fine for a sprint. For a launch it produces a mood diary: "Product Hunt was stressful", "Reddit was nice". None of that tells you whether to post on Reddit again or whether your onboarding is broken.

So change what the retro is: a document for the version of you who launches next, grounded in numbers pulled before you start typing.

What data should you pull before you write it?

Pull the numbers first, write second. Memory rewrites launches within days: one kind comment becomes "people loved it". You need five things.

What to pull	Where it usually lives	What it tells you
Visits by source, launch day to day 7	Your web analytics	Which surfaces sent real people
People who tried it (signup, install or first open)	Your auth table, store console or analytics event	Whether the page convinced anyone
People who did the core action once	Your database or an analytics event	Whether the product made sense on first use
People who came back on a later day	Your database, grouped by user and date	Whether it was useful, not just interesting
Every comment, reply, email and DM	The platforms you posted on, your inbox	Why the numbers look the way they do

For visits by source, Google Analytics groups sessions by channel and by source in its traffic acquisition report, and Plausible shows the same split under its Channels, Sources and Campaigns tabs. Either is enough.

One caveat: a lot of launch traffic arrives as Direct. Links opened from chat apps, email clients and some mobile apps often carry no referrer, so a busy Discord thread can look like nobody came from anywhere. If Direct spiked the day you posted somewhere, that post is the likely cause, and the retro should say "probably". Next time, add utm_source and utm_campaign to each link you post; Google's guide to building campaign URLs covers the parameters.

Also pull your own activity log: when you posted where, and what you spent each day doing. If you worked from a written plan like our Product Hunt launch day timeline, the plan is half your log already.

Which five questions matter?

1. Where did people actually come from, and where did you expect them to come from? The gap between those two lists is the most useful thing a retro produces.

2. Where did people stop? Take the four numbers from the table and read them as a sequence: visited, tried, did the core action, came back. The biggest drop between two steps is where your next week of work goes.

3. What did people say, in their own words? Copy the actual sentences, not your summary. One person confused by pricing is a person. Three is a pricing page problem.

4. What took real time and produced nothing you can see? The eight hours spent on a launch video that nobody watched, the directory that sent no visits. Name them so you don't do them again out of habit.

5. What would you repeat exactly as it was? Retros lean negative. This question protects the things that worked from being "improved" into something worse next time.

Here is the template. Copy it into a note, fill in the brackets, and delete any line you genuinely cannot answer.

LAUNCH RETRO: [app name]
Launch day: [date]    Retro written: [date, 7 days later]
Time spent writing this: [aim for about an hour]

PART 1: THE NUMBERS (pull before writing anything else)
Visits, launch day to day 7:        [number]
  Top sources:                      [source: number] [source: number] [source: number]
  Direct (probably from):           [your best guess, marked as a guess]
Tried it (signup / install / open): [number]
Did the core action once:           [number]
Came back on a later day:           [number]
Comments, replies, emails, DMs:     [number]

PART 2: FIVE QUESTIONS
1. Where people came from vs where I expected them to:
   Expected: [surface]
   Actual:   [surface]
   Why the gap, in one sentence: [ ]

2. Biggest drop-off step (visited > tried > core action > came back):
   Step: [ ]
   What someone sees right before they stop: [ ]

3. What people said, verbatim (paste, don't paraphrase):
   "[quote]"   [where]
   "[quote]"   [where]
   Anything said more than once: [ ]

4. Time that produced nothing visible:
   [task]: [hours]
   [task]: [hours]

5. Repeat unchanged next time:
   [ ]

PART 3: DIAGNOSIS (circle one)
Not enough people saw it / They saw it, didn't try it /
They tried it, didn't get it / They got it, didn't return

PART 4: TWO DECISIONS
Distribution decision: [keep / drop / add one surface]  by [date]
Product decision:      [the one step I will fix]         by [date]

Check again on: [date, 30 days after launch]

The brackets are placeholders, not targets. There is no "good" number to aim for here, because a good week for a niche developer tool and a good week for a consumer habit app look nothing alike. The only comparison that matters is your next launch against this one.

How do you tell a bad launch from a bad product?

Part 3 of the template answers this. Read your numbers from the top and stop at the first step that looks wrong.

Not enough people saw it. Visits were low across every source. That is a launch problem, not a product problem, and you have learned very little about the product yet. The work is distribution. If one big platform carried your whole plan, it is worth asking honestly whether Product Hunt was the right fit for this kind of app at all.

They saw it and didn't try it. Decent visits, few signups or installs. The page, the listing or the ask is the problem. Usually the visitor could not tell what the app does or who it is for. Our breakdown of why nobody tries your app walks through the common causes one by one.

They tried it and didn't get it. People signed up, then left before doing the one thing the app is for. This is onboarding: too many steps before the payoff, an empty state with no example, or a setup requirement nobody warned them about.

They got it and didn't come back. People did the core action once and never returned. This is the only diagnosis that says something hard about the product itself, and even then it can mean "useful occasionally" rather than "not useful". A tool people need once a month should not be judged on day-2 return.

One rule for small numbers: when your counts are in single or low double digits, stop reading them as percentages. A drop from 12 to 3 is nine people, and you can often look at what each of them did. Nine individual sessions tell you more than one ratio.

What should the retro end with?

Two decisions. Not a list of improvements, not "learnings". Two.

One distribution decision. Keep a surface, drop a surface, or add exactly one new surface. Adding five at once means you will not know which one worked, and you will run the same retro again with the same blur.

One product decision. The single step from Part 2 that lost the most people, and the one change you will make to it.

Give each a date. A decision without a date is an intention, and solo projects are full of those.

Why only two? Twenty action items from a team retro get spread across six people. Twenty action items for one person get done zero at a time. Everything else goes into a backlog note: not lost, just not next.

If you plan to launch the same app again later, fold anything procedural (tag links, prepare the demo clip earlier, pick a quieter day) into your launch checklist for solo developers so it happens automatically next time instead of relying on you rereading this note.

When should you run it?

Run it on day 7 or 8 after launch day. By then the launch-day spike has settled, you have a few days of "did anyone come back" data, and the adrenaline has worn off enough to read comments without flinching.

Not on launch night, when the numbers are still arriving. On launch night, do a five-minute capture instead: paste the comments you got, note when you posted where, and screenshot anything that might disappear, such as a leaderboard position or a thread that could get removed. That capture is raw material for day 7.

Then set a reminder for day 30 to fill in the last line of the template. It takes ten minutes: did the two decisions happen, and did the numbers you care about move?

FAQ

How long after launch should you run a retro?

Seven or eight days after launch day. That shows whether anyone returned, while the week is still fresh. Capture comments and your posting log on launch night, write the retro at day 7, and check the decisions at day 30.

What metrics matter for an indie launch?

Four counts in sequence: visits by source, people who tried the app, people who did the core action once, and people who came back on a later day. Add every comment and reply as qualitative data. Vanity figures like upvotes, impressions and follower changes can go in a footnote, but they do not tell you where people stopped.

Should you publish your retro?

It is optional, and it helps some makers more than others. A public retro is a natural post if you built in public on the way to launch. Write the private version first, with every raw number, then decide what to share. Leave out anything tied to specific users, and don't publish figures you are not prepared to keep publishing next time.

What if you have almost no data?

Then the diagnosis is almost always "not enough people saw it", and that is a real, useful answer. Skip the percentages, list the people who did show up and what each of them did, and make your distribution decision the priority. A launch with a handful of visitors has not tested the product yet. It has tested the launch.

---

If your retro landed on "not enough people saw it", the distribution decision can be a small one. Submit your app to TryMy for free: every listing is reviewed by a human, and free, free-trial and freemium apps that people can actually try get their own page in the showcase. It is one more surface, and it will still be there when you run your next retro.