How to build a SaaS product: From an idea to your first 100 paying customers

01Define what counts as a paying customer

SaaS means software delivered as a service. Customers buy access and expect you to keep the service running. For this plan, count a customer as a separate paying organisation or individual with an active subscription. Ten employees at one company may therefore represent one customer account. Trials, one-off consulting projects and cancelled subscriptions do not count towards the target.

A hundred paying accounts is a useful milestone, but it does not prove that the business is healthy. You also need to know whether customers use the product, what it costs to serve them and why they leave. Ten stable customers for a specialist business product may matter more than a hundred accounts paying a token amount.

Write down the customer, their recurring problem, their current workaround and the person who approves the purchase. A dispatcher at a small maintenance company might schedule visits in a spreadsheet while the owner approves subscriptions. Speak to both. One understands everyday use; the other must justify the budget and the disruption of switching.

02Investigate real work, then offer a paid pilot

Ask about the last specific incident. Who created the job? Where did someone retype information? How was the error found, and what happened next? Ask to see an anonymised version of the process. Asking whether people like your idea often produces polite agreement with little connection to a purchase.

Separate a recurring problem from an occasional inconvenience. Find out why the customer has not already adopted an available product. If an existing service handles the job well, a more attractive interface may not justify switching. A particular integration, difficult implementation or missing industry workflow could provide a stronger reason.

Offer a paid pilot with a defined outcome, scope, price, responsibilities and exit conditions. Explain which steps you will handle manually. Preparing an import yourself is reasonable if you do not present it as finished automation. Payment is stronger evidence than registration, but continued use is what tests whether the value lasts.

For more ways to test demand before development, see our guide to moving from an idea to an MVP.

03Build one complete route to a useful result

An MVP, or minimum viable product, should let customers finish one meaningful job. In our illustrative scheduling product, that might mean creating a job, assigning a technician, confirming the appointment and seeing its completion. Ten unfinished modules do not deliver that outcome. Include a way to correct mistakes, because real customers will not provide perfect inputs.

Divide requirements into those essential for the promised result, those essential for responsible operation and those that can wait. Your operating foundation includes access controls, backups, restoration, error visibility and a named support owner. More technologies do not automatically mean a better product. When planning web application development, include implementation, maintenance and ongoing work in the estimate.

Do not automatically turn every request from an early customer into a shared feature. Record who needs it and how it fits your chosen segment. If every pilot needs a different process and separate application version, you may be validating a bespoke development business. Dedicated infrastructure does not itself rule out SaaS: shared management and operations remain central, as described in the AWS SaaS Lens.

04Keep customer data, billing and access under control

Logging in does not by itself isolate one company's data from another's. AWS explains this distinction. Test whether a user at company A can reach company B's document by changing an address, exporting data or searching. Apply the same checks to background jobs and support access.

Design the subscription lifecycle as well: purchase, renewal, failed payment, plan changes and cancellation. Subscription status does not necessarily prove that every invoice has been paid, as the Stripe documentation explains. Set explicit access and notification rules, including what happens when a payment needs attention.

Payment services notify applications through messages called webhooks. Stripe can deliver them more than once and out of order, and their origin must be verified. See its webhook documentation. Test a repeated event, a delivery failure and subsequent reconciliation. A delayed message should not remove legitimately paid access or grant the same benefit twice.

For a fuller plan covering roles, subscriptions and the first release, read how to plan SaaS development.

05Help early customers reach their first result

Activation means reaching a useful outcome, not simply logging in. For the scheduling example, it could be a real visit assigned and confirmed. Choose an event that reflects the promised value and check whether each new account reaches it. Record the time since registration, the obstacle and the help required.

It is reasonable to onboard early customers personally. Observe their work instead of doing the entire job for them. If they cannot handle the next job without you, improve the product or its guidance. Turn repeated questions into a short walkthrough and unclear fields into clearer forms.

Follow up at the customer's next natural working cycle. Daily logins are a poor measure for a tool needed once a month. Ask what they completed, where they returned to a spreadsheet and whether they will continue on normal terms. Track payment, activation and repeated use separately so that one cannot hide the absence of another.

06After the first ten, look for repeatable sales

Choose one reachable customer segment and one main acquisition route. That might be useful industry content, partner referrals or sales conversations with relevant companies. Match the approach to your price and buying cycle. A low-cost self-service subscription cannot support the same sales effort as a substantial company implementation.

Do not increase advertising spend solely because registrations rise. Find the break in the journey first. Give your digital marketing team a specific audience, a tested message and a relevant next step. Include sales time, content production and partner work when estimating acquisition costs.

07Move towards a hundred with retention and capacity in view

Compare groups of customers by starting month, segment and acquisition source. These groups are called cohorts. Otherwise, new registrations can conceal existing customers leaving. Consider an illustrative month: you start with 70 active paying accounts, acquire 20 and lose 3. You finish with 87, not 90. Net growth determines your progress towards the target.

Measure the effort required to serve customers too. An illustrative 15 minutes of support per account each month becomes 25 hours for 100 accounts, before onboarding, operations or development. This is a planning calculation, not an industry benchmark. Replace the assumption with your own observations and separate typical accounts from unusually demanding ones.

At each review, identify the main constraint: too few suitable prospects, incomplete activation, poor continuation or expensive service. Assign an owner and specify the decision that the next measurement should support. Repeated refusal of a paid pilot, or customers abandoning the core task, is a reason to revisit the problem and segment. More features cannot guarantee demand.

08Frequently asked questions about starting a SaaS

09Prepare a brief for your first paid pilot

Send us your target customer, their current process and the one job your product should solve. Include what you learnt from interviews and your budget constraints. We can review the first version's scope and identify what needs testing before further development.