How to Build a SaaS

You want to sell software on a subscription. Maybe you have a problem from your own work, maybe a validated idea, maybe a prototype that people keep asking about. Knowing how to build a SaaS is less about the code than founders expect. The software is one part. The rest is accounts, billing, taxes, onboarding, support and a way to reach customers, and those parts decide whether a working product becomes a working business. This guide covers seven stages in the order I would take them.

What you are actually building

A SaaS product is software that customers use over the internet and pay for on a recurring basis. That simple definition hides a stack of obligations. You run the software for them, so uptime and data security are your responsibility. You charge them repeatedly, so billing, failed payments, refunds and tax become ongoing work. You keep them only if they keep getting value, so onboarding and support are part of the product.

It helps to think of a SaaS as five systems: the core application, accounts and permissions, billing, communication (onboarding emails, notifications, support), and visibility (website, documentation, analytics). A first version needs a minimal working version of all five, not a complete version of the first one.

How to build a SaaS in seven stages

Stage 1: Pick a narrow problem people already pay to solve

Recurring revenue needs a recurring problem. Look for tasks people do every week or every month, where the current solution costs them time, money or risk. Existing spending is the strongest signal: if people pay for an awkward tool or a manual service today, there is a budget you can win.

Narrow is better than broad at this stage. “Scheduling for independent tattoo studios” is easier to build, sell and support than “scheduling for small businesses”. Our guide to startup ideas covers how to collect and score problem signals before committing.

Stage 2: Validate with pre-sales or design partners

Before building, find a small group of potential customers who will either pre-pay or commit time as design partners: people who use early versions and tell you what is missing. Payment is the stronger signal. A design partner who will not pay later is a useful adviser, not a customer.

Agree on the problem you are solving for them, the outcome they expect, and a date for the first usable version. Write these down. They become your scope.

Stage 3: Choose a build route you can maintain

There are three routes, and the right one is the one you can keep running for years, not the one that ships fastest.

• A no-code platform suits SaaS products built around records, forms and workflows. Our guide to the no code app builder category covers the types and their exit options.
• An AI app builder can generate a working codebase quickly. You or someone you hire must be able to read and maintain that code.
• A coded build with a web framework, a managed database with built-in authentication, and a hosting platform gives the most control.

Check hosting terms before you take payments. Some free hosting tiers exclude commercial use; Vercel’s Hobby plan, for example, is limited to non-commercial, personal use according to its plan documentation. Moving to a paid tier before launch is cheaper than discovering the restriction later.

Stage 4: Build the core workflow

Build the single workflow that delivers the outcome you agreed with your design partners, end to end, and nothing else. For the tattoo studio example, that might be: a client picks a slot, pays a deposit, and both sides receive a confirmation. Reports, team management and integrations come later.

Track the core action as an event from the first day. You will need it to measure retention, and you cannot recreate history you did not record. For the other tools around the product at this stage, see our stage-by-stage guide to tools for startups.

Stage 5: Add accounts, billing and tax handling

Accounts need sign-up, log-in, password reset and, for business customers, usually the ability to invite teammates with different permissions. Use your platform’s or provider’s authentication rather than building your own. Security mistakes here are expensive and hard to see.

For billing, you choose between a payment processor and a merchant of record. A processor such as Stripe handles card payments and subscriptions, and you remain responsible for collecting and filing sales tax and VAT where required. At the time of writing, its standard fee for domestic cards is 2.9% plus 30 cents per successful transaction (Stripe pricing). A merchant of record such as Paddle becomes the legal seller of your product, handles tax collection and filing, and charges a flat 5% plus 50 cents per checkout transaction.

Decision point: processor or merchant of record

• If you sell mainly in one country and are comfortable handling tax, a processor costs less per sale.
• If you sell to individuals or businesses in many countries from day one, a merchant of record removes most of the tax work.
• If you are unsure, compare the fee difference at your expected monthly revenue against the time and advice you would need to handle tax yourself.

Whichever you choose, set up failed-payment emails and a clear cancellation path. Involuntary churn from expired cards is common in subscription businesses and is mostly preventable.

Stage 6: Onboarding, support and documentation

New users decide quickly whether the product is worth learning. Design the first session so they reach the core outcome as fast as possible: sample data, a short checklist, or a guided first action. Follow up with a few emails tied to what they have or have not done.

Set up a shared support inbox and a short help center that answers the first questions every user asks. Read every support message yourself in the early months. It is the most direct product feedback you will get.

Stage 7: Launch to the people who confirmed the problem

Your first launch audience is the design partners, the pre-sale customers and everyone who joined the waitlist during validation. Then widen to public channels: coverage, listings, communities where your customers already spend time, and search. Our guide on how to launch a product covers the stages and the follow-up work after launch day.

Pricing a SaaS product

Price relative to the value of the outcome, not your costs. If the product saves a studio several hours a week, the price should be a fraction of what those hours are worth to them, not a token amount.

Keep the first pricing simple: one or two plans, monthly and annual billing, and a clear difference between plans tied to how customers grow, such as number of users, locations or volume. You can add complexity once you know how customers use the product. Price changes are much easier to make upward with new customers than with existing ones, so do not start too low.

What this does not fix

Following these stages does not guarantee customers will stay. Retention depends on whether the product keeps delivering value, and that only shows up over months of use. Measure it from the start and expect to change the product more than once.

It also does not solve distribution. A well-built SaaS still needs a repeatable way to reach new customers, and many technically sound products stall because the founders never found one. Finally, it does not remove ongoing operations: a SaaS is a service you run every day, with outages, support and billing issues, not a product you ship once.

Your next action

Write a one-sentence problem statement for a specific customer type, and contact ten people who match it this week to ask how they handle the problem today and what they pay for it.