Building a SaaS by yourself is mostly a sequencing problem. The engineering is the easy part — you already know how to do that. What trips you up is deciding what to build at all, and in what order, when every decision is yours and there's no one to push back.
Why solo, and the scope trap
The appeal of solo is total ownership — every decision is yours, and you move at the speed of your own conviction. The cost is that the same property removes your brakes. On a team, someone questions the feature you're about to spend a week on. Alone, the only person who can say "we don't need this yet" is the same person who really wants to build it.
That's the scope trap, and it's sharper for an engineer because building is the comfortable part. The features most likely to escape into sprawl are the ones that are fun to engineer rather than the ones users are waiting for — an over-elaborate auth system, an analytics dashboard nobody asked for yet. The skill isn't building; it's not building.
Architecture decisions under one-person constraints
When you're the whole ops team, boring and fast-to-operate beats clever every time. The decisions that paid off:
- Supabase as a force multiplier — auth, database, and storage from one service is a lot of infrastructure you don't have to assemble or babysit. For a solo build, that consolidation is worth more than best-of-breed pieces you'd have to wire together and maintain.
- Edge where it removes ops, not where it adds it — using managed edge infrastructure to avoid running servers is a win; reaching for a distributed setup because it's interesting is a tax you'll pay alone at 2am.
- What I'd avoid solo — anything that needs constant operational attention, anything with a steep upgrade treadmill, anything where you're the only person who'll ever understand the clever bit.
The test for any architecture choice: can I operate this alone, half-asleep, six months from now?
The boring 80% — auth, billing, deploy
The unglamorous infrastructure — sign-up, sessions, payments, deploys — takes far longer than you expect and is most of the actual work of "a SaaS." The mistake I'd warn against is treating infrastructure as a feature to lovingly hand-build. Auth and billing are solved problems; reach for the managed solution and spend the saved time on the thing that's actually your product. Hand-rolling what you could have integrated is the most common way solo founders burn their first month.
What I overbuilt
The honest pattern across CodexGenAI and HireOS: the things I overbuilt were the things that felt like "real engineering" before there was a user to justify them — flexibility for cases that hadn't appeared, polish on flows nobody had walked yet. Every one of those was a YAGNI moment in hindsight. The tell, while it's happening, is when you're building for a hypothetical future user instead of a real current one. If you can't name the person who needs the thing this week, it can wait.
What I'd do differently
- Start with the riskiest assumption. Build the part most likely to be wrong first, so you find out cheaply.
- Ship to one real user before building the second feature. One user's reaction reorders your roadmap faster than any amount of solo planning.
- Take distribution as seriously as the build. The mistake that's easy to make as an engineer is assuming a good product gets found. It doesn't — the build and the getting-it-in-front-of-people are two separate jobs, and the second one can't wait until the first is "done."
FAQ
What's the hardest part of building a SaaS solo? Not the code — the sequencing and saying no. With no one to push back, scope creep is self-inflicted.
Should I build auth and billing myself? No. They're solved problems; integrate managed solutions and spend the time on your actual product.
What's the biggest mistake engineers make going solo? Treating distribution as an afterthought and over-engineering before there's a user to justify it.