The Common Confusion
When someone says they are building a "SaaS product," they often mean they are building something on the web that businesses will pay a monthly fee to use. But "SaaS" is not just a pricing model — it is an architectural and operational pattern that has specific technical requirements. A web app is the broader category. SaaS is a specific type of web app, and it comes with engineering decisions that need to be made from the very beginning.
Getting this wrong looks like this: you build a web application, launch it, acquire a dozen paying customers, and then someone asks you "can we have our own subdomain and keep our users' data separate from everyone else's?" And you discover that your architecture doesn't support it — because you built a web app, not a SaaS product. That retrofit is painful, expensive, and sometimes impossible without a full rebuild.
What Makes Something a Web App
A web application is any software application that runs in a web browser and does something interactive that static HTML cannot do. Gmail is a web app. Google Docs is a web app. Your company's internal project tracker is a web app. So is a bespoke client portal that a consultancy builds for a single enterprise customer.
A web app has no specific requirements around how many customers it serves, how they are billed, how their data is stored, or how they access the system. It is defined by its delivery mechanism — the web browser — not by its business model or architecture. You can build a web app for one customer or one million. The term itself does not constrain you.
This is important because "web app" is not a lesser thing than "SaaS." In many cases, a custom-built web application for a single enterprise client is a more complex and more valuable piece of software than a simple SaaS product. The distinction is about purpose and architecture, not quality.
What Makes Something SaaS
Software as a Service has three defining characteristics that separate it from a generic web application:
1. Multi-tenancy
A SaaS product serves multiple customers (tenants) from the same deployed instance of the software. Each customer gets their own isolated experience — their own users, their own data, their own settings — but underneath, they are all running on the same infrastructure and the same codebase. This is the core architectural requirement that distinguishes SaaS from a custom web app. Multi-tenancy is what gives SaaS its economics: you build and maintain one system, and you amortize that cost across every customer who pays for it.
2. Subscription billing
SaaS products are sold on a recurring basis — monthly or annual subscriptions, typically with tiered pricing based on usage, users, or features. This is not just a payment preference; it shapes how the product is built. You need billing infrastructure, metered usage tracking, subscription lifecycle management (trials, upgrades, downgrades, cancellations, dunning), and integration with a payment processor like Stripe that is aware of recurring charges rather than one-off payments.
3. Self-serve onboarding
True SaaS products allow customers to sign up, activate, and begin using the product without requiring human intervention. The onboarding flow, the email sequences, the in-app guidance — all of it is automated. This is what enables the economics of SaaS at scale: if onboarding requires a sales call or a manual setup process for every new customer, your cost to acquire and serve customers limits how far you can grow.
Why the Distinction Shapes Your Architecture From Day One
Authentication and user management
In a custom web app built for one organization, authentication is relatively straightforward — you have users, they log in, they see data. In a SaaS product, you have organizations (tenants), each with their own users, their own roles, and their own permissions. A user at Company A must never see Company B's data, even if they share the same database. Building this isolation correctly from the start requires careful database schema design, row-level security policies, and authentication middleware that is aware of which tenant a given request belongs to.
Data isolation
There are three common patterns for handling tenant data isolation: shared database with shared schema (all tenants share tables, data is separated by a tenant ID column), shared database with separate schemas (each tenant gets their own schema in the same database), and separate databases per tenant (complete isolation at the database level). Each has different cost, complexity, and compliance implications. The choice you make at the start shapes every data access pattern in your application. Changing this later is one of the most expensive refactors a SaaS company can face.
Billing infrastructure
Billing in a SaaS product is not a feature you add later. It is a foundational piece of infrastructure that touches the entire application. Which plan is the user on? What features are they allowed to access? Have they exceeded their usage limits? Is their payment current? Is their trial about to expire? These questions need answers at every layer of the application — the API, the frontend, the background jobs, the email system. Building a SaaS product and leaving billing for later means rebuilding large portions of your application when you try to add it.
The Business Model Implications
The architectural differences between a web app and a SaaS product are mirrored by equally significant business model differences.
A SaaS product generates recurring revenue. The unit economics center on metrics like Monthly Recurring Revenue (MRR), Customer Acquisition Cost (CAC), Lifetime Value (LTV), churn rate, and net revenue retention. Getting these numbers right is fundamental to understanding whether the business is healthy and scalable.
A custom web app is typically priced as a one-off project — a fixed price for a defined scope of work, potentially with a maintenance retainer. The revenue is not recurring in the same way, and the customer relationship is fundamentally different.
Distribution also works differently. SaaS products are designed to be discovered, evaluated, and purchased without human sales involvement at the lower tiers — the product itself is the sales channel. Custom web apps are sold through relationships, proposals, and often require significant pre-sales effort. Neither model is better; they serve different markets with different buying behaviors.
Can a Web App Become SaaS? What That Migration Actually Costs
Yes — but it is rarely as simple as people expect. The technical migration from a single-tenant web app to a multi-tenant SaaS product typically involves retrofitting multi-tenancy into an existing database schema (which means touching every table and every query), rebuilding authentication to be tenant-aware, integrating billing infrastructure, building a self-serve signup and onboarding flow, and often re-architecting the permission system from scratch.
Depending on the complexity of the existing application, this can easily represent 40-70% of the effort of building the original product again. For many teams, it is cheaper and faster to do a planned rebuild than to retrofit an existing codebase that was not designed for multi-tenancy.
This is why making this decision early matters so much. If you know you are building a SaaS product, design for multi-tenancy from day one — even if you only have one customer. The upfront cost is modest compared to the retrofit cost later.
Many early-stage products start as single-tenant web apps for their first customer and later need to become SaaS. This is a legitimate path — but it needs to be a deliberate choice with a plan, not something that happens by accident when your third customer asks why their data is mixed with someone else's.
Questions to Figure Out Which One You're Actually Building
Before writing a single line of code, you should be able to answer these questions clearly:
- How many separate organizations or customers will use this system? If the answer is one, you are building a custom web app. If the answer is "many, and they need to be isolated from each other," you are building SaaS.
- Will customers sign up themselves, or will you provision each account manually? Manual provisioning is fine for a custom app. Self-serve signup is a SaaS requirement.
- How are you billing customers? One-off project fee or retainer = custom app economics. Monthly/annual subscriptions with tiered plans = SaaS economics, which require billing infrastructure.
- Do customers need to customize their own configuration, users, and settings independently of each other? If yes, your architecture needs to support tenant-level isolation from the start.
- Is this product intended to grow without proportionally growing your team? If yes, it needs to be designed for self-serve operation — which is a SaaS requirement, not a web app one.
There are no wrong answers here — only honest ones. The goal is to make an informed architectural decision, not to pick the more impressive-sounding label.