Side Project Execution Framework
By Cristian Lascu · The Sovereign Technologist · Last updated: July 6, 2026
TL;DR — What's on this page
Side project execution framework: from idea to launch. The Sovereign Technologist. Practical frameworks for employed technologists building products, lever
👉 Want the next list each Thursday?
Free. No spam. Unsubscribe anytime.
A side project execution framework is the sequence you push an idea through — validate, scope, build, launch, decide — sized to the focused hours you can genuinely defend, not the hours you picture on your best week. Its only job is to stop a project from dying in the gap between your ambition and a demanding day job. You begin by counting real weekly hours, usually 5-10, treat that number as fixed supply, and force every stage to fit inside it. Ideas are cheap and interchangeable; the binding constraint is execution time, so the framework optimizes ruthlessly for that one scarce resource and lets everything else lose.
The non-obvious part: your enemy isn't a weak idea or thin skill — it's scope quietly widening until the launch never arrives. On 40 hours a week you can absorb a growing feature list; on six you cannot, and the project slides from "almost done" to permanently 80% done without any single decision you can point to. So the framework nails the launch date to the wall and makes scope the variable — when you fall behind, you cut features, you never move the date. That one inversion, applied every time you're behind, is what separates side projects that ship from the folder of repos that stayed nearly ready forever.
How do you scope a side project to the hours you actually have?
The first move is arithmetic, not inspiration. Open your last month and count the hours you actually defended for the project — not the ones you blocked off and then surrendered to a standup that ran long, a Tuesday evening you were too fried to think, or a weekend that got claimed by everything else. For most people carrying a demanding job, that number lands somewhere between 5 and 10 focused hours a week. Whatever yours is, treat it as fixed supply. Every downstream decision — which idea, how big, how long — is a withdrawal against it.
Then do the division on purpose. A build you honestly estimate at roughly 300 hours is not a six-week sprint at eight hours a week; it's six-to-twelve months of real calendar. Decide whether that's a timeline you'll still care about in month four before you write a line of code, because discovering it in month four is precisely how a repo joins the abandoned pile. Scoping is just this sum done deliberately instead of stumbled into — and it's why the identical idea is a different project at eight hours than at forty.
| Weekly focused hours | Realistic scope in one quarter |
|---|---|
| 3-5 hours | One narrow tool or a paid content product: a single core feature, no user accounts |
| 5-8 hours | A small app with auth and one workflow end to end, or a newsletter launched with 10-12 issues out |
| 8-12 hours | A polished MVP with payments and a landing page, ready to take its first paying users |
Get the next list before everyone else.
Each Thursday, The Sovereign Technologist ships a new framework, agent-ready workflow, or curated list — built specifically for senior engineers, tech leads, and consultants who want to compound career leverage without quitting their jobs.
Free. No spam. Currently read by 141+ senior technologists.
What are the five stages, and how long should each take?
The durations flex; the order does not. Validate, scope, build the smallest shippable version, launch, decide. Validation precedes scoping because you can't size something no one has confirmed they want. Launch precedes decide because "should I keep going" is a question only real usage answers, not your gut at 11pm. The recurring mistake is treating build as the whole project — it's one stage of five, and it's the single stage that will happily expand to swallow every hour you don't guard.
| Stage | Share of total time | Done means |
|---|---|---|
| Validate | ~15% | 5-10 real conversations or pre-signups from people who aren't already your friends |
| Scope | ~10% | A one-page written spec of the smallest thing worth launching; everything else parked on a 'later' list |
| Build | ~50% | The smallest shippable version works end to end for one real user |
| Launch | ~15% | It's public, someone who isn't you has used it, and you can take money or signups |
| Decide | ~10% | You've looked at actual usage and chosen: continue, pivot, or stop |
Why do most side projects stall before launch?
It's almost never a shortage of ideas or ability. Two failure modes account for most of the graveyard. The first is scope quietly widening until the launch date recedes forever — a 40-hour week absorbs a growing feature list, a 6-hour week cannot, and the project slides from 'almost done' to permanently 80% done without any single decision you can blame. The second is spending your scarce hours on the fun part, code, and skipping the uncomfortable part, asking people — so you ship something nobody requested and misread the silence as a marketing problem instead of a demand problem.
- →Scope creep: every 'while I'm in here' addition costs a week you don't have. Fix: a written 'later' list — nothing new enters the current build until it launches.
- →Building before validating: skipping the conversations to get straight to code. Fix: spend the first ~15% of hours confirming demand before any build.
- →No calendar deadline: 'someday' projects never ship. Fix: put a real launch date down and cut scope to hit it, not the other way around.
- →Energy mismatch: doing the hard creative work in your most tired, leftover hours. Fix: protect your best one or two blocks a week for the project, not the dregs.
- →Restarting the stack: rewriting into a shinier framework resets progress to zero. Fix: use tools you already know — novelty is a cost here, not a feature.
How do you keep momentum on 5-10 hours a week?
Momentum on a thin budget is a systems problem, not a willpower one — the entire point is that the project advances on the weeks you're not feeling it. The single highest-leverage habit: end every session by writing the literal next action in plain words, so your next block opens with hands on the keyboard instead of ten minutes of 'where was I.' Keep the thing resumable. If re-entry costs half an hour of context-reloading, a 90-minute block quietly becomes a 60-minute one, and after a few of those you'll stop opening it at all.
Batch by stage instead of interleaving. One week entirely on validation calls, then a week entirely on build, beats splitting a single evening between them and paying the context-switch tax twice. And hold the launch date fixed while scope stays the variable: when you fall behind, you cut a feature, you do not extend the date. Applied every single time you're behind, that one inversion is most of what a working execution framework actually does.
For the bigger picture, read the career sovereignty guide for technologists, or jump straight to 12 ranked side-project ideas for senior technologists. To get new frameworks like this each week, subscribe to The Sovereign Technologist newsletter.
Frequently asked questions
Should I validate before I build, or just start building?
Validate first, but keep it cheap and fast. Spend roughly the first 15% of your hours on 5-10 real conversations or pre-signups from people who don't already like you. On a 5-10 hour week, building the wrong thing costs you two or three months you can't get back, whereas a week of asking costs almost nothing. Validation isn't a survey — it's evidence someone will change their behavior or pay. If nobody bites before you build, that's the cheapest 'no' you'll ever get, and it frees your next quarter for a better idea.
How do I choose which idea to execute first when I have several?
Score each against your actual weekly budget, not its ceiling. Ask three things: can a shippable version fit inside one quarter at my real hours? Does it use a stack I already know, so build time isn't inflated by learning? Can I find ten people to talk to about it this week? The idea you can validate and launch fastest usually beats the more exciting one that needs six months before anyone can react — you want a full validate-through-decide cycle before your motivation and free time drift.
What actually counts as 'launch' for a side project?
Launch means it's public, someone who isn't you has used it end to end, and you can take money or signups — not that it's finished or polished. A landing page that collects emails counts. A tool one stranger has completed a real task with counts. The bar is deliberately low because launch exists to generate usage data for the decide stage, nothing more. Anything you keep private until it feels 'ready' never crosses this bar, which is exactly how projects stay permanently 80% done.
One framework. Every Thursday.
If this list was useful, the next one will be too. Subscribe and you’ll get the next agent-ready playbook the moment it ships.
Free. No spam. Currently read by 141+ senior technologists.