Building a SaaS Side Project
Every engineer has an idea for a SaaS product. Most never ship it. Of those who do, most never get a paying customer. Of those who get customers, most never reach meaningful revenue. This chapter is about maximizing your odds of being in that small group that makes it work -- while keeping your day job and your sanity.
The indie hacker playbook is well-documented: start small, solve a real problem, charge from day one, and iterate based on customer feedback. The hard part is not knowing the playbook. The hard part is following it when every engineering instinct tells you to build more features before launching.
Start Small
The number one killer of side project SaaS products is scope. Engineers are trained to think about scalability, edge cases, and architecture. This training works against you when starting a side project.
Your MVP should embarrass you a little. If it does not, you spent too long building it.
Too big for an MVP:
- Full authentication system with SSO and RBAC
- Multi-tenant architecture from day one
- Custom dashboard builder
- API with comprehensive documentation
- Mobile app alongside web app
Right-sized MVP:
- Solves one specific problem well
- Email/password auth (use a service like Clerk or Auth0)
- Single-tenant, you deal with it
- One page that delivers the core value
- Ship it in 4-8 weeks of nights and weekends
The Weekend Test
If you cannot describe what your product does in one sentence, it is too complex. If you cannot build the core feature in two weekends, you are overbuilding.
Good one-sentence descriptions:
"Monitors your cron jobs and alerts you when one fails."
"Converts Figma designs to clean React components."
"Sends you a weekly summary of your AWS spending by service."
Bad one-sentence descriptions:
"A comprehensive platform for managing all aspects of..."
"An AI-powered solution that leverages..."
"A full-stack tool that integrates with everything..."
Solve Your Own Problem
The best side project SaaS products come from solving a problem you personally experience. Why? Because you are the user. You understand the pain. You know what features matter and which are noise. You can test the product yourself.
Examples of successful "scratch your own itch" SaaS:
Problem: "I keep forgetting to renew SSL certificates"
Product: SSL certificate monitoring and auto-renewal alerts
Problem: "I waste 30 minutes every morning checking dashboards"
Product: Automated daily summary of key metrics, delivered by email
Problem: "Our team's code reviews take forever to get assigned"
Product: Automated code review assignment and tracking
Validating the Problem
Your own experience is a starting point, not proof. Before building, validate that other people have the same problem and would pay to solve it.
Validation steps (do these BEFORE writing code):
1. Search for the problem in forums, Reddit, HN, Stack Overflow
- Are people complaining about this?
- How are they currently solving it?
2. Talk to 5-10 potential users
- "How do you handle X today?"
- "What does it cost you in time/money?"
- "Would you pay $Y/month for a solution?"
3. Check for existing solutions
- If nothing exists, ask why (maybe the market is too small)
- If solutions exist, identify what they do poorly
4. Pre-sell or create a landing page
- Describe the product, add a "Join Waitlist" or "Buy Now" button
- If nobody signs up, reconsider
Charge From Day One
Free products attract free users. Free users give you vanity metrics, not revenue. Charge from the moment you have something that delivers value.
Why Engineers Resist Charging
Common excuses:
"It's not ready yet" → It never will be. Ship it.
"Nobody will pay for this" → Test that assumption. Do not decide for them.
"I need more features first" → Your first customer needs one feature that works.
"I'll add pricing later" → Later never comes. Free users resist converting.
"My competitor is free" → Free competitors often disappear. Paid products survive.
Pricing Your SaaS
Start simple. One or two pricing tiers. You can always add complexity later.
Common indie SaaS pricing patterns:
Simple:
Free tier: Limited usage (up to 3 projects, basic features)
Pro: $19/month (unlimited, all features)
Two-tier:
Starter: $9/month (individual use)
Team: $29/month (5 seats, collaboration features)
Usage-based:
Pay per: $0.01 per API call, $5 per 1,000 emails, etc.
Best for: Infrastructure and developer tools
Price higher than you think. You can always lower prices. Raising prices later is much harder. A product at 1,000 MRR. A product at $9/month needs 112 customers for the same revenue. Finding 35 customers is dramatically easier than finding 112.
The Indie Hacker Playbook
Build in Public
Share your progress openly. Tweet about what you are building. Write about your decisions. Post your revenue numbers. Building in public does three things:
- Creates accountability (you told people, now you have to ship)
- Builds an audience before launch (potential customers are already watching)
- Generates feedback early (people will tell you if your idea is terrible)
Building in public cadence:
Weekly: Share progress update (what you built, what you learned)
Monthly: Share metrics (users, revenue, churn)
Always: Be honest about struggles and failures
Validate Before Building
Spend 2-4 weeks validating before spending 4-8 weeks building. The ratio of validation to building should be at least 1:3.
Validation timeline:
Week 1: Research the problem space, find communities
Week 2: Talk to potential users, survey, landing page
Week 3: Analyze feedback, decide go/no-go
Week 4: If go: start building MVP
Building timeline:
Week 5-6: Core feature, basic UI
Week 7: Payment integration (Stripe)
Week 8: Polish, deploy, launch
Start With One Customer
Your first customer teaches you more than any amount of research. Find one person who has the problem, show them your solution, and get them to pay. Then find the second. Then the third.
The first 10 customers:
Customer 1: Personal network, manual onboarding
Customer 2-3: Referrals from customer 1
Customer 4-5: Community posts (Reddit, HN, forums)
Customer 6-10: Content marketing, word of mouth
After 10: Start thinking about scalable acquisition
Do not think about scalable growth until you have 10 paying customers. Before that, growth hacks and ad campaigns are premature. Your product is not proven enough to scale.
Realistic Revenue Expectations
Let us be brutally honest about what indie SaaS revenue looks like.
Month-by-Month Reality
Month 1 (launch): $0-200 MRR (1-5 customers)
Month 3: $200-500 MRR (if things are going well)
Month 6: $500-2,000 MRR (product-market fit emerging)
Month 12: $1,000-5,000 MRR (healthy growth)
Month 24: $3,000-15,000 MRR (compounding)
Most products never get past month 3 revenue levels.
The ones that do usually take 12-18 months to reach $5,000 MRR.
MRR Is Addictive
Monthly Recurring Revenue is the most motivating metric in business. Watching it grow from 100 to 1,000 creates a dopamine loop that keeps you shipping. This is both a feature and a bug.
The feature: MRR motivation will push you through the hard weeks when you want to quit.
The bug: MRR obsession can lead to checking your Stripe dashboard 40 times a day instead of actually improving your product.
Healthy relationship with MRR:
Check revenue: Once daily, in the morning
Analyze trends: Weekly
Strategic review: Monthly
Unhealthy relationship with MRR:
Check revenue: Every hour
Panic at churn: Every cancellation feels personal
Celebrate spikes: Every new customer gets a tweet
The Technical Stack
For a side project, optimize for speed of development, not architectural purity.
Use whatever stack you already know. Do not use a side project as an excuse to learn a new framework. Ship fast. You can rewrite later if the product succeeds. Use PostgreSQL for your database, Stripe for payments (non-negotiable), and a managed auth service. Keep infrastructure costs under 500/month on infrastructure for a product earning $200/month.
Marketing for Engineers
This is where most technical founders struggle. Building the product is the easy part. Getting people to find it and pay for it is the hard part.
Channels That Work for Developer Tools
Channel Effort Payoff Timeline Best For
-------------------------------------------------------------
Hacker News launch Low Immediate spike Initial users
Reddit communities Low Gradual Niche products
SEO content High 3-6 months Long-term growth
Twitter/X building Medium 1-3 months Developer audience
Product Hunt launch Medium Short spike Awareness
Direct outreach Medium Immediate Enterprise
Open source companion High 6-12 months Developer trust
The Launch Checklist
Before launching:
- Landing page with clear value proposition
- Working payment flow (test it yourself)
- At least one testimonial or beta user quote
- Support email or chat set up
- Basic analytics installed
Launch day:
- Post on Hacker News (Show HN)
- Share on relevant Reddit communities
- Post on Twitter/X with screenshots
- Email your personal network
- Submit to Product Hunt (optional, schedule separately)
After launch:
- Respond to every comment and question
- Fix bugs reported by real users immediately
- Follow up with every trial signup
- Write a "lessons learned" post (builds audience)
When to Quit vs When to Push Through
Most side projects should be killed, not nursed. Here is a framework:
Keep going if:
- Users who find your product love it (even if there are few)
- Revenue is growing, even slowly
- You are learning things that make the product better
- You enjoy working on it
Consider quitting if:
- After 6 months, you have zero paying customers
- Users sign up but never come back
- You dread working on it every weekend
- The market turned out to be smaller than you thought
- A well-funded competitor launched the same thing
Quitting is not failure. It is resource allocation. The time you spend on a dead project is time you could spend on the next idea, which might be the one that works.
Common Pitfalls
- Building for 6 months before showing anyone. Launch your MVP in 4-8 weeks. Real user feedback beats your assumptions every time.
- Adding features instead of finding customers. If you have zero customers, another feature will not help. Go talk to people.
- Pricing too low. 29/month attracts customers who value their time.
- Ignoring churn. If 10% of customers leave every month, you need to replace them just to stay flat. Fix churn before chasing growth.
- Over-engineering the infrastructure. You do not need Kubernetes for 50 users. A single VPS with a database handles thousands of requests per second.
- Not setting up Stripe from the beginning. If you do not have a way to collect money on day one, you will delay it indefinitely.
- Spending money on ads before product-market fit. Ads amplify what is already working. If nothing is working, ads just burn cash faster.
- Comparing your month 3 to someone else's month 36. That indie hacker with $50,000 MRR started where you are. You are seeing the highlight reel.
Key Takeaways
- Start with the smallest possible product that solves one real problem -- build an MVP in 4-8 weeks
- Validate demand before writing code: talk to users, create a landing page, pre-sell
- Charge from day one -- free products attract users who will never convert to paid
- Price higher than your instinct suggests -- 9/month
- Most indie SaaS products earn 5,000 MRR typically takes 12-18 months
- Use the tech stack you already know -- speed to market matters more than architecture
- Spend at least 30% of your time on marketing, not just building features
- Kill projects that show no traction after 6 months and move on to the next idea