How to build a SaaS product: from idea to first paying customer

Building a SaaS product that reaches a paying customer takes eight steps: pick a problem someone already pays to solve, confirm that with real conversations, cut the first version down to one job done well, choose a stack you can hire for, build with accounts and billing from the start, launch to a small group, charge from the first usable version, and then watch two numbers, the cost to acquire a customer and what that customer is worth, to decide whether to keep going.

Most SaaS projects that fail do so at step one or step three: the problem was not painful enough to pay for, or the first version tried to be the finished product. The steps below are the ones we use when a founder brings us an idea as part of our web app and SaaS development work.

Is the idea worth building?

Step 1: is the problem worth paying to solve?

A SaaS product sells a recurring solution to a recurring problem. The test is not whether people like the idea; it is whether they already spend money or hours on the problem today. A spreadsheet maintained every Monday, a freelancer paid to do it by hand, a tool they grumble about but renew: all signs of a budget that exists. A problem nobody has tried to solve usually means nobody minds it enough.

Write the problem in one sentence that names the person and the pain: "operations managers at small logistics firms spend four hours a week reconciling driver timesheets by hand". If you cannot write that sentence, you are not ready to build.

Step 2: talk to fifteen people before writing code

Find fifteen people who match the sentence and ask about the problem, not the product. How do they handle it now, what does it cost them, what have they tried, what would make them switch. Do not describe your solution until the end, and do not count polite interest as a signal. The signal is someone asking when they can have it, or offering to pay for early access.

Three to five people out of fifteen willing to pre-pay or sign a letter of intent is enough to proceed. Fewer than that and the problem is probably real but not urgent, which is the hardest kind of product to sell.

Step 3: cut the first version to one job

The first version, the MVP, exists to find out whether people pay, not to be complete. What is an MVP explains the idea; how to scope an MVP in one week is the exercise. The short version: list every feature, mark the one thing the customer must be able to do to get value, and keep only what that one thing needs.

Things that can wait: team invitations, multiple roles, a mobile app, integrations beyond the one that matters, analytics dashboards, white-labelling, an API. Things that cannot: sign-up and login, the core workflow, billing, and a way to contact you.

A first version we would consider well scoped has five to twelve screens, one user role, one integration at most and a single plan. It can be built in ten to sixteen weeks.

How should you build it?

Step 4: no-code, custom code or a hybrid?

No-code vs custom development and Bubble vs custom code cover the decision and the point at which teams switch. Our rule: if the product's value is in the workflow and the data is simple, start with no-code and plan to rebuild if it works. If the value is in logic, speed or integrations, build it properly once.

Step 5: choose a stack you can hire for

The stack matters less than founders think and more than they would like. Pick for three things: can you hire for it, does it have mature libraries for auth, billing and email, and will it still be maintained in five years.

For most products we build, that is Next.js and TypeScript, PostgreSQL, hosted on Vercel or a cloud provider, with managed services for the parts not worth building: authentication (Clerk, Auth.js or Supabase Auth; compared in authentication options for web apps), billing (Stripe), email (Resend or Postmark), and error tracking. Choosing a tech stack for a SaaS sets out the alternatives, and Supabase vs Firebase and PostgreSQL vs MongoDB cover the two decisions founders ask about most.

Two architectural decisions are hard to change later, so make them deliberately. One is how customers' data is separated: by rows in shared tables, by schema, or by database. Multi-tenant SaaS architecture explained covers the trade-offs; row-level separation is right for nearly every early product. The other is what to log from day one, so that when something breaks for a paying customer you can see what happened. What to log and monitor from day one is the minimum.

Step 6: build billing in, not on

Subscriptions touch sign-up, access control, invoicing, failed payments, upgrades, cancellations and tax. Products that add billing at the end spend weeks reworking the data model. Build it in from the first week, even if the first customers are on a free trial.

Stripe is the default for most markets (in India, new Stripe accounts have been invite-only since 2024, so Razorpay is the usual choice there), and its subscriptions documentation covers trials, proration and dunning in detail. How to add subscriptions with Stripe is our walkthrough. For Indian customers paying in rupees, Razorpay subscriptions are the common alternative. In both cases, the webhook that tells your app a payment succeeded or failed is the part that must be tested, because it is the one that quietly breaks.

Decide the pricing model early: per seat, per usage, or flat tiers. It shapes the data model. SaaS pricing page design covers how to present it; the model itself should match how the customer thinks about value.

Step 7: launch small and charge from the start

Launch to the fifteen people from step two, then to a waiting list, then publicly. A private launch finds the bugs that matter with people who have agreed to be patient. Onboarding flows that reduce churn covers the first ten minutes of a new account, which decide whether it ever becomes a paying one.

Charge from the first usable version. Offer a trial if you must, but with a card or an end date. Free users produce feedback about features; paying users produce feedback about value, which is the kind that shapes a business. A price can start low and rise. Six months of free usage cannot be turned into revenue later.

Step 8: the two numbers that decide what happens next

Once customers are paying, two numbers tell you whether the product is a business.

Customer acquisition cost (CAC): everything you spend on sales and marketing in a period, divided by the customers won in it. Our CAC calculator works it out per channel, which matters because one channel is usually carrying the rest.

Customer lifetime value (LTV): the average monthly revenue per customer, times gross margin, divided by monthly churn. Our LTV calculator does the arithmetic and shows the LTV to CAC ratio.

The common rule of thumb is that LTV should be at least three times CAC and that CAC should be recovered within twelve months. Early numbers are noisy; with twenty customers a single cancellation moves churn by five percentage points. Treat them as direction, not verdict, until you have a hundred or so. What they tell you early is whether to spend the next quarter on acquisition (ratio healthy, churn low), on retention (churn high), or on pricing (ratio poor despite low churn).

What goes wrong after the first customers?

The code written fast in step five starts to slow the team down. That is normal, and it has a name and a method: technical debt explains how to pay it down without stopping to rewrite. If the first version was built by a freelancer or a founder who has moved on, how to take over an existing codebase describes the audit that comes first.

The other common failure is building for the loudest customer. Three customers asking for a feature is a pattern; one customer asking for it loudly is a custom project. Keep a list, count requests, and build what the count says. The admin side, where you manage customers and see what they are doing, deserves more care than founders give it; how to build an admin dashboard staff actually use covers it.

The product that reaches a paying customer is rarely the one in the pitch deck. It is the one that did one job well enough that somebody paid for it, and then listened.