How to Build a SaaS Product

A SaaS product is software that lives on the internet, not on your computer. You build once, your users pay a monthly or yearly subscription, and the code runs on your server. When it works, it's recurring revenue and a scalable business.

But most founders burn cash on ideas that customers don't want. I've built enough of them to know where that happens.

What actually makes a SaaS product work

A SaaS product that wins does three things in order:

1. Solves a real problem, something your users would pay to avoid doing manually, or a process that costs them time or money.
2. Is owned by the founder, not the customer, the business model is subscriptions to your software, not a service you deliver.
3. Can run with minimal hands-on work, no customer handholding per month; support is asynchronous or self-service.

If your idea fails on any of those, it's likely a consulting business, not a product. That's fine, but it's not SaaS.

Validation before you build

Building before you validate is the way most SaaS products die. You spend three months writing perfect code for something nobody needs.

Validation is simple: find 10-20 people who have the problem, and ask them if they'd pay for a solution. Not vague interest. Would they actually hand over a credit card or sign a contract?

Your minimum viable validation:

1. Find the problem in the wild. Read forums, job boards, Reddit, Twitter spaces where people with this problem hang out. Document what they say.
2. Talk to 10-15 people directly. Email, cold DMs, or calls. Ask specifically: "Do you have this problem? How much time or money does it cost you?"
3. Charge, even if you don't have a product. Take pre-orders or a letter of intent. Money talks. If five people commit to paying you, you know it's real.

If you can't find people who care, or they won't commit, the problem isn't big enough. Stop and pick a different one.

The MVP: what to build first

An MVP is the smallest version of your product that solves the core problem and nothing else. Not polished. Not pretty. Just enough to let a user do the thing they're paying for.

Common founder mistake: adding features because they're interesting. Nobody cares about your tech stack. They care that the software saves them time.

What to include in your MVP:

• The core job. One main thing your product does. If your SaaS helps agencies track client invoices, that's it. Not invoicing, reporting, tax calculations, time tracking. One job.
• Authentication. Users need accounts so their data is private.
• A simple way to get data in and out. A form, upload, or API so users can actually use it.
• Basic support. Email, or a help centre. People get stuck.

What to cut:

• Analytics. You don't need them yet. Watch how users behave in person.
• Advanced permissions. If you have two users, you don't need role-based access control.
• Custom branding. Nice to have. Doesn't solve their problem.
• Mobile apps. Build the web app first. If it works, the mobile version can come later.

Your MVP should take weeks or a month or two to build, not a year. If you're still building at month four, you've added too much.

Choosing your tech stack

A bad tech stack will slow you down. A good one lets you move fast and not regret it six months later.

For a SaaS MVP, you don't need anything fancy. You need:

• Frontend. React or Vue. Something that lets you build a snappy interface without reinventing the wheel.
• Backend. Node.js, Python, or Go. Pick the one your team knows. It matters less than you think.
• Database. PostgreSQL. It's battle-tested, cheap to host, and you won't outgrow it for a while.
• Hosting. Vercel, Railway, Render, or AWS. Don't host on your laptop. Pay a few pounds a month and let someone else manage the server.

What not to do:

• Don't chase the shiny stack. The newest framework is probably someone's hobby project.
• Don't pick something because your CV needs it. Pick what gets you to market fastest.
• Don't over-engineer before you ship. You'll rebuild it anyway once you understand what users actually need.

If you're one person or a small team, pick boring, proven tools. The best tech stack is the one that doesn't distract you from talking to users.

Finding your first users

You have an MVP. Now you need people to actually use it.

Your first users are not your target market. They're people who care enough about the problem to try something rough. They're patient. They give feedback.

Where to find them:

• Communities where they already hang out. LinkedIn, Twitter, Reddit, Slack communities, Discord servers, industry forums. Post honestly: "I've built something for [problem]. It's rough. Want to try it?"
• Cold outreach. Find people who complained about the problem on Twitter, or posted a job looking for a solution. Email them. One line: "I saw you mention [problem]. I built something for it. Thirty-second video link."
• Launch platforms. Product Hunt, Indie Hackers, Show HN. They're not a substitute for talking to users, but they'll get you attention and feedback fast.
• Your network. Friends, past clients, colleagues in your industry. They're your easiest sells because they know and trust you.

Aim for 20-50 users in the first month. They don't all need to be customers. Free tiers and beta access count.

Pricing and the first customers

Pricing is not complicated. Look at what your customers would save or earn if they used you instead of the manual way. Price at 10-30% of that annual value.

Your first pricing model:

• One price. One tier. Not Pro, Business, Enterprise. Just simple pricing. Charge something, even if it's low. You'll learn what users actually value.
• Charge from day one. Free users don't give you feedback. They don't care. Charge something, even if it's low. You'll learn what users actually value.
• Don't discount to close deals. Every discount trains your customer to negotiate. Stick to your price and walk away if they won't pay.

Once you have 10-20 paying customers, you'll see patterns in who buys, and you can specialise.

Growing without burning cash

Scaling a SaaS on a budget means two things: focus your marketing, and don't hire until you have to.

What actually works for early SaaS:

• Content. Write about the problem you solve. Not "buy my SaaS." Write the definitive guide to solving [problem], with or without your tool. Users will find you.
• In-person and calls. Sales calls with early customers. Webinars. Speaking at industry events. It's slow but it works.
• Direct outreach. Email people who fit your customer profile. Bad conversion rate, but it's free.
• Referrals. Ask your customers to recommend you. Most don't unless you ask.

What usually doesn't work:

• Paid ads to a product nobody knows. You'll burn money before you make it back.
• Hiring a salesperson. Can't scale sales if the product isn't right yet.
• A massive feature roadmap. Three more features won't grow you if your core product doesn't work.

The best SaaS companies grew slowly and profitably for two years before raising money. Some never raised. Focus on having a product people will pay for, then the growth follows.

When to raise money

You don't have to raise money to build a SaaS. But if you do, raise it when you have traction, not before.

Raising money when:

• You have 10-20 paying customers, and they're asking for features you can't build alone.
• You've proven people will pay, and you want to accelerate.
• You want to hire to move faster.

Not raising money:

• If you don't have revenue yet. Investors are not believers, they're co-founders with equity. Act like it.
• If you're not sure the idea is going to work. Raising gives you more time to fail, not less.

Bootstrapping (building without outside money) is a valid path. Some of the best SaaS products were built by solopreneurs in their spare time before they took a salary.

Common mistakes founders make

1. Building before validating. You'll fall in love with your idea. Customers are less romantic. Talk to them first.
2. Solving a problem nobody has. "Scratching your own itch" is good, but it's one user (you). Make sure ten others have it too.
3. Adding features because they sound good. The longer your backlog, the longer until launch. Build less.
4. Hiring before you understand your customers. You can't tell a salesperson what to sell if you don't understand the pain. Do it yourself first.
5. Chasing pricing models. Three tiers, usage-based pricing, freemium. Pick one and move on. Pricing is easy to change.