Most people who try to build something on the side don’t stall because the work is too hard. They stall because the work never gets a fixed place in the week. It lives in “when I have time,” and you never have time.
The fix is a schedule small enough to survive a bad week and specific enough that you know what to do the moment you sit down. The one we use is six 90-minute blocks, about nine hours a week. Here’s how it’s built and why each block is shaped the way it is.
Why 90 minutes
Building with coding agents has a warm-up cost. You reopen the project, remember where you left off, start the app, and reload the context of what you were trying to do. That can eat the first 15 or 20 minutes.
In a 30-minute session, that leaves almost nothing. In a three-hour session, many people hit a wall partway through and start making sloppy changes. Ninety minutes is long enough to finish one meaningful change and short enough to fit before work, after the kids are asleep, or on a quiet lunch break.
A sample week
The exact days don’t matter. The mix does. Here’s one example layout:
- Monday evening, research. Customer calls, notes, reviewing what you heard.
- Tuesday early morning, build. One agent session, small commits.
- Thursday evening, review. Test what you built, read the diffs, fix what’s broken.
- Saturday morning, two build blocks. Feature work in the first, deploy and check in the second.
- Sunday afternoon, launch. Outreach, follow-ups, collecting feedback.
Notice that only half the time is building. Research, review, and outreach get their own blocks on purpose. If building takes over, you end up with a polished app that nobody has seen.
Rules that keep the week alive
- End every block by writing the next step. One line in a notes file: “Next: show an error when the email field is blank.” Next time, you skip the warm-up and start there.
- Commit before you stop. Save a working version to Git or throw the broken changes away. Never end a block with a half-finished mess you’ll have to decode later.
- Protect the block, not the hours. If you only have 45 minutes on Thursday, do a 45-minute review. A short session keeps the habit; a skipped one breaks it.
- Pick fixed times. “Saturday 8 to 9:30” survives. “Sometime this weekend” doesn’t.
- Plan for one bad week a month. Travel, quarter-end, a sick kid. When it happens, keep the research or launch block and drop the rest. Talking to users is the hardest habit to restart.
Matching work to your energy
Not every 90 minutes is equal. Most people have one time of day when they think clearly and another when they’re running on fumes.
Put build blocks, the ones that need concentration, in your best hours. For many people that’s early morning before the inbox wakes up. Put review and outreach in lower-energy slots. Clicking through your app looking for bugs or sending ten follow-ups doesn’t need your sharpest thinking.
If you carry a quota, mark month-end and quarter-end on your calendar now. Plan lighter build weeks around them in advance instead of pretending they won’t happen.
What to say no to
A side build competes with everything. A few things to drop or delay while you’re in a sprint:
- Researching new tools instead of using the ones you already picked.
- Redesigning the logo or color scheme before anyone has used the product.
- Watching tutorials that aren’t about the specific step you’re on.
- Adding features nobody in your conversations asked for.
Each of those feels productive in the moment, which is what makes them dangerous. A useful check at the start of any block: will this get the product in front of a user sooner? If not, it can wait.
The 30-Day Build & Launch Sprint is built around this exact week, with live sessions taking the place of one block rather than adding to it.