Building a SaaS Product: The Parts That Decide Whether Users Stay

People don’t sign up for a product because of its password reset flow. They can leave because of it, which shapes almost everything about building a SaaS product.

That’s the lesson under every other lesson here. The feature you’re excited to build is the reason someone tries your product. Whether they stay is decided by the parts nobody puts in the pitch: sign-up, billing, the first empty screen, the email that arrives when a card fails, and the months of upkeep after launch.

What follows applies to any SaaS product, and to any web app that people log into every day. Each lesson comes with why it matters and what to do instead.

1. One user, one job

The first version should serve one kind of user doing one job well. Everything else can wait.

Why it matters. Every extra audience multiplies the product. A second type of user means a second onboarding path, a second set of permissions, a second pricing question and twice the empty states. The core job gets less attention at the exact moment it needs the most.

What to do instead. Before any design, write one sentence: who it’s for, the job, and what they use today. Something like: “freelance designers use this to send invoices instead of a spreadsheet.” Test every feature idea against that sentence. If it doesn’t serve it, it goes on a “later” list, which is kinder than “no” and nearly as effective.

2. Accounts, billing and email are product, not plumbing

The flows around your main feature are part of the product, and often the first part people meet.

Why it matters. A confusing sign-up loses people before they’ve seen anything. A declined card handled with a vague error, or not handled at all, can quietly lose a customer who wanted to stay. And transactional emails are the one piece of your product that lands in someone’s inbox next to mail from people they trust.

What to do instead. Design these flows with the same care as the main screen. A minimum list:

• Sign up, verify email, log in, reset password
• Invite a teammate, accept an invitation
• Start a trial, upgrade, downgrade, cancel
• Card declined, card expiring, payment retried
• Receipts an accountant can actually use
• Export data, delete account

Hand card handling to an established payment provider rather than building it yourself. Anyone who stores, processes or transmits card data has to comply with PCI DSS, the card industry’s security standard. A provider’s hosted checkout page or payment fields send card details straight to the provider without passing through your servers. That reduces your PCI obligations, though it doesn’t remove them. Stripe’s integration security guide explains the difference.

Providers can also take on part of the failed-payment work. Stripe, for example, can retry failed subscription payments automatically and email customers when a payment fails or a card expires. Turn those features on, then decide what your product does in the meantime: what the user sees, whether the account stays open, and when access ends. And rewrite every default email in your own voice.

3. Your real homepage is an empty dashboard

After sign-up, the first thing a new user sees is usually a screen with nothing in it.

Why it matters. Dashboards tend to be designed with perfect demo data: full charts, busy tables. A new account has none of that. An empty chart and a table that says “No data” give a new user nothing to do, in the one session where they’re deciding whether to come back.

What to do instead. Design the empty state first. Each empty area should say what will appear there and offer the single action that fills it. Cut every onboarding question you won’t use straight away, and get people to their first useful result in as few steps as you can. Sample data can help if it’s clearly labeled and easy to clear. These quiet states are a large part of what good UX actually is.

4. Instrument before you guess

Decide what you’ll measure before launch, not after something goes wrong.

Why it matters. Without data, every product discussion is opinion against opinion, and the loudest one wins. It’s easy to misjudge where people drop off, and to build for the most vocal user instead of the typical one.

What to do instead. Track a handful of events that describe the path: signed up, finished the first key action, came back, invited someone, paid, canceled. Log errors with enough context to reproduce them. Ask people who cancel one short question, and read every answer. Collect only what you need and say so plainly; analytics is a trust decision too.

5. Launch is where the maintenance bill starts

Version one isn’t the finish line. It’s the start of a long tail.

Why it matters. A SaaS product is a promise that it will keep working. Dependencies ship security fixes, language versions reach end of life, APIs you rely on change, emails drift into spam folders, and support questions arrive at inconvenient hours. Code ages even when nobody touches it.

My own blog shows a small version of this. During the 2026 site rebuild, AI writing agents rewrote the text around 180 of my old snippet posts, under a brief that told them to flag problems in the code rather than silently fix them. They flagged 136 posts: deprecated functions, missing escaping, a few snippets that wouldn’t run on PHP 8. That’s tutorial code. A product that people pay for has far more ways to age.

What to do instead. Choose a boring stack you can maintain on a bad week. Automate backups, updates and uptime checks. Build small admin tools early: find an account, resend an email, see what a user sees. Treat support as research, because every question points to a bug, a UX problem or a gap in the documentation. And put maintenance time in the calendar every week as a fixed cost.

6. AI speeds up building a SaaS product, not validating it

AI coding tools make the build faster. They can’t tell you whether anyone wants the thing.

Why it matters. Claude Code is an AI coding agent that works on your codebase: it reads files, edits them and runs commands. With a tool like that, auth screens and CRUD dashboards can come together quickly. That makes the most expensive mistake a product can make, building something nobody needs, cheaper to make and easier to repeat. When I rebuilt my own site, Claude Code built the theme; the decisions that mattered, like which plugins to switch off, how images should load and what to remove, were still mine. Validation is that kind of decision, with more at stake.

What to do instead. Validate before you build the real thing. Talk to people who have the problem, find out what they use today, and ask for a commitment: a pre-order, a paid pilot, even an hour of their time. Use AI to build the prototype you show in those conversations, not the product you launch into silence. Judgment, not typing speed, is what keeps developers relevant in the AI era.

Building a SaaS product: the short version

• Scope to one user and one job.
• Design sign-up, billing and email like core screens.
• Build the empty state before the full one.
• Measure the path before you argue about it.
• Budget for maintenance from the first day.
• Let AI speed up the build; let people validate the idea.

The feature gets people through the door. The boring parts decide whether anyone stays, and they’re the parts worth planning first on any web app or dashboard.