The Year-End Retro Every Indie Hacker Should Run

Most indie hackers skip the year-end review entirely, or they write a Twitter thread and call it done. Neither helps you make better decisions in January. A real retro answers one question: given everything that happened, where should your energy go next year?

This post gives you a template to run that review in a few hours. It covers what to measure, what to ask yourself honestly, and how to turn the answers into a short list of bets you can act on.

Why Most Indie Hacker Retros Miss the Point

The common version of an annual review looks like this: list your wins, list your losses, set three big goals for next year. It feels good to write. It rarely changes what you actually do.

The problem is framing. Wins and losses are outputs. What you need to understand are the inputs: which decisions produced which results, and which results actually moved your situation forward.

A retro that treats "shipped a new app" and "grew MRR" as equivalent wins is not giving you useful signal. Shipping without retention is a different kind of result than shipping with it. The retro needs to separate those two things clearly.

Part One: Gather the Raw Data First

Do not start with reflection. Start with numbers. Pull together whatever you have before you write a single sentence of analysis.

Revenue and retention

Write down your MRR or total revenue at the start of the year and at the end. Write down your churn rate if you have it. If you do not track churn formally, count how many paying users from January are still paying now.

This single comparison does more work than any amount of qualitative reflection. A product that grew revenue but also churned most of its early users is in a different position than one that grew slowly but kept nearly everyone.

Time per shipped feature

Look at your commit history or your task list and estimate: on average, how many hours did it take you to go from idea to shipped feature this year? You do not need a precise number. A rough order of magnitude is enough.

If that number shrank over the year, you got faster. If it grew, something is slowing you down, and you need to name it.

Projects versus projects that earned attention

List every project or product you worked on this year. Next to each one, note whether it earned any of the following: paying users, meaningful free signups, or consistent inbound interest from people you did not pitch.

The distinction matters. A project you love working on but that earns none of those things is a hobby. That is fine, but call it what it is so it does not crowd out the project that actually has pull.

Part Two: The Honest Questions

With the data in front of you, work through these questions one at a time. Write a few sentences on each. Do not aim for polish; aim for honesty.

What did I build that someone kept using?

Not downloaded. Not signed up for. Kept using. Ongoing use is the first real signal that something fits. If nothing kept users, that is the most important finding of the year.

Where did I spend time that did not compound?

Some work compounds: a feature that improves retention, a piece of content that keeps sending signups, a process that makes every future project faster. Some work does not: fixing the same category of bug repeatedly, rewriting infrastructure for the third time, spending hours on positioning for a product without users.

Name the non-compounding work specifically. You will probably recognize a pattern.

Which assumption did I hold longest before dropping it?

Every founder has at least one assumption they held past the point where the evidence should have changed their mind. Name yours. The goal is not self-criticism. The goal is to get better at recognizing the same pattern earlier next year.

What did I avoid that I should have done?

This is usually one of three things: talking to potential users, cutting a feature or a whole project, or raising prices. Pick whichever one is truest for you and write a sentence about why you avoided it.

What did I do well that I undervalued at the time?

Indie hackers are better at cataloguing failures than recognizing genuine strengths. If something worked, say so plainly, and think about whether you can repeat or extend it.

Part Three: Score Your Projects

Take the project list from Part One and score each project on three dimensions. Use a simple scale: low, medium, or high.

Pull: Does this product generate inbound interest without you actively promoting it? Does it have users who come back on their own?

Fit: Does working on it use the skills you are genuinely good at, not just the skills you have?

Ceiling: Given the market this sits in, is there a meaningful path to the revenue level you actually want?

A project that scores high on all three is a clear priority. A project that scores low on all three is a clear cut. Most will land somewhere in the middle, and that is where the retro earns its keep: making the tradeoffs visible enough that you can make a real call instead of a vague one.

Part Four: Map Next Year's Bets

By now you have data, honest answers, and project scores. Use them to produce exactly one output: a ranked short list of bets.

A bet is not a goal. A goal says "grow MRR to X." A bet says "I believe that if I do Y, Z will happen, and here is why." Bets are falsifiable. You can check in six months and know whether the reasoning held.

Format each bet simply

Write each bet as one sentence: "I believe that [specific action] will produce [specific result] because [one-sentence reason]."

Aim for three bets, maximum five. More than five means you have not actually prioritized.

Rank them by confidence times impact

Confidence: how sure are you that the action will produce the result? Impact: how much does the result matter to your situation? The bet that scores highest on both should come first.

This ranking will feel uncomfortable if it puts a less exciting project above a more exciting one. That discomfort is the retro working correctly.

Set one check-in date per bet

Pick a date in the middle of next year. On that date, you will look at each bet and ask: is the reasoning still holding? You are not grading yourself on the outcome yet; you are checking whether the logic still makes sense given what you have learned.

That mid-year check is where most indie hackers recover time they would otherwise spend on a bet that stopped making sense in February.

What to Do With the Output

The retro produces a short document: raw data, honest answers, project scores, and a ranked bet list. That document should take you less time to read than this post.

Keep it somewhere you will actually open it. Not in a Notion page three levels deep. A text file on your desktop or a note pinned in your writing app is fine.

Share it with one person who will ask you about it in March. That accountability is low-cost and surprisingly effective.

A Note on Tooling and Velocity

One theme that comes up in retros for solo founders is time-per-feature. When that number is high, the retro often reveals that the bottleneck is not ideas or distribution, it is the pace at which working code gets in front of users.

Faster iteration does not guarantee better outcomes, but it does mean you get more chances to learn within the same year. That is worth thinking about as you set your bets, whatever stack or workflow you choose for next year.

Conclusion

A year-end retro is only as useful as the decisions it changes. Run through the four parts above, write down what you actually find rather than what sounds good, and end with a short ranked list of bets.

The template is a starting point. Adjust it to fit your situation. What matters is that you come out of the review knowing which one or two things deserve most of your energy next year, and why.

If you want to go deeper on the indie hacker app-building process itself, the indie hacker playbook covers how to move from validated idea to shipped product without getting stuck in the middle.