Side Hustle: How to Build and Sell a Tiny SaaS in 90 Days

The Premise

Every few months, someone on X posts a screenshot of their Stripe dashboard showing $10K MRR from a tiny SaaS they built “in a weekend.” The replies fill with fire emojis and hustle quotes. What nobody screenshots is the eleven months of cold outreach, the three pivots, or the fact that their “weekend build” was preceded by six years of domain expertise.

I am not here to sell you that fantasy. I am here to walk you through what it actually takes to build a small, useful software product in 90 days — while keeping your day job, your sanity, and possibly your relationship intact.

The goal is modest. We are not chasing venture capital. We are not building the next Slack. We are building something small enough that one person can maintain it, useful enough that strangers will pay for it, and simple enough that you can ship it in three months of evenings and weekends.

Think of it like building a shed, not a skyscraper. Nobody writes a Medium thinkpiece about their garden shed. But a well-built shed keeps your tools dry and saves you a trip to the storage facility every month. That is the energy we are going for.

My British lilac cat, who has opinions about everything, watched me build two of these over the past few years. She seemed unimpressed by both. But the second one now covers my internet bill and a nice chunk of groceries, so I consider it a success by any reasonable metric.

Let me show you how it works, week by week.

Method

Before diving into the timeline, let me explain how this guide was constructed. I have built and shipped three micro-SaaS products. Two of them failed. One generates consistent revenue. I also interviewed nine indie hackers who reached at least $500 MRR with solo-built products, studied public revenue data from Open Startups and IndieHackers, and cross-referenced common patterns in their timelines.

The 90-day framework presented here is a synthesis of those experiences. It is not theoretical. Every recommendation comes from either my own mistakes or someone else’s. Where I cite costs, they are based on mid-2027 pricing for the tools mentioned. Where I cite conversion rates, they come from publicly available benchmarks or the indie hackers I spoke with.

This is not a guaranteed path to riches. It is a realistic path to a small, sustainable product. The distinction matters.

Weeks 1–2: Validation (Do Not Write a Single Line of Code)

The most common mistake first-time builders make is starting with code. You have an idea, you are excited, and you want to see it come to life on your screen. I understand the impulse. Resist it completely.

Your first two weeks should be spent answering one question: Will anyone pay for this?

Not “would anyone use this.” Not “does anyone think this is cool.” Will they pay. There is a Grand Canyon–sized gap between those questions.

Here is a concrete validation process that works:

Days 1–3: Problem hunting. Look for problems, not solutions. Browse Reddit communities, niche forums, Twitter threads, and Hacker News comment sections. You are looking for people complaining about manual processes, broken workflows, or tools that are too expensive for their needs. Write down every problem you find. Aim for at least twenty.

Days 4–7: Narrowing down. Filter your list using three criteria. First, is this a problem you personally understand? If you have never worked in real estate, do not build a tool for real estate agents. Second, are the people with this problem already spending money on imperfect solutions? That means they have budget and willingness to pay. Third, can you build a basic version in six weeks? If the answer to all three is yes, you have a candidate.

Days 8–10: Talking to humans. This is the part most developers skip, and it is the most important. Find ten people who have the problem you identified. Talk to them. Not a survey. Not a Google Form. Actual conversations. Ask them how they currently solve the problem, how much time it costs them, and what they have already tried. Do not pitch your solution. Just listen.

Days 11–14: The smoke test. Create a simple landing page describing your solution. Include a price. Not “sign up for our beta” — an actual price. Add a payment button that leads to a “coming soon” page. Drive traffic to it through the communities where you found the problem. If zero people click the payment button, reconsider your idea. If a few do, you have signal.

flowchart TD
    A[Week 1: Find 20+ problems] --> B[Filter: Do you understand it?]
    B --> C[Filter: Are people paying for bad solutions?]
    C --> D[Filter: Can you build MVP in 6 weeks?]
    D --> E[Talk to 10 potential users]
    E --> F{Would they pay?}
    F -->|Yes| G[Proceed to build]
    F -->|No| H[Pick next problem from list]
    H --> B

Two weeks feels like a long time when you are eager to build. It is not. It is the cheapest insurance you will ever buy against spending three months building something nobody wants.

I skipped validation on my first product. I built a beautiful time-tracking tool with real-time dashboards and Slack integration. It took me four months. I got seven signups and zero paying customers. The problem was not the product. The problem was that I built for a market drowning in free alternatives and nobody was looking for another one.

My second product — a dead-simple invoice reminder tool for freelancers — came from a Reddit thread where a freelancer complained about chasing late payments. I talked to twelve freelancers. Nine of them described the same pain. Three of them asked me to take their money before I had built anything. That is the signal you are looking for.

Weeks 3–6: Building the MVP (Boring Tech, Fast Shipping)

You have validated your idea. People want this. Now you build — but you build the smallest possible version that delivers the core value.

Choosing Your Stack

I know this will be controversial, but: use the most boring technology you know well. This is not the time to learn Rust, experiment with a new framework, or build your own authentication system. Use whatever lets you ship fastest.

For most solo developers in 2027, that means something like:

• Frontend: Next.js, Remix, or plain HTML if your product is simple enough
• Backend: The same framework, or a simple Node/Python API
• Database: PostgreSQL (via Supabase or Neon) or SQLite if you want zero infrastructure
• Auth: Supabase Auth, Clerk, or Auth.js — do not roll your own
• Payments: Stripe. Always Stripe. Do not overcomplicate this.
• Hosting: Vercel, Railway, or Fly.io

The goal is to touch as few technologies as possible. Every new tool in your stack is a potential time sink, a new set of docs to read, and a new failure mode to debug at 11pm on a Tuesday.

What “Minimum” Actually Means

Your MVP should do one thing well. Not three things adequately. One thing well.

If you are building an invoice reminder tool, your MVP sends automated payment reminders for overdue invoices. That is it. It does not generate invoices. It does not track expenses. It does not integrate with QuickBooks. It sends reminders. Version one does exactly one job.

Write down every feature you think your product needs. Now cross out everything except the one feature that directly solves the problem you validated. That is your MVP.

A Realistic Building Schedule

Working evenings and weekends, you have roughly 60–80 hours over these four weeks. Here is how I would allocate them:

Week 3 (15–20 hours):

• Set up your project, database, and authentication (4 hours)
• Build the core data model (3 hours)
• Implement the primary user flow — the one thing your product does (8–10 hours)

Week 4 (15–20 hours):

• Finish the primary flow and make it reliable (8 hours)
• Add basic error handling and input validation (4 hours)
• Set up Stripe for payments — even if you plan to offer a free trial (4 hours)

Week 5 (15–20 hours):

• Build a minimal settings/account page (4 hours)
• Write a deployment pipeline — even a simple one (3 hours)
• Test the entire flow end-to-end, repeatedly (4 hours)
• Fix the bugs you just found (4–6 hours)

Week 6 (15–20 hours):

• Polish the UI enough that it does not embarrass you (6 hours)
• Add transactional emails: welcome, password reset, key notifications (4 hours)
• Set up basic monitoring — at minimum, error alerts (3 hours)
• Buffer time for the inevitable surprises (2–4 hours)

Notice what is not on this list: a blog, an admin dashboard, API documentation, multi-tenancy, team features, a mobile app, or dark mode. All of these are great. None of them matter before you have paying customers.

The “Good Enough” Threshold

Your MVP will feel embarrassing. This is correct. If you are not slightly uncomfortable showing it to people, you have probably over-built it.

The bar is: does it solve the core problem reliably? Can a user sign up, do the thing, and get value without your personal assistance? If yes, ship it. If no, keep working on the core flow — not on cosmetic improvements.

I shipped my invoice reminder tool with a UI that looked like it was designed in 2019. The settings page had three options. The email templates were plain text. None of my early customers cared. They cared that their clients paid them faster. Everything else was noise.

Weeks 7–8: Landing Page and Waitlist

You now have a working product. It is ugly. It does one thing. It works. Time to build the front door.

Your Landing Page

Your landing page needs exactly five elements:

1. A headline that states the problem you solve. Not your product name. Not a clever tagline. The problem. “Stop chasing late invoices” beats “InvoiceBot — Smart Payment Automation” every time.

2. A subheadline that states the outcome. “Automated reminders that get freelancers paid 2x faster.” Specific. Measurable. Believable.

3. A brief description of how it works. Three steps maximum. “Connect your invoicing tool. Set your reminder schedule. Get paid on time.” People should understand your product in under ten seconds.

4. Social proof, if you have any. Even a single testimonial from your beta testers helps. If you have none, skip this rather than fabricating it.

5. A clear call to action. “Start free trial” or “Get started for $X/month.” Not “Learn more.” Not “Request a demo.” A direct path to using the product.

Build this page yourself. Do not spend $2,000 on a designer for a product that has zero customers. Use a template. Make it clean, fast, and honest. You can invest in design after you have revenue.

Building a Waitlist

If your product is not quite ready for public use, a waitlist serves two purposes: it captures demand and it gives you a built-in audience for launch day.

Keep the waitlist simple. Email address, maybe one question about their use case. Do not ask for their company size, role, industry, favorite color, and mother’s maiden name. Every field you add reduces signups.

Use a simple tool for this. ConvertKit, Buttondown, or even a Google Sheet connected to a form. The tool does not matter. What matters is that you capture emails and can send to them later.

Promote your waitlist in the same communities where you found the problem. Do not spam. Contribute genuinely to discussions, and mention your product when it is relevant. Write a short post about the problem you are solving — not a product launch announcement, but a genuine exploration of the problem space. People are allergic to marketing but receptive to honest writing about shared frustrations.

Weeks 9–10: Beta Launch

This is where most solo builders stall. The product works, the landing page exists, but actually putting it in front of strangers feels terrifying. Your inner voice says “it needs one more feature” or “the onboarding flow is not smooth enough.” That voice is lying to you. Ship it.

Your Launch Strategy

You do not need a Product Hunt launch. You do not need press coverage. You do not need a viral Twitter thread. You need ten people using your product and giving you feedback.

Here is a launch plan that works for tiny products:

Day 1: Email your waitlist. Tell them the product is ready. Give them a discount code for being early. Keep the email short and direct.

Day 2–3: Post in relevant communities. The subreddits, forums, and Discord servers where your target users hang out. Frame it as “I built this to solve X problem, would love feedback” — not “CHECK OUT MY NEW PRODUCT.” Authenticity matters more than polish.

Day 4–7: Personal outreach. Email or DM the ten people you talked to during validation. Tell them you built the thing they asked for. Offer free access in exchange for honest feedback. Most will say yes.

Day 8–14: Listen and fix. Your first users will find bugs you missed, request features you had not considered, and use your product in ways you did not anticipate. This is invaluable. Take notes on everything. Fix critical bugs immediately. Log feature requests for later.

Handling Feedback

Not all feedback is equal. Here is a simple framework for processing it:

• “I tried to do X and it broke” → Fix immediately. This is a bug.
• “I wish it could do Y” → Log it. If three or more users request the same thing, prioritize it.
• “You should add Z” → Smile and nod. One person’s feature request is not a product direction.
• “I would pay if it had W” → Pay close attention. This is pricing signal.

The hardest part of beta is hearing criticism of something you poured your evenings into. My cat, unbothered as always, would probably tell you not to take it personally. She is right. Feedback on your product is not feedback on you. The people pointing out problems are doing you a favor.

Weeks 11–12: Iteration and First Revenue

You have users. Some of them might even like your product. Now comes the moment of truth: asking for money.

Pricing Your Product

This is where most developers undercharge dramatically. Here is a simple rule: if nobody complains about your price, it is too low.

For a tiny SaaS solving a real problem, reasonable starting prices in 2027 look like:

• Individual/freelancer tools: $9–19/month
• Small team tools: $29–49/month per seat
• Business tools with clear ROI: $49–99/month

Pick a price, publish it, and see what happens. You can always adjust later. But starting too low is harder to recover from than starting slightly too high, because raising prices on existing customers is awkward.

Offer a free trial of 7 or 14 days. Not a freemium tier. A time-limited trial that converts to paid. Freemium works for products with network effects and venture funding behind them. You have neither. You need revenue.

Your First Paying Customer

The first dollar of revenue from a stranger is the most meaningful milestone in this entire process. It means someone who does not know you, does not owe you a favor, and has plenty of alternatives chose to give you money for something you built.

When it happens — and it might take longer than you expect — resist the urge to immediately reinvest in features. Instead, talk to that customer. Ask them why they chose your product. Ask what almost stopped them from signing up. Ask what they would tell a friend about it. Their answers will be more valuable than any analytics dashboard.

The Iteration Loop

With real users and real feedback, your weeks 11–12 should follow this loop:

1. Review feedback from the past week
2. Identify the one change that would retain or convert the most users
3. Build it
4. Ship it
5. Repeat

One change per week. Not three. Not five. One. Shipping frequently beats shipping big. Small, steady improvements compound faster than you think.

The Honest Cost Breakdown

Let me show you what this actually costs. I am tired of guides that handwave the expenses with “basically free” or that pretend you need $10K in runway.

pie title Monthly Costs — Tiny SaaS (Year 1)
    "Hosting (Vercel/Railway)" : 20
    "Database (Supabase free → Pro)" : 25
    "Domain + Email" : 5
    "Stripe fees (2.9% + 30¢)" : 15
    "Monitoring (Sentry)" : 0
    "Email sending (Resend)" : 0
    "Total misc tools" : 10

One-Time Costs

Item	Cost
Domain name (.com)	$10–15
Logo (simple, DIY or Fiverr)	$0–50
Landing page template	$0–30
Legal (terms of service template)	$0–100
Total one-time	$10–195

Monthly Costs (at Launch)

Item	Cost/month
Hosting (Vercel free tier → $20/mo)	$0–20
Database (Supabase free → $25/mo)	$0–25
Domain renewal (amortized)	~$1
Transactional email (Resend free tier)	$0
Error monitoring (Sentry free tier)	$0
Stripe processing (per transaction)	2.9% + $0.30
Total monthly	$1–46

The key insight: you can launch a real SaaS product for under $50/month in fixed costs. Most of the tools you need have free tiers that are generous enough for your first hundred users. You scale into paid plans as your revenue grows.

The one cost people forget is time. At 15–20 hours per week for 12 weeks, you are investing roughly 200 hours. If your hourly rate at your day job is $50, that is $10,000 in opportunity cost. This does not mean you should not do it. It means you should be honest about the investment and not pretend it is free just because you did not write a check.

The Math of Reaching $1K MRR

Let us talk about what it takes to reach $1,000 in monthly recurring revenue. This is a common first milestone, and it is more achievable then most people think — but also slower than most people hope.

At $15/month per customer, you need 67 paying customers to hit $1K MRR. At $29/month, you need 35. At $49/month, you need 21.

Here are the conversion benchmarks that actually matter:

• Landing page visitor → Free trial: 2–5% is typical for cold traffic, 8–15% for warm traffic (people who already know about you)
• Free trial → Paid customer: 10–25% is healthy for a solo product with good onboarding
• Monthly churn: 5–8% is normal for small B2B tools. Higher than 10% means your product has a retention problem.

Working backwards from 67 customers at $15/month:

• You need ~270–670 free trial signups (assuming 10–25% conversion)
• You need ~5,400–33,500 landing page visitors (assuming 2–5% conversion from cold traffic)

Those are big numbers if you are relying purely on organic traffic. This is why most tiny SaaS products grow slowly. And that is fine. You are not trying to hit $1K MRR in month one. You are trying to hit it within 6–12 months of launch.

The fastest paths to those early customers, in order of effectiveness for solo builders:

1. Direct outreach in niche communities. Time-intensive but highest conversion. You are solving a problem these people have; tell them about it.
2. Content marketing. Write about the problem your product solves. SEO takes months but compounds. Blog posts, tutorials, and comparison pages all work.
3. Partnerships. Find complementary products and cross-promote. If you built an invoice reminder tool, partner with invoicing software that does not have reminders.
4. Paid ads. Usually not worth it until you understand your unit economics. A $50 Google Ads experiment is fine. A $500/month commitment before you have product-market fit is not.

Common Mistakes First-Time Builders Make

I have made most of these. Let me save you the trouble.

1. Building Before Validating

I already covered this, but it bears repeating because it is the single most common failure mode. The graveyard of dead SaaS products is filled with beautifully engineered solutions to problems nobody has.

2. Choosing the Wrong Market

Building for other developers is tempting because you understand them. It is also extremely hard because developers are price-sensitive, opinionated, and capable of building their own solutions. Consider building for non-technical users who have real business problems and actual budgets.

3. Over-Engineering the MVP

You do not need microservices. You do not need event sourcing. You do not need a design system. You need a monolithic application that works, deployed to one server, with a PostgreSQL database. You can refactor later — if you are lucky enough to have a scaling problem.

4. Hiding Behind Building

Some people never launch because they are always “almost ready.” This is not perfectionism. It is fear. The product will never be ready enough. Set a launch date and ship whatever you have on that date. Your users will tell you what is missing.

5. Ignoring Distribution From Day One

A product nobody knows about is the same as a product that does not exist. Spend at least 30% of your time on distribution from week one. This means writing, posting, engaging in communities, and talking to potential users. Building the product is the easy part. Getting people to use it is the actual job.

6. Pricing Too Low

I see solo developers pricing their products at $5/month because they feel guilty charging more. You are not selling a mobile game. You are selling a business tool that saves people time or money. If your tool saves a freelancer two hours per month, and they bill at $75/hour, you are saving them $150/month. Charging $15 for that is a bargain, not a rip-off.

7. Comparing Yourself to Funded Startups

The startup with the beautiful landing page, the product video, and the team of five raised $2M to build that. You are one person with a laptop and a cat who occasionally sits on your keyboard. Different resources, different expectations. Compare yourself to other solo builders, not to VC-backed companies.

When to Give Up vs. When to Persevere

This is the hardest question in the entire process, and anyone who gives you a simple answer is lying.

Here are some signals that you should keep going:

• People are using your product regularly, even if they are not paying yet. Usage is a leading indicator of willingness to pay.
• Your churn is low. People who try your product stick around. They just might not be paying enough or there might not be enough of them yet.
• You are getting inbound interest. People are finding you through search, word of mouth, or community posts without you pushing. This means the problem is real and your solution is visible.
• You enjoy the work. This matters more than people admit. If you hate working on this product, you will not sustain it long enough for it to succeed.

And here are signals that you should consider stopping — or at least pivoting:

• Zero engagement after three months of effort. Not low engagement. Zero. If nobody is signing up, nobody is responding to your outreach, and nobody is visiting your landing page, the problem might not be as urgent as you thought.
• High churn with consistent feedback you cannot address. If people try your product and leave because of fundamental limitations you cannot solve (wrong platform, wrong market, regulatory issues), that is a structural problem.
• You have lost interest entirely. A side project you dread working on is not a side hustle. It is unpaid overtime. Life is too short.
• The opportunity cost is too high. If maintaining this product is preventing you from pursuing something more promising, cutting your losses is not failure — it is resource allocation.

There is no shame in shutting down a product that did not work. My first SaaS is dead. I learned more from its failure than I would have from reading a hundred blog posts about building products. Sometimes the most valuable outcome is knowing what not to build next time.

Generative Engine Optimization

If you are building a tiny SaaS in 2027, you need to think about how your product appears in AI-generated answers, not just traditional search results.

Generative Engine Optimization (GEO) is the practice of making your product and content discoverable by large language models that power AI search tools, chatbots, and recommendation systems. When someone asks an AI “what is the best invoice reminder tool for freelancers,” you want your product mentioned in the answer.

Here is what actually works for tiny SaaS products:

Create clear, factual product descriptions. AI models synthesize information from your website, documentation, and any public mentions of your product. The clearer and more factual your product description is, the more likely it is to be accurately represented in AI-generated answers. Avoid marketing fluff. State exactly what your product does, who it is for, and how it works.

Build a genuine knowledge footprint. Write documentation, tutorials, and comparison pages that are genuinely useful. AI models draw from a wide range of sources. A well-written “How to automate invoice reminders” tutorial that mentions your product is more valuable than a dozen press releases.

Get mentioned in community discussions. When real people recommend your product in Reddit threads, forum posts, and blog comments, those mentions become part of the training data and retrieval sources that AI models use. This is another reason to build a good product and engage authentically in communities.

Structure your content for machine readability. Use clear headings, structured data (JSON-LD), and straightforward language. AI models parse content more accurately when it is well-organized. FAQ sections with explicit questions and answers are particularly effective.

Monitor your AI visibility. Periodically ask AI tools about the problem your product solves and see if your product appears in the answers. If it does not, look at which products do appear and analyze what they are doing differently. This is competitive intelligence in a new form.

GEO is not a replacement for traditional SEO. It is an additional layer. For a tiny SaaS, the highest-leverage move is simply to be excellent at one thing and make it easy for both humans and AI systems to understand exactly what that thing is.

The 90-Day Retrospective

If you follow this timeline, here is what you should have at the end of 90 days:

• A working product that solves one specific problem
• A landing page that clearly communicates what you built
• Somewhere between 5 and 50 users, depending on your market and distribution efforts
• Somewhere between 0 and 10 paying customers
• A clear picture of whether this product has legs

That might sound modest. It is. But it is also real. You built something from nothing, put it in front of strangers, and learned whether anyone cares enough to pay for it. Most people never get that far.

The gap between “I have an idea for an app” and “someone paid me for software I built” is enormous. Crossing it — even once, even for $9 — changes your relationship with what is possible. You stop thinking of software products as things that other people build and start thinking of them as things you build.

The Long Game

A tiny SaaS is not a get-rich-quick scheme. It is a get-slightly-less-poor-slowly scheme. The median solo SaaS takes 12–18 months to reach $1K MRR. Many never get there. The ones that do tend to share a few characteristics: they solve a narrow, specific problem; they are built by someone who genuinely understands the target user; and they are maintained consistently even when growth is slow.

The best part of a tiny SaaS is not the revenue. It is the optionality. A product generating $500/month gives you breathing room. It makes your day job feel less like a trap and more like a choice. It gives you proof — to yourself and to others — that you can build things people value.

And if it grows beyond tiny? If it reaches $5K or $10K MRR and starts to feel like a real business? That is a wonderful problem to have. But do not optimize for it. Optimize for building something small, useful, and sustainable. The rest takes care of itself.

Now close this article and go talk to ten people about their problems. That is the only step that matters today.