Why I started building a SaaS while working full-time
I want to be honest about something before I start: my grand plan was to find a way to quit my day job and run a software SaaS full time. I also wanted to build something most engineering teams actually need, with a focus on making the development lifecycle better.
I work full-time as a software engineer building tools for a company in the financial sector. We have a large user base and use feature flags to manage deployments safely. We pay for a feature flag platform. It works. But over time I noticed something: the tools kept growing into things we didn't need. More configuration surfaces, more integrations, more dashboard real estate dedicated to capabilities that a working engineer rarely touches. The useful core kept getting buried under the accumulated weight of everything the product had become.
That observation sat in the back of my head for a while. Then it sharpened into something more specific: I started noticing the things that were missing. Not table-stakes flagging functionality; the tooling landscape has that well covered. I mean the features that would actually change how it feels to be an engineer working with flags day to day. Workflows that don't exist yet. The stuff where you think "why does nobody build this" and then go back to whatever workaround you've been using.
I kept a list. It kept growing.
That was the spark.
Not a eureka moment. More like a slow accumulation of observation that finally crossed some threshold into: I think I should just build this.
What I'm actually building
Zenmanage is a feature flag and rollout management platform. The foundation is the expected stuff: flags, environments, percentage rollouts, targeting rules, kill switches, and SDKs for the popular languages. I'm building that out now, getting the core right before I layer anything on top of it.
The part I'm more excited about comes after that. The features from that list. The things I kept thinking were missing. I'm not going to detail them here because I'm not there yet, and I don't want to over-promise on a roadmap I'm building in personal time. But that's the actual motivation: not to rebuild what already exists, but to build the layer on top of it that I kept wishing existed.
That distinction matters to me. It's what keeps this from feeling like "another feature flag tool" in my own head, which is a thing I have to keep in check because the category looks crowded from the outside.
And it is crowded. Feature flagging is becoming a commodity. The baseline expectations are high. If you're going to ask anyone to trust your platform with how they ship software, you need to cover a lot of ground just to be taken seriously. There's a real feature parity problem to solve before you can even make the case for anything differentiated. I think about that a lot. It's a long road to reach the point where the tooling is solid enough across the board that the things I actually want to build become the story.
The infrastructure side compounds this. Feature flags sound simple until the app using them is handling serious scale: high request volumes, low latency requirements, availability expectations that don't care about your side-project maintenance window. Building something that works for a small team today and doesn't fall over when that team's app grows is a real engineering problem, not a configuration one. I'm thinking about that architecture now rather than later, because retrofitting it is worse. At the same time I'm trying to stay disciplined about the frontend: build only what's actually needed, keep the interface honest. The trap I'm trying to avoid is the exact thing that frustrated me about existing tools: a surface that grew faster than the substance underneath it.
One other thing worth mentioning: I'm using AI heavily to build this. Not as a shortcut. As a force multiplier. Building a solo side project to enterprise-grade quality is a different challenge than building the same thing with a full team, and I've spent real time learning how to use AI tools in a way that produces code I'd actually be proud to ship. The slop problem is real. AI can generate a lot of plausible-looking code that doesn't hold up under scrutiny: wrong abstractions, missed edge cases, security issues that a reviewer would catch immediately. So part of this project has become learning how to work with AI in a way that raises the bar rather than lowering it: clear context, tight review, understanding what was generated rather than just accepting it. That's a skill in itself, and it's one I think matters more as these tools get more capable, not less.
The part nobody talks about: staying motivated after hour eight
One thing I want to be direct about: I take the boundary between my job and this project seriously. I don't want there to be any question of impropriety: no working on Zenmanage during work hours, no blurred lines. So I schedule it explicitly: nights and weekends, on my own time, on my own equipment. That constraint is non-negotiable for me, and honestly it makes the whole thing feel cleaner.
The tradeoff is that it's slow. Slower than you think. Not because the work is hard in any dramatic sense, but because the time is fragmented. An hour here after dinner. A longer session on Sunday morning. A week where something comes up at the day job and you make zero progress.
I went through a phase around month three where I questioned whether I was actually building something or just doing a very elaborate form of procrastination. I had a codebase but no customers. I had a product but no proof it would be useful to anyone other than myself.
What got me through that phase was something unglamorous: I went back to the thing that started this. The tools work. They're fine. But fine isn't the same as great, and great is achievable with the right developer-focused features built on top of the foundation. That gap kept being the answer every time I asked myself why I was still doing this.
It is not motivational poster stuff. It is just: do you actually care about the problem? Because the problem is what you're going to spend most of your time with. The market validation, the revenue graphs, the "I quit my job" thread. Those are downstream of whether you care enough about the problem to keep working on it when the output is invisible.
What I'd say to someone starting
A few things I've learned that feel worth sharing:
The day job is actually useful. Not just for the income, but for the perspective. I test assumptions about Zenmanage almost every week against real engineering problems I see at work. That feedback loop is slow but it's grounded.
You don't have to find the next big thing. Find something that actually motivates you. The market for "next big thing" ideas is crowded and most of them don't get built anyway. Something that genuinely bothers you, that you'd find satisfying to fix, is a better starting point than something that sounds impressive in a pitch.
Know the difference between what you need to reach feature parity and what your actual differentiators are. The parity work is a checklist. You have to do it, but it's not where the interesting decisions live. The differentiators are where you iterate, experiment, and learn. Treating them the same way leads to premature optimization on the wrong things: over-engineering features that need to stay flexible, or shipping the parity work half-finished because you got distracted by the exciting stuff.
Ship something that delivers on what it promises and does that well. The initial release doesn't have to be groundbreaking to be valuable. Before you ship anything, be able to clearly define the value it provides. Not a vague sense of usefulness. A specific thing it does for the person using it. If you can't articulate that, you're not ready to ship it. If you can, that's your bar, and hitting it cleanly matters more than adding more surface area around it.
I'm still employed. Still building. Right now I'm heads-down on the core, getting the feature flagging foundation solid before I start working on the features that are the real reason I started.
Happy to answer questions in the comments about the technical side, the tooling decisions, or just the experience of building in this space while working full-time.
This is not a success story yet. It's the part before the success story, if there is one. I'm writing it down while I'm in it because I find that more useful than retrospectives written from a comfortable distance.
