docs/weekly/friday-4-12-blocker-note.md is pre-filled with three empty section placeholders for your end-of-week progress review. This 10-minute exercise cuts through the vague “I got a lot done this week” self-reporting that usually leaves you scrambling on Monday morning to remember what you were working on, why you were stuck, and where to start next. This framework is adapted from the Build Next Stack end-of-week checkpoint for solo devs and side project builders, designed to skip fluffy status updates and cut straight to actionable next steps that keep your project moving forward even when you’re juggling multiple responsibilities.
Document the unacknowledged stall
The first section of the note is where you name the exact blocker you’ve been dancing around all week, no euphemisms, no downplaying, no blaming external factors for the work that didn’t get done. Most people spend 3+ hours a week avoiding a blocker they’ve built up to be a massive, insurmountable problem in their head, when it’s usually a small, solvable issue they’re just hesitant to tackle. To fill out this section, follow these four steps:
- Write the exact task you prioritized at the start of the week that remains 30% or more unfinished, no vague language like “I worked on the backend” — name the specific task, e.g., “I did not finish building the password reset flow for the user dashboard”.
- Note the last specific action you took on that task before you switched to doing unrelated busywork, e.g., “I stopped after getting a 500 error when I tried to test the password reset email send function”.
- List the single core reason you haven’t returned to it, even if it feels silly or trivial, e.g., “I don’t know how to configure the email service API key correctly and I’m embarrassed to look up the basic setup guide for the third time this month”.
- Cross out any secondary excuses you’re tempted to list, like “I didn’t have time” or “Other tasks came up” — those are never the real blocker for tasks you explicitly marked as high priority on your Monday to-do list.
Illustrative example: 72% of builders who fill out this section say they realize their blocker is a 10-minute Google search away, not the multi-day problem they’d built it up to be in their head over the course of the week. You don’t have to solve the blocker right now, though — the point of this section is just to name it out loud so it stops taking up unnecessary mental space over the weekend.
Map the two low-lift experimental fixes
The second section of the note is where you outline two small, low-stakes experiments you can run to unstick yourself when you return to the project next week. Neither experiment has to be the perfect permanent solution, and neither should take more than 20 minutes to run end to end. The goal here is to eliminate the decision fatigue you usually face on Monday morning, when you spend 45 minutes cycling through possible solutions without ever picking one to test. For example, if your stall is the password reset email 500 error, your two experiments might be: first, double check that you pasted the API key correctly in your environment variables, and test sending a test email via the service’s CLI tool to rule out a key configuration error; second, swap the current email service for the lighter weight, open source alternative you bookmarked last month, to see if the error is tied to the specific service you’re using rather than your code. Write both experiments out step by step, so you don’t have to brainstorm the steps when you come back to the work next week. You can also add links to any relevant documentation or tutorials you already have saved, so you don’t have to dig through your browser history to find them later.
Lock in the next two-hour work block
The third section of the note is where you make a final choice between the two experiments you outlined, write the chosen experiment directly into the file, and schedule an uninterrupted two-hour block on your calendar for Monday to run that experiment. You don’t have to pick the “right” experiment — if the first one doesn’t work, you can run the second one in your next dedicated work block, and if neither works, you’ll have new information that helps you narrow down the root cause of the blocker. The point is to make the decision now, when you still have the full context of the work fresh in your head, instead of waiting until Monday when you’ve lost half that context to your weekend off. Once you pick the experiment, add all the context you’ll need to run it directly into this section: paste the link to the API documentation, note the line numbers of the code you need to test, list the exact CLI commands you need to run, so you can jump straight into the work as soon as your block starts, no prep work required. After you fill out this section, save the file to your desktop, or leave it open in your primary text editor, so it’s the first thing you see when you log on next week.
Return to this note first thing Monday morning
This is the first file you open when you sit down at your desk on Monday, before you check your email, before you open Slack, before you look at any new notifications or requests that came in over the weekend. You spend 60 seconds reading through the stall you documented, the two experiments you mapped, and the chosen experiment for your two-hour block, then you jump straight into that work, no detours, no busywork, no unnecessary planning. If the experiment works, you can cross out the blocker and move on to the next task on your priority list. If it doesn’t work, you can run the second experiment you outlined, or add two new experiments to the list for your next work block, no stress, no wasted time trying to remember what you were working on. This small 10-minute Friday exercise cuts down on average 90 minutes of context switching and decision fatigue per week, letting you get more high-impact work done in less time, without spending your weekend worrying about the work you didn’t finish. You don’t have to overcomplicate it — the note only needs to be three or four short paragraphs total, no long status reports, no fancy formatting, just the exact information you need to hit the ground running next week. You can even add a short line at the end of the note with one small win from the week, to remind you that you made progress even if you didn’t check every item off your to-do list.