The Solo Developer's Weekly Review Routine
The short version: A solo developer's weekly review is a 30-minute ritual with four steps: empty the inbox, review what actually shipped, re-rank the backlog, and plan next week. Run it at the same time every week, ideally Friday afternoon. The goal is to stop re-deciding the same priorities every morning and start each week with the decisions already made.
One 30-minute ritual, once a week, is what separates a project quietly moving forward from a pile of tasks you keep re-deciding on. Here is the exact routine, plus a checklist you can run every Friday.
Want your weekly review to run on the real backlog, not a copy? Heygents turns this guide into a workflow on your real projects.
Try Heygents free →By Heygents · Updated · All guides
Why the weekly review is the keystone habit
As a solo developer, you have no manager syncing your priorities and no daily standup surfacing what you missed. Without a deliberate pause, two things happen: your inbox fills with unsorted noise, and your sense of "what should I do now?" drifts toward whatever feels urgent that morning.
The weekly review fixes both. It is the moment you step out of doing the work and into steering it - the single habit that keeps a solo project coherent from week to week.
When and where to do it
Pick a fixed time slot and protect it like a client meeting. Friday afternoon is popular: you close the week with a clear picture and start Monday already knowing what to do. Sunday evening works too if that fits your rhythm.
- Same time every week - consistency beats perfect timing.
- 30 minutes, boxed - if it runs longer, you are working, not reviewing.
- One screen, one board - do it where your tasks actually live, so you sort the real list, not a copy of it.
Step 1 - Empty the inbox
Everything you captured during the week - bugs, ideas, "I really should..." notes - gets a decision now. For each item, pick one:
- Now - blocks a release or a user; it goes to the top of the backlog.
- Next - important, not this week.
- Later - real, no urgency.
- Someday / Maybe - park it to the side.
- Delete - it no longer matters. Let it go.
The goal is an empty inbox. An empty inbox is what lets your brain trust the system and stop nagging you.
Step 2 - Review what shipped
Look at your Done column from the past week before you plan the next one. This is not filler - solo developers often feel like they achieved nothing precisely because there is no one else reflecting it back to them. Seeing the list is the cure.
Ask two questions: what went well that is worth repeating? What dragged, and why? You are not writing a report; you are noticing patterns while they are still fresh.
Step 3 - Re-rank the backlog
Priorities drift during a week of heads-down work. Now realign them: read the backlog top to bottom and drag the items that truly matter to the top. You are not estimating or ordering every card - just making sure the top of the list is right, because that is where next week's work comes from.
Step 4 - Plan next week
Pull a small, realistic set of tasks from the top of the backlog into a This week list. "Small and realistic" is the hard part - most solo developers commit to too much. Plan the week you actually have, not the ideal one.
Then the rule that makes it hold: during the week, new ideas go to the inbox, not this list. You protect the plan until the next review.
A worked example: one real Friday review
The steps read cleanly in the abstract, so here is what a single session looks like in practice. Picture a solo developer running a small invoicing SaaS: one web app, one database, a handful of paying customers, and a side project that gets a few hours a week. It is 4:00 pm on Friday and the timer is set for 30 minutes.
4:00 - Empty the inbox (10 minutes)
The inbox holds 14 items captured during the week. Most take a few seconds each:
- Now (2): a customer reports that PDF invoices cut off long line items; the password reset email lands in spam for one mail provider.
- Next (3): add CSV export, clean up the pricing page copy, bump the framework to the next minor version.
- Later (4): dark mode, a Slack integration someone asked for once, a faster dashboard query, a refactor of the billing module.
- Someday / Maybe (2): a mobile app, a public API.
- Delete (3): two duplicate notes about the same bug, and an idea that made sense on Tuesday night and no longer does.
Notice what did not happen: no bug got investigated, no estimate got written. The PDF issue is sorted, not solved. That discipline is what keeps this step to ten minutes.
4:10 - Review what shipped (5 minutes)
The Done column shows six cards: the Stripe webhook retry fix, two small UI bugs, a dependency update, the new onboarding checklist, and a blog post. One win worth repeating: the onboarding checklist shipped in a single focused afternoon because it was scoped tightly on Monday. One drag: the webhook fix took three days instead of one, because there was no test reproducing the failure, so every attempt meant a manual retry. That drag becomes a note for Step 3.
4:15 - Re-rank the backlog (8 minutes)
Reading top to bottom, two things move. The PDF truncation bug goes to the very top: it affects every customer who sends a large invoice. And the drag from Step 2 turns into a new card near the top: "add a webhook replay test," because the same class of bug will come back. The billing refactor, which had crept up to third place because it felt interesting, drops below the CSV export that two customers actually asked for. Nothing below the top ten gets touched.
4:23 - Plan next week (5 minutes)
This week has about four real working days, minus a half day already committed to the side project. The This Week list gets four items, not nine:
- Fix PDF truncation for long line items.
- Fix the password reset deliverability issue.
- Add a webhook replay test.
- Ship CSV export.
Monday's first task is item 1, written on the card in one sentence so there is no warm-up decision on Monday morning.
4:28 - Close (2 minutes)
A quick glance at the one-line notes from the last three reviews shows the same drag twice: bugs without a reproducing test take far longer than planned. That pattern is worth more than any single task, and it only shows up because the notes exist. Laptop closed at 4:30.
A weekly review notes template
Keep a single running note, one entry per week, newest at the top. Five lines is enough; the point is to make patterns visible across weeks, not to write a report.
- Week of: the date of the Friday you ran the review
- Inbox: how many items were sorted, and how many were deleted
- Win: one thing that went well and why, in a sentence
- Drag: one thing that took longer than planned and the likely cause
- This week: the three to five tasks you committed to, plus Monday's first task
Once a month, read the last four entries together. If the same drag shows up twice, it deserves a card of its own in the backlog, like the webhook replay test above. If This Week keeps finishing with items left over, commit to one fewer task next time. The template is small on purpose: a note that takes a minute to fill in is one you will still be writing six months from now.
Run your weekly review where your work already lives
Heygents keeps each project's backlog, board, and this-week list in one place - so the review is a five-minute pass over the real list, not a copy of it. Its AI assistant can even summarize what changed in the repo during the week, so Step 2 writes itself.
Open Heygents →The copy-paste checklist
- Empty the inbox - every item sorted into Now / Next / Later / Someday / Delete
- Review the Done column - note one win and one drag
- Re-rank the backlog so the top items are the real priorities
- Pull a small, realistic This Week list from the top
- Confirm one clear "first task" for Monday morning
- Close the laptop - the review is done, no new work now
Frequently asked questions
How long should a weekly review take?
Around 30 minutes. If it consistently takes longer, you are probably doing the work instead of reviewing it - move those tasks to next week and keep the review a sorting-and-planning pass only. The four steps are deliberately short: empty the inbox, review what shipped, re-rank the backlog, and plan the coming week.
What happens if you miss a week?
Just run the next one. The review is self-correcting: a bigger inbox takes a few extra minutes to empty, and you are back on track. Missing one week is fine; abandoning the habit is what hurts, because the value comes from running it at the same time every week, not from any single session.
Daily standup or weekly review?
For most solo developers the weekly review is the higher-leverage ritual. A short daily glance at "what is my task today?" is a nice addition, but the weekly review is what keeps the whole project aligned, because that is where you re-rank the backlog and decide what next week is really for, instead of re-deciding every morning.