The Indie Hackers Guide to Building a SaaS

As an indie hacker, you build a SaaS by validating a real problem, shipping a lean MVP fast, launching to a small audience for direct feedback, and charging early. Start from a boilerplate so auth, billing, and infrastructure are already done, and spend your time on the part only you can build: the actual product. Speed and focus beat scope - get to paying users before you build more.

What is an indie hacker?

An indie hacker is a solo developer, or a very small team, who builds and ships software products independently, funds the work through customer revenue instead of venture capital, and keeps full control over product decisions.

This is different from a venture-backed startup in a few concrete ways. You are not raising a round before you have a product. You are not hiring a team before you have revenue. You are betting your own time against a problem you understand well, usually while working a day job or running the business solo full time.

Most indie hacker products fall into the micro SaaS category: narrow, single-purpose tools built for a specific audience rather than broad platforms meant to serve everyone. That narrowness is a feature. A smaller scope means less to build, less to support, and a clearer answer to "who is this for."

Step 1: Pick a problem worth solving

Pick a problem you already understand, ideally one you have hit yourself or watched someone else fight through repeatedly. Familiarity with the problem cuts down the guesswork later, because you already know the workarounds people use.

Talk to eight to ten people who currently deal with this problem. Ask what they use today, what they pay for, and what they have cobbled together with spreadsheets or duct-taped tools. If nobody has built a workaround, that is a signal the pain is not sharp enough yet to pay for a fix.

FastStaq came from repeatedly rebuilding the same infrastructure across SaaS projects: authentication, billing, permissions, background jobs, and admin tooling. My workaround was copying parts from older codebases and wiring the missing pieces together again. That showed me the real cost was engineering time, which supported selling the finished foundation as a one-time purchase rather than another monthly subscription.

Pro tip: Write the problem down in one sentence, naming exactly who has it worse than everyone else. If you cannot write that sentence, you do not have a validated problem yet.

Step 2: Build lean, borrow the boring parts

Every SaaS needs the same unglamorous plumbing before it can ship a single feature: authentication, billing, a database schema, background jobs, file storage, and a way to deploy the thing. None of it differentiates your product. All of it takes real time to build correctly.

This is where a boilerplate helps you build a SaaS MVP faster than starting from an empty repo. We built FastStaq to cover exactly this gap: a full-stack SaaS boilerplate you buy once for $299 with lifetime access and the full source code, no subscription, no per-seat fees. It is marketed as 350+ hours of pre-built work, and the sales site you would land on runs on the boilerplate itself.

Here is what that plumbing looks like when you build it yourself versus what ships out of the box:

The stack itself is a pnpm monorepo split into client/ (Next.js 16, React, Zustand, Tailwind, shadcn/ui), server/ (a dedicated Express and TypeScript REST API), and shared/. It ships with 120+ passing tests and automated CI checks, so you are not the first person to find the bugs in the plumbing.

Full disclosure: I run FastStaq, so weigh that against your own research. If you would rather assemble the stack piece by piece, that is a legitimate path too, just budget the time for it honestly before you commit to a launch date.

Step 3: Launch to a small audience and listen

Do not wait for a polished product before you launch. Ship a working build to a small group of real users first, not to an empty landing page collecting emails for months.

Post where indie hackers already gather: build-in-public threads on X, niche Slack and Discord communities for your specific audience, and your own mailing list if you have one. Ask directly for feedback on the core workflow, not on the color of the buttons.

Note: Building in public works best when you are specific. "I shipped invoice reminders that trigger after 7 days" gets more useful replies than "working on something exciting."

Expect the first version of your product to be wrong in a few places. That is the point of launching small: you find out which parts are wrong while the cost of changing them is still low.

Step 4: Charge early

Set a price and put it in front of real users during the first week, not after weeks of polish. A free tier with no path to payment tells you almost nothing about whether people will pay. A checkout screen tells you the truth fast.

If you are using FastStaq, the billing module gives you Stripe by default, with Lemon Squeezy available through a toggle if you would rather sell as a merchant of record. Both support one-time and lifetime pricing as well as subscriptions, and the source ships a credits and usage-metering module if your pricing model is consumption-based rather than seat-based.

For pricing strategy and positioning beyond the mechanics, our SaaS growth strategies guide covers how to set and adjust pricing once you have your first paying customers.

Note: FastStaq ships privacy and compliance tooling, consent management, data retention controls, and data export and deletion, but that tooling is not a certification. It does not make your product SOC 2 certified or GDPR compliant on its own; those are separate processes you still own.

The build-to-launch checklist

1. Write the problem in one sentence and name who has it worse than everyone else.

2. Talk to eight to ten people who currently deal with the problem, and note what they already pay for or hack together.

3. Decide the smallest version that solves the core problem, then cut everything else from the launch scope.

4. Start from a boilerplate instead of building auth, billing, and infrastructure from zero.

5. Wire up payments before you finish your first real feature: checkout and the customer portal should work end to end.

6. Ship a working build to a small group of real users, not to a waitlist page.

7. Post where your audience already gathers and ask directly for feedback on the core workflow.

8. Put a price in front of users during the first week.

9. Track one number that tells you if the product is working, activation or first payment, and check it weekly.

10. Decide what you will cut before the next release, not only what you will add.

Remember: A checklist only helps if you actually stop and check each item before moving to the next step. Skipping step 8 because the product "isn't ready" is usually a sign you are avoiding the real test.

FAQ

Do I need to code everything from scratch to build an indie SaaS?

No. Most of what a SaaS needs before it can ship a feature, authentication, billing, a database, background jobs, is the same across products. Starting from a boilerplate or an established framework lets you spend your limited time on the part that actually differentiates your product.

How much does it cost to start an indie SaaS?

Costs vary by stack choice and hosting, but the biggest cost for most indie hackers is time, not money. A boilerplate like FastStaq costs $299 one time with lifetime access to the source code, which replaces months of unpaid plumbing work with a working foundation on day one.

What's the difference between indie hacking and a startup?

A venture-backed startup typically raises outside capital, hires a team early, and optimizes for growth at scale. An indie hacker typically self-funds through customer revenue, stays solo or very small, and optimizes for reaching profitability without external investors.

How long does it take to launch a solo SaaS?

There is no fixed timeline, and anyone quoting an exact number is guessing. What you can control is the plumbing: skipping months of building auth, billing, and infrastructure from scratch by starting from a pre-built foundation shortens the path from idea to a working checkout.

Should I use a boilerplate like FastStaq?

If auth, billing, and database setup are not the part of the product you are excited to build, a boilerplate is worth the cost. If you specifically want to learn how to build that plumbing yourself, or your product has unusual infrastructure needs a general boilerplate will not fit, building it yourself is the better call.

Where to go next

Building a SaaS as an indie hacker comes down to four moves: validate the problem before you write code, build lean by borrowing the parts that do not differentiate you, launch to real users early, and charge from week one. None of these steps require a team or outside funding, just a clear problem and the discipline to test it fast.

Your next action: write the one-sentence problem statement from step 1, then go find eight to ten people who are living with that problem right now.

Further reading: For the mechanics of turning your problem statement into a shipped MVP, see build a SaaS MVP.

If the plumbing is the part holding you back, FastStaq gives you auth, billing, a Postgres database with 76 models, background jobs, and a deploy-ready Docker image for $299 one time, so you can spend your first weeks on the product instead of the setup.