How to Build a SaaS: The Complete Guide from Idea to Paying Customers

Learning how to build a SaaS is mostly learning the right order: validate the problem with real buyers, scope a small first version, pick a widely used stack, get accounts, permissions and billing right from day one, and launch to a handful of paying customers before you build anything else. The expensive mistakes usually come from doing those steps out of order, such as building before validating or leaving billing and permissions for "later".

I am a freelance developer based in Denmark. This guide covers the work a SaaS product needs: development, billing, user experience and operations. Each step links to a more detailed post if you want to go further.

The short answer: eight steps in four phases

Building a SaaS breaks down into eight steps, grouped into four phases. The table shows what each step should give you and where founders most often go wrong.

Steps 1-3 keep you from building the wrong thing. Steps 4-6 make sure what you build holds up. Steps 7-8 are about winning customers and keeping them. If the terminology is new to you, start with what SaaS is, explained for non-technical founders.

Phase 1: before you write any code

The first three steps cost almost nothing in development time, yet they decide whether the rest of your budget is well spent. This is also where I most often advise founders to slow down.

Step 1: Pin down the business model

SaaS (software as a service) is software your customers pay for on an ongoing basis, usually through a monthly or annual subscription, while you handle hosting, updates and security. That model has a consequence many founders only feel after launch: revenue comes in over months and years, not at the first sale. A customer who cancels after two months may not even have covered what it cost to acquire them.

So answer three questions before anything else:

• Who pays? A company, a team or an individual. Business customers often pay more and stay longer, but the sales cycle is usually slower.
• What do they pay for? Per seat, per location, by usage or for a fixed plan.
• Why do they stay? What does the customer get from renewing month after month?

There are more ways to make money from software than a flat monthly fee, and I've mapped them out in SaaS business models and how each one makes money. If you already run a service business, turning it into software is often the shortest route, because you know the customers and the problem from the inside. I cover that in my guide to productizing a service into a SaaS. Thinking about a narrow product for one industry? Here's why vertical SaaS tends to do well in smaller markets like the Nordics. And if you want something small and profitable that you can run alone, the playbook for micro-SaaS is different again.

Step 2: Validate that someone will pay

Validation means collecting evidence that the problem hurts enough for someone to pay to make it go away. "Sounds clever" isn't evidence. It's politeness.

Stronger signals look like this:

• Prospects describe the problem before you mention it, and they already spend time or money on a poor workaround, such as spreadsheets, manual processes or an expensive tool they dislike.
• They'll give you an hour to click through a prototype and tell you what's missing.
• They'll prepay, sign a letter of intent or join as a pilot customer at a real price.

The last one is the strongest signal by far. Money or a signature beats ten enthusiastic calls. You can validate with interviews, a landing page, a Figma prototype or a concierge version where you do by hand what the software will later automate.

My step-by-step process is in the guide to validating a SaaS idea before you write any code. Still looking for the idea itself? I've collected SaaS ideas and how to test them cheaply.

Step 3: Scope an MVP that can take money

An MVP (minimum viable product) is the smallest version of your product that solves the core problem well enough for someone to pay for it. It isn't a half-finished version of the final product, and it isn't a throwaway prototype either. If the distinction is fuzzy, I've written about what an MVP is and what it isn't.

My rule of thumb: a SaaS MVP needs to do four things. A customer can sign up, use the one feature that solves their problem, pay, and get help when something breaks. Everything else has to earn its place. That includes things that feel mandatory, like advanced reporting, integrations with five other tools, dark mode and a mobile app.

A practical way to scope is to write down the customer's path from first visit to first invoice, then cross out every step that isn't needed for your first customer to get their problem solved and pay. The rest goes on a "later" list. The detailed method is in my guide on how to scope an MVP, and if you find it hard to say no, use my list of features your SaaS doesn't need at launch.

Who should build your SaaS?

Once your MVP is scoped, the next question is who builds it. There are four realistic routes, and none of them is right for everyone.

AI tools like Lovable, Bolt and Cursor have become good at producing something that looks finished, and for validation they can be a sensible choice. But a SaaS with real customers also needs proper access control, tenant isolation, billing, backups and security updates. Those are exactly the parts you can't see on the surface, and they're where mistakes get expensive.

A freelance developer like me fits best when you have a scoped first version, want to talk directly to the person building it, and need to scale the effort up or down. Don't hire a freelancer if you need branding, user research, marketing and development all at the same time. An agency is a better fit for that. And if software is your entire business and you know it needs full-time development for years, a technical co-founder or an in-house developer is the right long-term answer. A freelancer can still build version one and hand it over properly.

Location matters less than working-hour overlap. A developer on Central European Time overlaps almost completely with UK and EU working hours and still shares a few hours a day with the US East Coast (their morning, your afternoon). Whoever you pick, insist that the code lives in your own repository from day one and that the contract assigns the rights to you. Cost depends mostly on scope, and I've broken down what SaaS development costs in Europe so you can set a realistic budget.

Phase 2: the technical decisions that are expensive to undo

Most choices in a SaaS can be changed later. A few can't, or only with a major rebuild. Make those deliberately at the start, even if you're not the one writing the code.

Step 4: Choose a boring tech stack

Your tech stack is the set of languages, frameworks and services the product is built on. My advice is to choose boring: a mainstream stack with good documentation, a large ecosystem and plenty of developers who could take over if your first one leaves. This isn't the place to be inventive. Save that for the product.

I work mainly with Laravel (PHP) on the backend and React or Next.js on the frontend, so weigh my view with that in mind. Laravel covers a lot of what a SaaS needs, either built in or through official packages, including authentication, queues for background jobs and Laravel Cashier for Stripe subscription billing. Ruby on Rails, Django or Next.js with a hosted database are all reasonable alternatives. What matters most is that the stack is widely used and that your developer knows it well. I go deeper in my recommended SaaS tech stack.

Hosting belongs to the same decision. A new SaaS rarely needs a complex setup on one of the big cloud providers. A managed platform that handles deployments, SSL certificates and backups for you is usually enough for a long time. If your customers are European businesses, pick a provider and region that keep data in the EU, since many buyers will ask about it during procurement. I compare the options in my overview of SaaS hosting options.

Step 5: Get tenants, roles and data right from the start

Almost every B2B product has many customers in one system, and each customer has several users. That's called multi-tenancy, and it raises three questions that are far cheaper to answer before the first line of code than after your first hundred customers:

1. How is each customer's data kept separate? One shared database with a tenant ID on every row, one database per customer, or something in between. A shared database is the most common and cheapest to run, but it takes discipline so that one customer can never see another's data. The trade-offs are in my explainer on multi-tenant SaaS architecture.
2. Who can do what? Owner, admin, regular user, maybe a guest or an external accountant. Even if version one only has two roles, the code should be built so more can be added. Here's how to design roles and permissions from the start.
3. How do you handle GDPR? If you offer your product to people in the EU, the GDPR can apply even when your company is based outside the EU. When your customers store personal data about their staff or clients in your system, you're typically their data processor, which means they'll expect a data processing agreement (DPA) from you. You also need to be able to export and delete data and know where your subprocessors store it. I've listed the technical requirements in my GDPR checklist for SaaS.

This isn't legal advice, so talk to a lawyer if you're unsure about your role. And if other companies should be able to resell your product under their own brand, that affects the architecture from day one too. I cover it in my post on white-label SaaS.

Phase 3: billing, pricing and EU VAT

Step 6: Set up billing and pricing

Never build billing from scratch. Use a provider that handles cards, subscriptions, renewals, failed payments and invoices. Two of the most common choices are Stripe, where you're normally the seller and responsible for tax, and Paddle, a merchant of record that formally sells to your customers and handles sales tax and VAT for you, in exchange for a higher fee. I compare them in my guide to SaaS subscription billing.

Tax is easy to overlook. If you're an EU business selling to businesses in other EU countries, you usually don't charge VAT, because the customer accounts for it under the reverse-charge procedure. Selling to consumers is different: once your cross-border sales to consumers in other EU countries pass €10,000 a year, digital services are taxed at the customer's local rate. The One-Stop-Shop scheme lets you report all of it in one country. The rules are summarized on the EU's Your Europe portal. Selling to US customers can trigger state sales tax as well, which is one reason founders outside the US often pick a merchant of record. Check your situation with an accountant.

Pricing is a product decision, not just a number. Do customers pay per seat, by usage or for a fixed plan? Do you offer freemium, a free trial or paid plans from day one? For a new B2B SaaS, my advice is to charge early, even if the price is low. One paying customer gives you better feedback than a hundred free users. Build billing so you can change plans and prices without rewriting code, because your first price is almost never your final one.

I've written separately about SaaS pricing models and how to choose one and about freemium vs a free trial vs paying from day one.

Phase 4: launch and what comes after

Step 7: Launch to a few customers, then fix onboarding

Don't wait for the product to feel finished. It never will. Launch when the MVP solves the core problem, billing works, and you can help customers when something goes wrong. Start with the pilot customers you found during validation, then open up gradually.

Before you open the doors, get the basics in place: backups you've actually restored, error and uptime monitoring, terms and a privacy policy, a way for customers to reach you, and a billing flow you've rehearsed. My SaaS launch checklist has 30 items worth going through the week before.

The first sessions after signup decide whether a customer stays. Track how many new users reach the moment where the product solves their problem for the first time, and remove whatever gets in the way: an empty dashboard, a long setup or an import that fails. These SaaS onboarding best practices cover 11 ways to get more users to that point.

Step 8: Measure, learn, then scale

Once customers are paying, the work changes. Now it's about understanding what's happening and prioritizing based on it. The key numbers are MRR (monthly recurring revenue), churn (the share of customers or revenue you lose each month) and the ratio between what it costs to win a customer and what that customer is worth over time. I explain them in plain terms in SaaS metrics explained: MRR, churn, LTV and CAC.

Churn often has technical causes that are easy to miss: slow pages, billing bugs that get cards declined, no way to export data, or emails landing in spam. I've collected the technical causes of SaaS churn I'd check first.

Scaling is rarely the first problem. A well-built SaaS on a mainstream stack can usually handle far more customers than most products have in their first year, and when bottlenecks show up, they tend to be in the database or background jobs, not in the choice of framework. Build for the customers you have and watch the numbers. When the time comes, my guide to scaling a SaaS application walks through what to do in which order.

Next steps: what to have ready before you talk to a developer

The hard part of building a SaaS is rarely the code. It's building the right thing, in the right order, and keeping version one small enough to ship. Go through this list before you contact a developer. The more you can tick off, the more accurate the quote you get back.

If some answers are missing, that's normal. Before larger builds, I run a paid, fixed-price discovery phase where you and I scope the MVP together, make the technical decisions and produce an estimate for the rest. You can see how I approach SaaS development, from discovery through launch and ongoing work.

Frequently asked questions

How long does it take to build a SaaS?+

It depends mostly on how tightly the MVP is scoped. A first version with one core feature, a couple of roles and standard billing is typically a matter of months, while many integrations, complex business rules and several user types stretch the timeline quickly. The most effective way to ship sooner is to cut scope, not to push the developer harder. A discovery phase gives you an estimate for your specific project.

Can I build a SaaS without knowing how to code?+

Yes. Plenty of SaaS products are started by people who know the industry and the problem rather than the code. You can validate with no-code and AI tools, then bring in a developer or a technical co-founder to build the version real customers pay for. Your most important job is owning the product decisions: who the customer is, what ships first and what waits.

What does it cost to run a SaaS after launch?+

Running costs typically cover hosting, billing provider fees, transactional email, error monitoring, any licenses, and time for maintenance and security updates. Hosting is often a small line item early on. The biggest cost is usually development time for fixes and new features, so set aside a monthly budget for it from the start instead of handling it as things come up.

Does my SaaS have to be hosted in the EU?+

Not strictly. The GDPR doesn't require EU hosting, but transferring personal data outside the EU needs a valid transfer mechanism, such as an adequacy decision or standard contractual clauses. In practice, many European business customers prefer or require EU hosting, and it makes security questionnaires easier to answer. If you sell mainly to European companies, EU hosting is usually the simplest choice. Check the details with a privacy lawyer.