Building a side project while employed full-time is mostly a scoping problem, not a time problem. The builders who ship are the ones who define "done" small enough that two interrupted hours a night can still move it forward. I haven't quit my job. I'm not planning to until the numbers make it obvious. Everything I know about shipping side projects comes from within that constraint, not from the other side.

The real reason side projects die, and it's not the job

The job gets the blame. "I just don't have time." I've said it. It's not accurate.

The projects that die don't die because the evenings ran out. They die because the scope was sized for a team with eight-hour days, not a solo developer with ninety minutes after dinner. You sit down on a Tuesday with two hours, and the next task is "build the dashboard": a task that would take a full day even with no interruptions. You make some progress, leave it half-done, come back Thursday and spend thirty minutes figuring out where you left off, make a bit more progress, leave it half-done again. Three weeks in, the dashboard is 60% there, nothing works end-to-end, and the project feels like a slog. That's not a time problem. That's a scoping problem wearing a time problem's clothes.

The other thing that kills side projects is the gap between the idea and the first working thing. If the first session that produces something real is session eight, you've asked motivation to carry you through seven sessions of setup and scaffolding. Motivation at the start of a project is high and depreciates fast. The quicker you get to something that works, even something small, the better your odds of finishing.

How to scope a side project for the time you actually have

The exercise I do before starting anything: write down the one user action that has to work for the product to be worth anything at all. One action. The whole first version is scoped around making that action work, cleanly, for a real user.

Not "users can manage their projects." One action: "a user can create a project, add three tasks, and mark one complete." That's the MVP. Everything else, reporting, collaboration, notifications, and settings, is a note in a backlog I might never open.

This feels like compromising the vision. It isn't. It's the difference between shipping in six weeks and not shipping at all. A product that does one thing properly, for real users, generates feedback you can build on. A product that's 70% complete across ten features can't be shown to anyone.

The rule I use: if I can't finish the next task in a single session, the task is too large. Break it down until it fits. "Add the POST /invite endpoint" fits in a session. "Build the invite flow" doesn't. The difference is whether you end the session with something finished or something half-done. Half-done is almost always worse than not started.

What a sustainable build rhythm looks like on evenings and weekends

A weeknight session starts around 9 pm, sometimes 9:30 if dinner runs long. The transition from the day job to the side project is the part nobody talks about, and it's the part that determines whether the session produces anything.

I don't open the side project the second the day job is done. There's a gap: dinner, some Counter-Strike if the evening allows, time where I'm not thinking about either thing. The context switch doesn't work if I try to force it immediately. An hour of actually switching off produces a better two-hour session than two and a half hours of grinding through mental fatigue.

When I sit down, I read the close-out note from the last session first. Not the code. The note. What I finished, the next task, and what's blocking. Two minutes of reading saves twenty minutes of reconstruction. Then I confirm the task for tonight fits in the time I have. If it doesn't fit, I scope it down before I start, not halfway through. Headphones on, the playlist on, and we're building.

Weekends are different. Saturday morning, before the family's fully up, is the best time I have: two to three hours of uninterrupted focus that doesn't feel like it's stolen from anything else. I use that block for the harder problems, the architectural decisions, anything that needs more context than a weeknight session can hold. Weeknights are for execution. Weekend mornings are for thinking.

I stop at 11 pm on weeknights. Not when the problem is solved. Not when I'm tired enough that stopping feels justified. At 11 pm. The hard stop is what makes the rhythm sustainable across months rather than productive for two weeks and burnt out for one.

Protecting your energy across a split-attention week

The day job takes more than time. It takes cognitive load. A day of difficult meetings, a production incident, a deadline that ran long: these don't just consume the hours, they consume the capacity to think clearly in the hours that follow. A session that starts from empty produces worse work than a session that starts from okay.

Your side project output is partly a function of how you manage the day job, not just how you manage the side project. Protecting energy means not burning everything at the day job and expecting the evenings to be productive on reserves.

Practically: know which evenings are write-offs before you sit down, and don't force a session that isn't there. A twenty-minute session where you re-read old code and close the laptop is better than the alternative: a two-hour session where you make bad decisions you'll spend the next session undoing. I've shipped bugs because I pushed through a session I should have skipped. The bugs cost more time than the session saved.

There are weeks where the day job is consuming, and the side project gets nothing. That's not failure. That's the model working: the day job pays the bills while the side project is built. Treating every low-output week as evidence that the side project is failing is how you quit something that just needed patience.

The tooling decisions that matter when your hours are limited

Since 2024, the infrastructure setup that used to take up the first week of any side project can now be done in an evening.

The first week of a side project used to be almost entirely setup: auth configured, database schema defined, ORM connected, deployment pipeline wired, environment variables sorted. None of that was the product. All of it was load-bearing, so you couldn't skip it, and it consumed exactly the sessions where motivation is highest.

That cost is now mostly optional. Full-stack AI builders that generate the infrastructure layer as native code, auth, schema, API scaffolding, deployment config, and land in your repo as code you own have made the "first week of setup" a twenty-minute problem. What you can build in a single session with Mayson is the baseline that used to take me three evenings of documentation, reading, and configuration. Those evenings now go to the product.

The distinction that matters: tools that generate a frontend and wire it to a managed backend service look fast at first, but hit a ceiling when you need backend logic that the managed layer doesn't support. I used Lovable on a project before I understood this distinction. The frontend came together quickly. Then I needed a background job for async processing, nothing exotic, and the platform's managed Supabase layer didn't expose what I needed cleanly. I spent three evenings trying to work around it before accepting that the architecture wouldn't hold. Three evenings I didn't have. The lesson isn't that Lovable is bad at what it does. It's that "what it does" has an architectural boundary, and discovering that boundary three weeks into a project built in stolen hours is expensive in a way it wouldn't be if you had unlimited time.

The tooling principle for limited-hour builders: pick tools where the cost of the wrong choice is low or visible early. Anything that can consume three sessions before the problem becomes clear is a risk you can't afford.

How to know when your side project is ready to show someone

Earlier than you think. Much earlier.

The instinct is to wait until it's polished: until the edge cases are handled, the UI is clean, the onboarding flow is smooth. That instinct is wrong and expensive. Every session you spend polishing before real users have touched it is a session spent optimising for assumptions about what they want.

The bar I use: Can a real user complete the core workflow without me guiding them? If yes, it's ready to show someone. Not ready to launch publicly. Ready to put in front of five people who represent the actual user and watch what they do.

The feedback from that session will entirely reorder your backlog. Features you thought were urgent will turn out not to matter. Things you hadn't considered will be the first thing every person asks for. The sooner you have that information, the less time you spend building in the wrong direction.

"Not ready" is usually a feeling, not a fact. When you interrogate it, it usually means "I'm nervous about what people will think" rather than "the product can't be used." Those are different problems. The first one doesn't get better with more sessions.

What "shipping" means when you're not doing this full-time

Shipping, for a still-employed solo developer, is not the same event as it is for a funded startup. No launch day, no press coverage, no single moment where everything changes. There's a deployed URL that five people are using, then ten, then twenty. The growth is slow because you have maybe eight hours a week to work on it, and four of those go to responding to user feedback rather than building new things.

That's fine. That's the model.

What shipping means in this context: the product is live, real users can access it without you setting things up for them, and you're making changes based on what they do rather than what you imagined they'd do. That's the threshold. Everything before it is building. Everything after it is a different kind of work.

The projects that never ship are the ones where shipping got redefined upward over time: the bar kept moving because the definition of "ready" kept expanding. Setting the bar explicitly and early, and holding it there, is the discipline that separates side projects that reach real users from those that live in private repos indefinitely.

I have a project currently making real money. It launched looking worse than I wanted it to. The users who pay for it have never mentioned the things I was embarrassed about. They care about whether it solves the problem. It does. That's what shipping means.

FAQ

Rishi is a developer based in Noida, working full-time in the software services sector and building solo products on the side. He writes about tooling, workflow, and the specific constraints of shipping without a team.