Yes, provided the project fits the capacity you actually have rather than the capacity you have on a good week. The mistake is almost never ambition about the idea. It is arithmetic about the time, and the arithmetic is wrong because hours are the wrong unit. What you actually have is a number of sessions, and each session costs you something before it produces anything.
Work out that number honestly and the rest follows: what to build, how narrow it has to be, and whether twelve weeks is realistic or whether you are describing a two year project to yourself in optimistic language.
- Two one hour sessions are worth much less than one two hour session, and the gap is the reload cost.
- Ending each session by writing the next action is the cheapest productivity gain available here.
- Evening hours are real but they are not decision hours. Schedule judgement for your best block.
- Pick something shippable in pieces, so a bad month costs you progress rather than the project.
- A launch that goes well reduces your building time, because support and marketing arrive with it.
Why "I do not have time" is usually the wrong diagnosis
Most people with a full time job and a side project do have some hours. What they do not have is uninterrupted, predictable, well rested hours, and those are not the same resource.
The specific cost is reloading context. Sitting down to a project you last touched nine days ago means rereading your own code, remembering what you were halfway through, and rebuilding the mental model of how the pieces connect. That is real work and it produces nothing. On a project of any complexity it can eat the first twenty or thirty minutes of every session.
If your reliable block is sixty minutes and reloading takes twenty five, you are not working five hours a week. You are working under three.
This explains something that otherwise looks like a character flaw. People who make good progress in a focused weekend and then stall on weeknights have not lost discipline. They have hit a session length below which the reload cost dominates, and no amount of motivation changes that arithmetic.
It also points at the fix, which is unglamorous and works: reduce the reload cost rather than hunting for more hours.
Measure capacity in sessions, not hours
Write down, for a normal week rather than an ideal one:
- How many blocks you actually get. A block is a stretch where you are not going to be interrupted and are awake enough to think. Count the ones that happened last week, not the ones you intended.
- How long each block is. Honestly, including the part where you make tea and read something first.
- What reloading costs you. Next time you sit down, note when you started and when you were actually working on the thing. Most people are surprised.
- Subtract. Productive minutes equal block length minus reload cost, times the number of blocks. Blocks shorter than the reload cost are worth roughly nothing and should be used for something else.
The number that comes out is usually between half and two thirds of the hours you would have claimed. That is not a reason to give up. It is the number you should be planning against, and planning against the real one is the entire difference between a project that finishes and one that quietly stops in week seven.
End every session by writing one line: the exact next thing to do, specific enough to start without thinking. Not "continue the export feature" but "add the filename field to the export dialogue, the function is in export.js line 40". Reload cost drops from twenty five minutes to about two, because you no longer have to rediscover where you were. This costs thirty seconds and buys back more time than any tool.
What three, five and eight hours a week can actually produce
Assuming the session discipline above, and assuming twelve weeks.
| Weekly capacity | Realistic outcome in twelve weeks | What to skip |
|---|---|---|
| About three hours | A verified problem, a manual solution delivered to a few real people, and a rough prototype of the one step worth automating | Do not attempt a public launch. The goal is knowing whether the thing is worth building. |
| About five hours | One narrow feature built properly, tested by a handful of people, working reliably for the common case | No accounts, no billing, no settings screen. One input, one output. |
| About eight hours | A small dependable product, documented, released, with the first round of feedback gathered | Still no roadmap and no second feature. Launch means finished, not started. |
Two things worth noticing. Even at eight hours a week the honest output is one small product, not a business. And at three hours the correct outcome is knowledge rather than software, which is a legitimate result and much better than three hours a week spent building the wrong thing for a year.
A twelve week shape
Most of this is not building, which is the point.
Weeks one and two: find and verify one recurring problem. Something you have personally, that happens often, and that you can describe in a sentence. Our guide on turning a work problem into a product covers how to tell a real one from an irritation.
Weeks three and four: solve it manually. By hand, for yourself and ideally for one other person. This produces the specification and tells you whether the outcome is genuinely wanted before you have written anything.
Weeks five and six: find five people with the same problem. Not to pitch. To ask what they did the last time it happened. If you cannot find five, that is information and it has arrived cheaply.
Weeks seven to nine: build the smallest dependable version. One complete job, end to end, for the common case. It should refuse to run rather than produce a wrong result.
Weeks ten and eleven: documentation and onboarding. This is always underestimated. A tool nobody can work out how to start is indistinguishable from a tool that does not exist.
Week twelve: release, watch, decide. Then stop and look at what people actually did rather than what they said.
If your capacity is three hours a week, this plan runs to about twenty weeks rather than twelve, and saying so up front is better than discovering it in week nine and concluding you failed.
Choose something you can ship in pieces
This is the constraint that matters most and the one that gets least attention.
If nothing you build is usable until all of it is built, then a bad month does not cost you a month, it costs you the project, because you come back to a pile of half finished work with no evidence that any of it was worth doing. Motivation does not survive that.
A project that ships in pieces gives you something usable at week four, week eight and week twelve. Each piece is small enough to finish inside your real capacity, and each one produces the only fuel that actually sustains a side project, which is somebody using the thing.
Practically, this means preferring a tool that does one step over a system that does five, and preferring something with no state to store over something with accounts and data, because accounts drag in password resets, deletion requests and support before you have a single user.
What not to build first
| Avoid | Why it does not fit a side project |
|---|---|
| Marketplaces | Useless until both sides exist, and you cannot build either half incrementally |
| Social platforms | Value comes from other people being there, so an empty version proves nothing |
| Anything needing moderation | Creates an unbounded, unpredictable daily obligation |
| Regulated areas | Compliance work arrives before revenue and does not scale down |
| All in one platforms | No version of it is finishable in twelve weeks |
| Audience dependent tools | Requires you to build a following first, which is a different project |
The common thread is that each of these is only useful at a scale you cannot reach in your available hours. A tool that is useful to one person on day one is the opposite, and that is the shape to look for.
Protecting the day job
Worth handling deliberately rather than hoping.
Read your employment agreement. Clauses about intellectual property, outside work and competing activity vary enormously between employers and jurisdictions. Some assign anything you create during employment, some only what relates to the business, some almost nothing. You need to know which yours is. Nothing here is legal advice, and if the wording is ambiguous the sensible move is to ask a qualified professional rather than to guess.
Keep everything separate. Your own device, your own accounts, your own hours. Not primarily for legal reasons but because a clean boundary removes any question later about whose work this is.
Do not build on confidential information. The problem you noticed at work can be a legitimate starting point. Your employer's customer list, internal data or proprietary process cannot.
Watch the burnout mechanism honestly. The failure mode is not dramatic. It is that the side project starts costing you sleep, the day job gets slightly worse, you compensate by working more, and both suffer. A project that only works when you are running at full output is not sustainable and it is better to reduce its scope than to find out the hard way.
The missed week is the real risk
Every side project meets a week where nothing happens. A deadline at work, illness, family, or simply being tired. That week is not the problem. What happens next is.
If getting back in costs an hour of rereading before you can do anything, the restart gets postponed, and one missed week becomes six. This is the same mechanism that kills personal productivity systems, and the same fix applies: make recovery cheap enough to happen on a bad day.
Concretely, that means the next action note, a short file describing where the project is and what is unfinished, and a deliberate decision that a missed week is normal rather than evidence of failure. Projects die from the second missed week, not the first.
A worked example
The tools on this site were built this way, and the honest version includes the parts that did not go to plan.
Grid Maker is what a small, shippable-in-pieces project looks like. It does one thing, it has no accounts and stores nothing, and a first usable version existed long before the current one. It is now the most visited page on the site. Nothing about it required a large block of time, because no part of it depended on holding the whole system in your head.
DreamTools AE is the opposite and it is instructive. It is a larger idea with more parts, less of it is useful in isolation, and it is still unfinished and marked as coming soon with no purchase option. That is not a secret plan, it is what happens when a project's smallest useful version is bigger than the capacity available. Publishing a payment page for it would have been the wrong order.
If there is a lesson worth taking, it is that the two projects differed in shape rather than in effort. One could be finished in pieces and one could not.
Small tools, built this way
Nine of them, each one narrow enough to finish and useful on its own. Free, no account, and everything runs in your browser.
See the toolsWhere this does not apply
This is about building a small software product alongside employment. It is not a route to replacing your income quickly, and any plan that depends on doing so is making an assumption about demand that twelve weeks cannot test.
It also assumes you can legally build the thing at all, which depends on your contract and your jurisdiction. If your employment agreement is restrictive, the correct first step is advice rather than code.
And if your real capacity turns out to be under two hours a week of usable time, the honest answer is that software is a poor fit, because a codebase you touch fortnightly costs more in reload than it returns. Writing, research or a manual service all survive that constraint far better.
Frequently asked questions
How many hours a week do I actually need?
Around five hours of genuinely productive time is enough for a small product in twelve weeks, but productive time is what remains after reloading context. If your blocks are short and infrequent, five hours on the calendar may be under three in practice, which is why measuring sessions matters more than counting hours.
Should I quit my job to work on it properly?
Not before something works and somebody uses it repeatedly. The job is what lets the project fail without consequence, and that freedom is worth more early on than the extra hours would be. The point is leverage and autonomy over time, not a dramatic exit.
What if I miss two weeks?
Expected, and survivable if restarting is cheap. Keep a next action note and a short file describing where things stand. If restarting requires an hour of rereading, it will not happen on a busy evening, and that is how projects end.
Can I use what I learned at work?
Noticing a problem at work is usually fine. Using your employer's data, code, customer information or proprietary process is not. Where the line falls depends on your contract and your jurisdiction, so read it and take proper advice if it is unclear. This article is not legal advice.
Should I build in public?
It helps some people and adds a second project for others, because posting consistently is itself a commitment. If your capacity is already tight, building quietly and writing afterwards costs less and loses little.
What is the most common reason these projects fail?
Choosing something whose smallest useful version is too large. Everything else, including missed weeks and lost motivation, tends to follow from having nothing usable to show after two months of work.
Where to start this week
Do not plan the project yet. Spend one week recording when you actually sat down, how long the block lasted, and how long it took before you were doing real work. Three data points is enough.
Multiply out the productive minutes and look at the number. Then choose a project whose smallest useful version fits inside it, which is a much narrower project than the one you had in mind, and that is the whole benefit of doing the arithmetic first.
How this was put together: this reflects how the tools on this site were built and where that process has broken down, including one project that is still unfinished for exactly the reasons described. It is not research, there is no survey of founders behind it, and we have quoted no success rates because we have none that would mean anything. The hour bands and the twelve week shape are starting points for your own arithmetic rather than findings, and the section on employment agreements is general information rather than legal advice.