I’ve shipped two SaaS products to production. Not side projects with a landing page and a waitlist — real platforms with real users, real revenue, and real 3 AM pages when something breaks.
I did it alone. No co-founder. No team. No funding. Just me, a Hetzner VPS, and a lot of caffeine.
Here’s what I learned.
The Myth of the Team
When you read about successful SaaS companies, the story always starts with a team. A founder, a technical co-founder, maybe a designer. There’s a reason for this — building software is hard, and doing it alone is harder.
But “harder” isn’t “impossible.” And the constraints of building solo forced me to make decisions that a team might have overthought into oblivion.
When you’re alone, you can’t have a two-hour debate about whether to use a monorepo. You just pick one and move on. You can’t spend three weeks on a design system. You use Tailwind and ship. The absence of consensus becomes a feature.
Constraint #1: You Can’t Build Everything
The first thing solo building teaches you is ruthless prioritization. When I started ScoreResume, I had a list of 40 features I wanted to build. I shipped with 6.
Those 6 features were the ones that directly solved the user’s problem: upload resume, paste job description, get a score, see what’s wrong, fix it, re-score. Everything else — the dashboard, the history, the templates, the export options — came later. Some of them never came. And that was fine.
The features you don’t build are the features you don’t have to maintain.
This sounds obvious, but it’s incredibly hard to practice. Every feature feels essential when you’re imagining the product. Very few are essential when you’re watching real users use it.
Constraint #2: You Are the Bottleneck
In a team, when the backend is blocked, someone works on the frontend. When the frontend is blocked, someone works on DevOps. When everything is blocked, someone writes tests.
When you’re solo, you are the backend, the frontend, the DevOps, and the test writer. If you’re blocked, the entire company is blocked.
This taught me to never block myself. If I’m waiting on an API key, I switch to the database schema. If the LLM is being slow, I work on the UI. If I can’t figure out a bug, I go for a walk and work on something else.
The key insight: always have a clear next task that doesn’t depend on the current blocker. This is a superpower. Most people stare at the blocker. Solo builders learn to orbit around it.
Constraint #3: You Can’t Hide from Users
In a company, there’s a support team. There’s a product manager who reads the feedback. There’s a designer who runs user interviews.
When you’re solo, you are the support team. Every bug report lands in your inbox. Every confused user is your problem. Every feature request is a direct line to the person building it.
This is uncomfortable. It’s also the most valuable thing about building solo.
When a user emails you saying “I don’t understand what this score means,” you don’t file a ticket. You realize your UI is confusing, and you fix it that afternoon. The feedback loop is instant. There’s no game of telephone. No prioritization meeting. Just: user says it’s broken, you fix it.
The Loneliness Is Real
I won’t romanticize this part. Building solo is lonely.
There’s no one to celebrate with when you ship a feature. No one to whiteboard with when you’re stuck on architecture. No one to tell you “that’s a terrible idea” before you spend a week building it.
I handled this by being public. I wrote about what I was building. I shared my metrics. I talked to other indie builders on Twitter. The internet became my team — not in a sentimental way, but in a practical one. Feedback came from the community instead of a co-founder.
What I’d Do Differently
If I were starting over, I’d change three things:
-
I’d start marketing on day one. I built both products for months before telling anyone. That was months of zero feedback. I should have put up a landing page the day I wrote the first line of code.
-
I’d charge sooner. I waited too long to add payments. Free users give you different feedback than paying users. Paying users tell you what’s actually valuable. Free users tell you what’s nice to have.
-
I’d write more. Every blog post I’ve written has brought in more traffic than any feature I’ve shipped. Content compounds. Features don’t.
The Real Lesson
Building solo isn’t about being a 10x developer. It’s not about working 16-hour days. It’s not about being smarter than everyone else.
It’s about finishing.
Most people can start. Most people can build a prototype. Most people can get 80% of the way there. Very few people can take a product from “it works on my machine” to “it works for 300 users at 3 AM.”
That last 20% — the deployment, the monitoring, the error handling, the edge cases, the support, the billing, the backups — that’s where most projects die. Not because it’s technically hard, but because it’s boring and unglamorous and there’s no one to do it but you.
If you can find the discipline to finish, you can build solo. If you can’t, no amount of technical skill will save you.
I’m still building. AttemptIQ and ScoreResume are both live, both growing, both breaking in new and creative ways. I wouldn’t trade it for anything.