How I Build a SaaS While Working a Full-Time Job

Most advice about building a startup while employed comes down to one question: when do you quit? That's the wrong question for me, because I'm not choosing between two things. I have a full-time day job as an MIS and Data Analyst on a rural development programme in Arunachal Pradesh, I take on freelance client work on the side, and I'm building my own SaaS product in whatever time is left. Three tracks, not two. Nobody writing "quit your job" content is doing that math.

This isn't a productivity system post. It's what actually happens when you try to run three things at once, what breaks first, and why I'm not in a hurry to collapse it down to one.

The Math Nobody Talks About: It's Not Two Jobs, It's Three

Every "should I quit my job" article assumes a clean binary: employment on one side, startup on the other. That framing doesn't survive contact with how most builders I know actually operate. My day job funds my life. My freelance work through client projects funds the tools, the hosting, and the buffer that lets my SaaS not need to make money yet. My SaaS is the thing I actually want to exist in five years.

Each one protects the other two. The day job means a bad freelance month doesn't wreck me. Freelance income means I'm not pulling from savings to pay for Supabase and Vercel bills. And the SaaS is the only one of the three I'd keep doing even if it paid nothing, which tells me something about which one is actually the point.

The problem is that "three income tracks" doesn't fit in a listicle, so most content flattens it to "keep your job until your side hustle replaces it." That advice assumes the side hustle is singular. Mine isn't.

What a Real Week Actually Looks Like

The day job has fixed hours and real deadlines — programme reporting, field data, coordination with a funding body. That block of the day isn't negotiable and I don't try to make it negotiable. I learned early that trying to squeeze SaaS work into day-job hours just makes both worse: the reporting gets sloppy and the code gets written by someone who's half paying attention to a Slack notification.

Freelance work fills evenings and weekends, on a client-driven schedule. Some weeks that's light. Some weeks a client deadline eats an entire Saturday. My SaaS gets whatever's left after that — which some weeks is a real, focused stretch, and other weeks is forty-five minutes before I fall asleep fixing a broken migration.

I used to feel guilty about how inconsistent that made my SaaS progress look. I don't anymore. The inconsistency isn't a discipline problem. It's what happens when the thing you care about most is structurally the lowest-priority item on your calendar, because it's the only one of the three that doesn't have someone else waiting on it.

Why I Haven't Quit, and Why That's Not Fear

I could frame not quitting as playing it safe. That's not really it. The rural development work is genuinely meaningful to me in a way that has nothing to do with income — it's not a placeholder job I'm counting down from. If my SaaS started making real money tomorrow, I'd still have to think hard about whether to leave that role, and I'm not sure I would.

That's an uncomfortable thing to admit in a culture that treats "went full-time on my startup" as the only real proof of commitment. I've made peace with the fact that my path doesn't look like a founder story arc. It looks like three overlapping commitments that I'm trying not to let any of them fall over.

There's also a financial reality here that runway math makes obvious the moment you actually sit down and do it: a pre-revenue SaaS with no funding has a runway measured in how long your savings last, full stop. Freelance income extends that. A day job makes the runway question irrelevant, because there's no clock running out. I'd rather build slowly with no clock than fast with one.

What Actually Breaks First

It's not the hours. I have less free time than I used to, but I adjusted to that faster than I expected. What actually breaks is context-switching capacity. Going from a spreadsheet reconciling programme expenditure, to a client's copy revisions, to debugging an auth flow in my own codebase, in the same day, costs something that doesn't show up on a time tracker. By the third switch, the quality of my thinking on all three drops.

The second thing that breaks is momentum on anything that requires more than a few days of continuous focus. Deep architectural decisions on my SaaS — the kind that need you to hold the whole system in your head for a stretch — get worse when they're spread across five interrupted sessions instead of one uninterrupted one. I've made decisions on a Tuesday evening that I second-guessed by Thursday, not because they were wrong, but because I'd lost the mental model that made them make sense.

The third thing, and the one I was least prepared for, is that freelance client work and my own SaaS compete for the exact same kind of energy. Day-job work uses a different part of my brain — structured, reporting-focused, less ambiguous. But freelance and SaaS work both draw on the same well of "build something from scratch, make judgment calls, write good code." By the time I've spent that on a client project, there's less of it left for my own product, even if there's technically still time on the calendar.

The One Rule That Makes This Sustainable

I stopped trying to protect time for my SaaS and started protecting a specific kind of attention instead. Concretely: I don't touch my own codebase in the same sitting as client work, even if I technically have the hour for it. If I only have forty-five minutes and I just came off a client call, I do something low-stakes on my SaaS — triage a bug list, write a migration I already planned — instead of trying to make a real architectural call while running on client-brain.

That sounds like a small distinction, but it changed how much I actually got done. The old version of me tried to maximize hours logged. The current version tries to match the kind of task to the kind of mental state I'm actually in, which sometimes means doing less total SaaS work in a week but doing better work in the sessions I do have.

When I'd Actually Reconsider

I'm not against ever going full-time on my SaaS. I just don't think the trigger should be "it made a little money" or "I'm tired of juggling." The trigger I'm actually watching for is whether the SaaS reaches a point where the freelance and day-job time I'm spending elsewhere is the thing actively slowing it down, rather than the thing making it possible. Right now, freelance work funds tools I'd otherwise have to skip, and the day job funds the runway to not need the SaaS to work on any particular timeline. Neither of those is a constraint I'm fighting yet. They're the reason I get to build something I actually believe in instead of something I need to believe in because the mortgage depends on it.

If you're reading this while juggling something similar, the honest answer isn't a framework. It's that the juggling itself is a legitimate way to build, not a lesser one — as long as you're honest with yourself about which of the balls you'd keep in the air even if nobody was watching.

For more Startups & Indie Hacking posts, I write about the decisions behind what I build and why, without the survivorship-bias version of the story.