Building a SaaS With a Full-Time Job: The Honest Schedule

Photo by Vitaly Gariev on Unsplash

Building a SaaS with a full-time job means about ten genuinely focused hours a week, and the whole game is protecting them from everything else. Not the mythical evenings-and-weekends grind where you code until 2 a.m. and still show up sharp for standup. That version is a lie people tell on X. The real version is small, repeatable, and a little boring: two or three sessions a week where the door is closed and the phone is in another room, plus a lot of thinking done in the shower and the commute. This is the schedule I actually ran while shipping Coding Capybaras around a day job, including the parts that didn't survive contact with reality.

TL;DR

• Plan for ~10 focused hours a week, not 30. The constraint is attention, not calendar space.
• Full-time founders grow faster — MicroConf found full-time founders grew 2.2x faster than part-time ones — so part-time is a slower road, not a broken one. Choose it on purpose.
• Protect two or three deep sessions a week. Everything else (email, "research," Twitter) expands to fill whatever you leave open.
• Cut scope, not sleep. The founders who burn out on a day job cut the one thing they can't refill.
• You are not behind. Roughly 70% of independent SaaS founders earn under $1,000 MRR — the quiet middle is the normal place to be.

The math nobody wants to hear

Start with the arithmetic, because it reframes everything. A full-time job plus a commute plus sleep plus being a person leaves you a specific, small amount of time. If you're honest, it's not the "20 hours a week" you told yourself. After the job, the errands, the relationship, and the eight-ish hours of sleep you actually need to not make terrible decisions, most people building on the side have something like ten real hours to spend on their product.

Ten hours. That's the number to plan around. Everything downstream — scope, roadmap, how fast you can launch — flows from accepting it instead of fighting it.

The temptation is to fight it. To carve out the extra hours by stealing from sleep, or from the people who live with you, or from the recovery time that lets you think clearly. I tried all three. They work for about two weeks and then they collapse, and the collapse costs you more than the hours you borrowed. I've written before about the unglamorous reality of shipping indie SaaS, and this is the core of it: the constraint isn't your ambition, it's your recovery.

Here's the part that stings if you're competitive. Part-time is genuinely slower, and the data says so. MicroConf's State of Independent SaaS survey found that companies with full-time founders grew about 2.2 times faster than those with part-time founders. That's not a rounding error. It's a real gap, and pretending it doesn't exist just sets you up to feel like a failure when your part-time product grows at a part-time rate.

But slower isn't the same as doomed. The 2.2x gap is an argument for choosing part-time deliberately and setting your expectations to match — not an argument for quitting your job before you have a reason to. It's the difference between "I'm behind" and "I'm on the slower track on purpose, with a paycheck covering my rent while I learn." One of those is corrosive. The other is a strategy.

What actually fits in ten hours

Once you accept ten hours, the real skill is triage. Not everything you want to do fits, and the founders who succeed part-time are ruthless about what earns a slot. Here's roughly how the two lists shook out for me.

| Fits in a part-time week | Doesn't fit (cut or defer) | | --- | --- | | One meaningful feature or fix, shipped | A ground-up rewrite because the code "feels messy" | | Talking to 2-3 users | A 40-tab competitor analysis | | Writing one piece of content | A full content calendar you'll never maintain | | A small, reversible pricing experiment | A rebrand, a new logo, a landing-page redesign | | Fixing the thing that's actually broken | Optimizing something no user has complained about | | One marketing action you'll repeat weekly | Learning a new framework mid-project |

The pattern is obvious once it's on paper: the left column is shipping and talking to humans, and the right column is motion that feels like progress but isn't. When you have forty hours, you can afford some of the right column. When you have ten, every hour on the right column is an hour stolen from the left.

This is where non-technical founders have a weirdly specific advantage in 2026. AI coding tools compressed the "how do I build this" part enough that the bottleneck moved. SaaS Capital's 2025 survey found 69% of SaaS teams now use AI to eliminate bottlenecks that used to slow them down. When I came at this from an Excel-and-operations background rather than a CS degree, the leverage was enormous: a well-scoped session with Claude Code turns a feature that would've eaten a full weekend into a two-hour block. That doesn't buy you more hours. It makes each of your ten worth more.

The trap is letting that leverage seduce you into building more, faster, instead of building the right thing, slower. Ten fast hours spent on features nobody asked for is still ten hours wasted.

The schedule that actually held

I ran three schedules. The first two failed, and they failed in instructive ways.

Schedule one was "every night after dinner." It failed because after a full day of a demanding job, my 9 p.m. brain is not a building brain. It's a brain that opens the editor, stares at it, refactors one function, and calls it a night. I was present but not productive, and the gap between those made me feel worse than not showing up at all.

Schedule two was "big weekend blocks." Saturdays, four or five hours. This one failed slower and hurt more, because it worked just well enough to be tempting. But it made the product the thing that ate my weekends, which made the people around me resent it, which made me resent it. I've written about the loneliness that comes with solo building, and marathon weekend sessions are a fast way to manufacture more of it.

The schedule that held was smaller and stranger. Two weekday mornings before work — genuinely before, alarm ninety minutes early, coffee, no email, no Slack, one scoped task. Plus one weekend session capped at two hours, deliberately short so it didn't swallow the day. That's roughly six focused hours, and it consistently beat the "twenty hours" I used to schedule and never actually spend well.

The mornings worked for a reason worth naming: my decision-making was fresh, and there was a hard stop. The job start time was a wall I couldn't push, so I couldn't rabbit-hole. Constraints that you can't negotiate with are a gift. If you want the full version of how I think about defending these blocks, I broke it down in my actual time-blocking calendar — but the one-line version is: block by energy, not by category, and leave part of the week empty on purpose so life has somewhere to go that isn't your product.

The rest of the "work" happened off the keyboard. The commute and the shower did more architectural thinking than any keyboard session. By the time I sat down, I usually already knew what I was building, which is the only way two-hour blocks are enough.

Protecting the thing you can't refill

Every part-time founder eventually faces the same tempting trade: borrow from sleep to buy shipping time. Don't. This is the one non-negotiable I'd carve into the desk.

Sleep is the input to every other thing that matters — your judgment at the day job that pays your rent, your patience with the people who love you, and the quality of the ten hours you're trying to protect. Tired code is bad code, and tired decisions are worse, because a bad architectural call made at midnight can cost you a month of your scarce weekends to unwind. You cannot out-hustle a sleep deficit. It compounds against you.

The same logic applies to the relationships and the day job itself. The day job is not the enemy of the SaaS — it's the funding. It's the thing that lets you make good, patient, long-horizon decisions instead of desperate ones, because you're not betting the mortgage on next month's MRR. Treating your employer's hours with respect isn't just ethics, it's self-interest: a stable paycheck is what makes "part-time and profitable" a strategy instead of a countdown.

Here's the reframe that kept me sane. You are not behind. It feels like everyone on X shipped their thing in a weekend and hit $10K MRR by Tuesday, but that feed is a highlight reel. Freemius's 2025 State of Micro-SaaS report found that roughly 70% of independent SaaS products earn under $1,000 MRR, and about half are solo-founded. The quiet, slow, still-under-a-grand middle isn't the exception. It's where almost everyone actually is. Building next to a day job puts you squarely in the normal distribution, not below it.

I kept a private version of this reminder taped where I'd see it during the morning blocks. Some mornings the win was one bug fixed and one user emailed back. That's a good morning. Ten of those a month is a real product, built slowly, without setting your life on fire.

Frequently asked questions

How many hours a week do you really need to build a SaaS with a day job?

Plan for around ten focused hours a week, and treat six to eight genuinely focused hours as a good, sustainable week. The number that matters is quality attention, not calendar time — two sharp morning hours beat five tired evening ones. Consistency across months matters far more than any single big week.

Is it realistic to build a SaaS part-time, or should I quit my job first?

It's realistic, but slower — MicroConf found full-time founders grow about 2.2x faster. For most first-time founders, staying employed until you have real revenue signal is the lower-risk path, because the paycheck funds patient decisions. Quit when the product's growth, not your frustration, makes the math obvious.

When during the week is the best time to work on a side project?

Whenever your decision-making is freshest and there's a hard stop after it. For me that was two early mornings before work, when my brain was sharp and the job start time capped the session. Post-dinner coding sounds productive but usually isn't — you're spending your worst hours on your most important work.

How do I avoid burning out building a SaaS on the side?

Cut scope, never sleep. Keep sessions short enough that they don't swallow evenings and weekends whole, leave part of your week deliberately empty, and protect the day job and relationships that make the whole thing sustainable. If you're stealing recovery time to ship, you're borrowing against the exact resource the work depends on.

What should I not spend my limited hours on?

Rewrites, rebrands, competitor-analysis spirals, learning new frameworks mid-project, and optimizing things no user has complained about. These feel like progress and produce almost none. Spend your ten hours shipping one real thing and talking to two or three actual users; defer everything else.

The slow road is still a road

Building a SaaS with a full-time job is not the heroic all-nighter version you've been sold. It's ten quiet hours a week, defended against a hundred small thieves, spent shipping one real thing and talking to a few real users while a paycheck covers your rent and buys you patience. It's slower than going full-time — the data is honest about that — but slower is a pace, not a verdict. The founders who make it aren't the ones who found extra hours. They're the ones who protected the few they had and refused to trade away sleep, relationships, or the job that funds the whole thing.

I write about this side of the journey most weeks on the Coding Capybaras blog — the boilerplate itself is free if you want to see the product all these ten-hour mornings actually built.