Pick one fixed slot of 60 to 90 minutes, cut every task until it can start and finish inside that slot, and mark each day you show up. By the end of this post you will have a one-sentence plan, a weekly hour budget you can repeat for four weeks, and a rule for what to do when a day goes wrong.
It will take longer than it would full-time. One developer's write-up on solodevstack says to accept that and not count it as failure. Slower is the baseline for a side project.
Put the build slot where your energy is, not where the free time is
Free hours are not the limit for most people with a day job. Energy is. After a full day of work, many people have nothing left, and one poster on Indie Hackers said they moved their work to the morning so the project got their best instead of their leftovers.
Test it for two weeks before you commit:
- Try a different slot every few days: before work, right after work, and a weekend block.
- At the end of each session, write down how many tasks you finished, not how many hours you sat there.
- Keep the slot with the most finished tasks.
If you are drained every evening, do not fight it. Move the slot to the morning and keep it short.
Pick a weekly budget you can repeat for four weeks
The formula is simple:
Weekly build hours = (weekday slot hours x weekday slots) + weekend hours
Example: say a 90-minute weekday slot, five days a week, plus 4 hours on Saturday. That is (1.5 x 5) + 4 = 11.5 hours. Put in your own numbers.
People on Indie Hackers report very different plans. These are what they said, not targets:
| Plan | What people report | Source |
|---|---|---|
| Heavy | 2 hours every day after work plus 4 to 6 hours on weekends | Indie Hackers |
| Medium | 2 hours each morning plus a few hours on Saturday, 10 to 14 hours a week | Indie Hackers |
| Light | 5 to 10 hours a week | Indie Hackers |
The same thread that reports 5 to 10 hours also mentions people putting in 50 to 60 hours a week. Those are people who work part-time at their day job. Their budget does not apply to you, so do not copy it.
Start lower than you think. Pick the plan you can repeat for four weeks in a row, not the one you could survive for a single week. Burnout is the outcome people with day jobs fear most, and it ends the project completely.
Then review at week four:
- Hit the budget every week? Add 30 minutes a day.
- Missed twice? Lower it.
- Feeling burnout coming? Cut the weekly hours, not the streak. Drop to the smallest daily change and keep the habit alive.
Write the plan as one sentence tied to something you already do
A slot that floats gets skipped. Tie it to something that already happens every day: coffee, the commute home, dinner being cleared.
Copy this and fill it in:
After [thing I already do every day], I build for [N] minutes at [place].
For example: "After I pour my first coffee, I build for 60 minutes at the kitchen table." Put it on the calendar as a block called "build" and put the sentence where you will see it tomorrow.
Make every task small enough to finish in one sitting
The test is one question: Can I start and finish this before I stop tonight? If the answer is no, split the task until it is yes.
Small tasks that start and finish the same day give you visible progress every day, and visible progress is what keeps you coming back. A task like "build the dashboard" will eat three weeks of evenings with nothing to show. "Add the empty dashboard page with a heading" is done tonight.
Cut features, not quality. Customers still deserve something that works, so when the project is too big, remove a feature. Andy Jiang's advice is to cut scope aggressively and to start with a library or a command line tool before a full web app. A smaller first form ships sooner, and you can grow it after.
Show the streak where you can see it
Make one commit or one visible change every day, however small. People on WIP recommend a contribution graph, a paper calendar or a streak counter, because a broken visible streak makes it harder to skip the next day.
A simple count works too: days you built in the last 14, divided by 14.
One missed day is fine. A run of empty days is the problem
A UCL study of habit formation found the average time to form a new habit was 66 days. Lead researcher Phillippa Lally said that "missing one opportunity did not significantly impact the habit formation process, but people who were very inconsistent in performing the behaviour did not succeed in making habits."
The range was wide: 18 days to 254 days depending on the person. And the study measured simple daily behaviors. Building a product is more complex, so your timing may differ. It was not a study of side projects.
What to take from it:
- Missed a day? Write "skip" on the calendar and do nothing else. No catch-up marathon.
- Plan for months, not weeks. 66 days is about 9 and a half weeks (66 / 7). Put "day 66" on the calendar as a checkpoint to look at your streak, not as a deadline.
- Skipping across a whole week is the real risk. That is what stops habits, not the single miss.
Here is a rule to test, and it is not from the study: if you hit fewer than about 5 of the last 7 days, cut the slot length in half before you change anything else. A 30-minute slot you hit beats a 90-minute slot you dread.
If this happens, do this
| What is going on | Do this |
|---|---|
| A task will not fit in one sitting | Split it until it starts and finishes the same day |
| The project is a full web app and nothing is shipping | Build a library or command line version first |
| You want to ship faster | Cut a feature, keep the quality |
| You missed one day | Write "skip," show up at the next slot |
| You missed most of a week | Halve the slot length |
| You are drained after work | Move the slot to the morning |
| You feel behind people who build full-time | Ignore the comparison, slower is normal |
| Burnout is coming | Cut weekly hours, keep a tiny daily change |
Mistakes that stall a side project
- Tasks too big for one sitting. No visible progress, so motivation drops.
- Marathons instead of steady days. Steady daily effort of 2 to 4 hours compounds over weeks and months. Bursts do not.
- Planning 20 hours a week on top of a full-time job with no rest. It ends in burnout.
- Working only after a full day. The hours are poor quality. Move the slot or shorten it.
- Calling a missed day a failure and quitting the routine. Quitting costs more than the miss did.
After the first version ships, switch to a weekly check
Once something is live, the problem changes from "how do I finish this" to "how do I keep it from breaking." That is a different routine, and the article on running a portfolio of small apps with a team of AI agents covers it.
If your slot is short, the way you work inside it matters too. The Claude Code setup for non-developers is a safe place to start if you want an AI coding agent doing part of the typing. Speculative, and not measured here: an agent may let a 60-minute slot cover more ground. Test it against your own finished-task count from the two-week energy check.
Do this in the next ten minutes
- Pick tomorrow's slot.
- Write the first task so you can finish it in that slot.
- Write your one-sentence plan: "After [thing], I build for [N] minutes at [place]."
- Set a calendar block called "build."
Stuck on a task you wish was already automated?
If one manual job keeps eating your short slot, email me with the task you want automated.