How to build a saas while working a full-time job

The math that actually works

Let's be real: you don't have as much time as you think. If you're working 40 hours a week, commuting, sleeping 8 hours, and need some semblance of a social life, you're looking at maybe 10-15 solid hours per week for side projects. That's roughly 2 hours a day if you're disciplined.

The founders who succeed with this constraint don't try to build the whole product. They build the smallest possible version that solves one specific problem for one specific type of customer.

Take this framework: instead of "build a project management tool," aim for "build a tool that helps solo developers track GitHub commits" (yes, that's a real example). Instead of "build an analytics platform," start with "build a dashboard that shows Stripe MRR." One is a business. The other is a feature. You need to ship the feature first.

At 10 hours per week, that's roughly 40-50 hours to get an MVP in front of people. That's one month. Do that four times and you've got real product-market feedback instead of theoretical ideas.

The time protection system

This is where most side projects die. You need to treat your building time like it's a client meeting—non-negotiable and scheduled.

Block specific hours

Pick 3-4 time slots that work for your life. Maybe it's 6-7am before work, or 9-11pm after everything settles down. The actual time doesn't matter as much as consistency. Your brain gets better at context-switching when it knows it's coming.

Some founders I know use Saturday mornings: 8am-12pm, four uninterrupted hours. Others do 5 one-hour sprints during the week. Experiment for two weeks, then commit to whatever feels least miserable.

Remove friction from your setup

You don't have time to faff around with environment setup. If you're a backend engineer, use Supabase or Firebase instead of spinning up your own database. If you're building a web app, use a framework with good defaults like Next.js or SvelteKit. You're not trying to be clever here—you're trying to ship.

Same goes for your workspace. If you work from home, have a specific chair or corner. If you go to a coffee shop, go to the same one. Remove the "where should I work" decision. Decision fatigue is your enemy.

Track what you actually shipped

Keep a simple log of what you completed each session. Not for productivity theater—for morale. There's something powerful about writing down "deployed comment feature" or "fixed auth bug" at the end of a 2-hour session. It's evidence that you're moving forward even if it doesn't feel like it.

This also helps you identify if you're actually using your time or just going through the motions. If you're consistently shipping nothing after a month, something is wrong with your approach.

The product strategy that fits your schedule

You need a product that can be built iteratively and shown to people quickly. Here's what works:

Start with a narrow slice

Don't build a "platform." Build a tool that does one thing, extremely well, for a specific person.

• Good: A tool that converts Stripe failed charge notifications into Slack alerts for SaaS founders.
• Good: A dashboard that shows which GitHub actions are costing you the most money.
• Bad: An all-in-one developer operations platform.

The narrow slice is buildable in weeks, not years. It also forces you to get real feedback early instead of building in a vacuum.

Pick a technical stack you know

This is not the time to learn Rust or master Kubernetes. Use what you already know. If you're a Rails developer, build in Rails. If you know Next.js, build in Next.js. Every hour spent learning a new framework is an hour not spent shipping.

The only exception: if you're learning something that directly saves you time. For example, learning how to use an AI code assistant (like GitHub Copilot) can legitimately speed up development. Learning a new language because you think it's cool will slow you down.

Plan for 2-3 weeks to MVP, not 2-3 months

Set a hard deadline. "The product goes live in 3 weeks" forces you to cut scope ruthlessly. You'll have a functioning product with real users faster than if you give yourself "as long as it takes."

This is counterintuitive, but artificial constraints create better products. You'll focus on the 20% of features that matter instead of perfecting the 80% that doesn't.

How to stay sane and not hate your day job

The trap with side projects is that they start consuming mental energy even during your day job. You're thinking about them in meetings, worrying about them during lunch.

This happens because the project feels fragile and uncertain. The antidote is forward momentum.

Small wins compound psychologically. If you shipped something every week—even tiny things—your subconscious believes the project will work out. If you go two weeks without tangible progress, your brain starts telling you it's a waste of time.

This is why the time blocking matters. When you know you have dedicated building time coming up, you stop obsessing about it during work. When you know you shipped something last week, you stop second-guessing the idea.

Also: be honest about how much energy you actually have. If you're mentally exhausted from your day job, forcing yourself to code at 9pm is counterproductive. Some weeks you'll get 15 hours. Some weeks you'll get 5. That's fine. The project isn't going anywhere.

The one thing that separates success from abandonment

It's not willpower. It's not coding skill. It's shipping publicly.

Tell people what you're building. Post about it online. Share early, ugly versions. Ask for feedback. Because the moment you have even one user, the project stops being "my side project" and becomes "a tool people use."

That shift changes everything. You go from motivating yourself to actually solving someone's problem. You go from "I should work on this" to "they're waiting for this."

So here's the real takeaway: ship something small in the next 30 days. Not someday. Not when you have more time. Now. Build the smallest possible thing that helps one type of person, get it in front of them, and iterate from there.

Your full-time job isn't a constraint on building a SaaS. It's a constraint that forces you to focus. Use it.