It's 11 PM, and I'm staring at a spreadsheet with one number in it: $47. That's the entire Stripe balance of my first SaaS attempt. Three months of nights and weekends, and I had built something nobody wanted.
I didn't know it then, but I was about to learn the most important lesson of indie hacking: validation before code. Not validation after launch. Not validation once you've sunk 200 hours. Before. The first time I built SaaS the right way, I validated the idea in 48 hours, built the MVP in three weeks, and had paying customers in month one. The difference wasn't genius engineering or a brilliant idea. It was ruthless prioritization, strategic tech choices, and protecting my sanity.
If you're thinking about building SaaS as a solo developer, I want to share exactly how to do this without burning out or wasting six months on an idea nobody will buy.
Why Solo Developers Can Build Profitable SaaS
The first objection I hear is always the same: "But I'm just one person. How can I compete?"
You're not competing on engineering resources or marketing budget. You're competing on speed and honesty. That's where solo developers win.
Here's the unit economics: A modest SaaS with 50 customers at $30/month is $18,000 MRR. That's a full-time income from a product built in two weeks by one person. Add another 50 customers and you're at $36,000. That's well above median salary in Bangladesh, Poland, or the Philippines—regions where I have friends running profitable one-person SaaS businesses right now.
The structural advantage is focus. You don't have product meetings, sprint planning arguments, or slow deployment cycles. You ship features directly based on what customers ask for. You own the entire stack, so you make informed tech decisions instead of committee compromises. This is the same discipline I learned building from my childhood tinkering with old hardware—constraints force creativity.
The hard part isn't the engineering. It's staying disciplined about scope and protecting your mental health. Most solo developers I know fail not because they can't code—they can—but because they burn out chasing feature creep or build the wrong product in the first place.
Validation Phase (48 Hours)
Before you write a single line of code, you need to know if anyone will pay for this.
I'm serious about 48 hours. You don't need a prototype, a landing page, or a pitch deck. You need evidence that real people have this problem and will pay to solve it.
Here's the framework I use:
Spend 8 hours on Reddit, Hacker News, and Twitter. Search for your idea's core problem. If someone is asking about it, screenshots of the threads are gold. If they're willing to pay now, even better. One of my SaaS ideas came directly from a Hacker News comment thread where someone said, "I'd pay $50/month for a tool that does X." That comment is worth 1,000 hours of speculation.
Find five people who have the problem. Not LinkedIn connections. Real people from communities where your target audience hangs out. Reach out with genuine curiosity: "I saw you talking about [problem]. Do you have five minutes to chat about how you solve this today?" Most will say no. Some will say yes. Those people are invaluable.
Ask these six questions:
- How are you solving this right now?
- What's broken about your current solution?
- How much time does this take you each week?
- How much would it cost you if you lost this workflow?
- Would you use a tool that solved this in [your simple vision]?
- If it existed, what's the most you'd pay per month?
Listen to their answers. Write them down. If three out of five say they'd pay $30+/month, you've got signal. If they say "I don't know, maybe," that's a soft no.
Red flag: If you pitch the idea and they go quiet, that's validation that this isn't urgent. Urgency = customers.
The output of this phase is a one-paragraph problem statement and a number: the dollar amount they'd pay. Nothing else. No mockups. No code. Just evidence.
Choose Your Stack for Speed
Now you know someone will buy this. The next mistake solo developers make is choosing a stack that looks impressive on GitHub instead of one that gets them to market in weeks.
I use this criteria: Can I build an MVP in 2–4 weeks alone? If the answer is no, that technology doesn't belong in my stack.
My current choice is Next.js + Supabase + Vercel. Here's why:
Next.js removes the frontend/backend boundary. I write API routes in the same codebase as the UI. No separate repos, no deployment choreography. Supabase gives me PostgreSQL, auth, and real-time subscriptions without managing infrastructure. Vercel deploys automatically on git push. I'm live in seconds.
The trade-off? I'm not building a custom distributed system or optimizing for millions of requests per second. I don't need to. A solo SaaS at $10K MRR doesn't need that complexity. Premature optimization is where solo developers lose weeks.
Alternative for API-first: Express + Fly.io. If your product is mostly API (no web UI), you move faster. But you lose the nice integration that Next.js gives you.
Don't choose: Kubernetes, microservices, GraphQL from day one, or any framework that has a slow feedback loop. You'll spend weeks configuring infrastructure instead of talking to customers.
Here's what authentication looks like in my current setup:
// pages/api/auth/[...nextauth].ts
import NextAuth from "next-auth"
import GitHubProvider from "next-auth/providers/github"
export default NextAuth({
providers: [
GitHubProvider({
clientId: process.env.GITHUB_ID,
clientSecret: process.env.GITHUB_SECRET,
}),
],
callbacks: {
async session({ session, user }) {
session.user.id = user.id
return session
},
},
})
And a simple API route that checks auth:
// pages/api/workspace/list.ts
import { getSession } from "next-auth/react"
import { supabase } from "@/lib/supabase"
export default async function handler(req, res) {
const session = await getSession({ req })
if (!session) return res.status(401).json({ error: "Unauthorized" })
const { data, error } = await supabase
.from("workspaces")
.select("*")
.eq("user_id", session.user.id)
if (error) return res.status(500).json({ error: error.message })
return res.status(200).json(data)
}
This is five minutes of setup and you have authenticated API endpoints. That's speed. For deployment, I use Vercel for the Next.js app and Supabase's hosted Postgres. If you prefer more control over infrastructure, the manual deployment approach with Docker and Nginx is still my go-to for larger systems, but for a solo SaaS MVP, managed services let you focus on product, not DevOps.
Build MVP in 2–4 Weeks
The MVP phase is where most solo developers fail. They add too much.
Here's my definition of an MVP: the minimum set of features that a customer would actually use. Not "technically could use." Actually use, right now, to solve their problem.
Ruthless scope exercise. Write down every feature you think the product needs. Now cut it in half. Then cut the remaining half. What's left is your MVP. If it sounds too simple, you've probably nailed it.
Let me be concrete. If you're building a content scheduling tool, the MVP is: upload content, choose a date/time, send it. That's it. No custom analytics, no team collaboration, no integrations. One person, one simple workflow.
Weekly sprint breakdown (assuming 40 hours):
Week 1 (10 hours coding): Database schema, authentication, one core workflow. Keep Saturday and Sunday completely free.
Week 2 (12 hours coding): Finish the core workflow, add one reporting page, basic error handling. Take Friday afternoon off.
Week 3 (12 hours coding): Rough UI polish, security audit of the auth flow, deploy to staging. Full weekend off.
Week 4 (6 hours coding): Final testing, bug fixes, deploy to production. Ship on Tuesday.
Notice the pattern? You're coding 40 hours in four weeks, but with deliberate rest. Most solo developers do 60–80 hour sprints and burn out by week 6.
Build incrementally. Deploy to production weekly. Don't wait four weeks to see if anything works. If something breaks in week 3, you have time to fix it. If you wait until week 4, you're launching with bugs and no energy to handle them.
Launch & Get First Customers
You've validated the idea, built the MVP, and deployed. Now you need customers.
Don't launch to "the internet." Launch to specific communities where your audience already hangs out.
Hacker News. If your product is for developers, post to Show HN. Write the post as if you're telling a friend what you built. Be honest: "I was frustrated that [problem], so I built [solution]. Here's what I did."
Reddit. Find three subreddits where your target audience posts. r/Entrepreneur, r/startup, r/sideproject. Write a post about your journey and include a link. Don't spam. One thoughtful post per community, and answer every comment.
Twitter. Post your launch story with a link. Tweet progress updates weekly. Retweet and reply to people in your space. Build in public.
ProductHunt. This is optional. If your product is a tool, Post here. If it's B2B SaaS, skip it.
Email. The five people you interviewed for validation? Email them the MVP. Ask for honest feedback. Two of them will try it and give you gold-tier feedback. One will actually pay.
The goal of launch isn't 10,000 users. It's 10 paying customers. That's enough to validate the business model and start iterating.
I launched my first SaaS with $0 marketing spend. I got my first three paying customers from a single Hacker News comment where I helped someone, and then they tried the product.
Growth Phase Metrics
Once you have customers, you're doing SaaS now. The metrics change.
Customer Acquisition Cost (CAC). How much did it cost to get this customer? If you launched for free on HN and someone signed up, your CAC is $0 + the time you spent building. If you buy an ad, your CAC is ad-spend / new customers.
For solo SaaS, aim for CAC < monthly value (ideally CAC < 3 months of revenue). If a customer pays $30/month and it cost you $100 to acquire them, that's a 3.3-month payback. That's acceptable.
Lifetime Value (LTV). How much revenue will this customer generate? If average customer stays 8 months at $30/month, LTV is $240. If you spend $100 to get them, your LTV:CAC ratio is 2.4:1. That's breakeven, barely.
Churn. What percentage of customers cancel each month? Aim for <5% monthly churn. If you have 50 customers and 3 cancel each month, that's 6%. You're losing customers faster than you're adding them, which means growth is flat.
Track these three numbers every week. If CAC is rising, something's broken with your launch strategy. If churn is rising, something's broken with your product. If LTV is rising, you're pricing it right.
Burnout Prevention
Here's what separates solo developers who make it from those who quit: they don't work 80 hours a week.
I learned this the hard way. My first two SaaS attempts, I worked nights and weekends until I hated code. I crashed. I didn't touch a personal project for six months.
My current rhythm is: 2 hours in the morning, 2 hours in the evening, one full rest day per week.
That's 24 hours of focused work per week while my main job pays the bills. It's slower than a startup sprint, but it's sustainable.
Morning block (6–8 AM). Deepest thinking. Architecture changes, complex bugs, customer research. No Slack, no emails. Just code and notes.
Evening block (9–11 PM). After the day job. I deploy fixes, respond to customer feedback, write documentation. Lower-cognitive work that doesn't demand the freshness of morning.
Rest day. Usually Sunday. I don't check dashboards, don't think about the product. I read, play guitar, have dinner with friends. This is non-negotiable.
Why does this matter? Because burnout isn't a myth. I know three solo developers who completely stopped coding for 1–2 years after the burnout hit. They had the skills, the money, the ideas. They just couldn't look at their laptop.
The irony is that this rhythm produces better products. Rested brains spot bugs faster. Rested brains say "no" to feature creep. Rested brains make smarter decisions.
If you're thinking about solo SaaS, this is the trade-off you're making: slower growth, but sustainable. If you're not okay with that, find a co-founder or work at a startup instead.
You now have the roadmap: validate in 48 hours, build in 4 weeks, launch to real communities, track the metrics that matter, and protect your energy. Every solo SaaS that made it to $10K MRR followed this pattern or something close to it.
The $47 Stripe balance from my first attempt taught me more than any course ever could. It taught me that validation is non-negotiable, that scope control is a superpower, and that your energy is your most limited resource.
Your first SaaS probably won't be your last. But if you follow this framework, your first probably will make money.
Tested environment: Node.js 20 LTS, Supabase CLI 1.141.0, Vercel CLI 33.5.0, Ubuntu 24.04