Website, web app or SaaS? The architecture questions we ask before writing a line of code

By the Brightcode team, a small web agency in Delhi NCR. Reviewed by Gaurav Khokkar, Founder.

A lot of project briefs we get start with "we need an app". Sometimes that's true. Often what the person needs is a fast website with a good form, plus one paid tool they haven't heard of yet. And now and then a "simple website" turns out to be a multi-tenant product with billing.

Calling it wrong is expensive in both directions. Build a SaaS when the client needed a brochure site and you've burned months. Build a brochure site when they needed a portal and you'll rebuild it within a year.

So before we pick a stack or write an estimate, we sort the project into one of three buckets. Here's how, and what changes in the architecture once we know.

The one-line test

Ask: will people come here to read, or to do work?

• Mostly reading (services, products, contact details, then call, WhatsApp or buy) → website
• Logging in to get something done (book, order, approve, check a report) → web app
• The same web app, sold to many customers who each get their own walled-off space → SaaS

A store sits in between. It's a website with an app-like checkout. A service site with a client login area is a website with a small web app attached. That's fine. Name the parts separately and scope them separately.

Question 1: Does anyone need to log in?

This is the biggest fork. The moment there's a login, you're on the hook for:

• Auth (sessions or tokens, password reset, maybe OTP or Google sign-in)
• Roles and permissions, even if it's only "admin" and "user" on day one
• Data that differs per person, which changes how you cache everything
• Security reviews you didn't need for a marketing site

If nobody logs in, keep it a website. Static or mostly static pages, a CMS for the people who edit content, aggressive caching at the CDN. If only the client's team logs in to edit content, that's a CMS, not a web app. Don't build custom auth for it.

Question 2: Is the content the same for everyone?

Websites serve the same page to every visitor. That's what makes them cheap to host and fast to load. You can pre-render, cache at the edge for minutes or hours, and serve most traffic without touching your server.

Web apps serve different data to each user, so pages are rendered per request or built on the client from an API. Caching moves down to the data layer. This is why "can we just add a dashboard to the website?" is rarely a small change. It brings a second rendering model into the same codebase.

A pattern that works well for us: keep the marketing site and the app as two deployables. example.com is the website, built for SEO and speed. app.example.com is the web app, built for logged-in users. They share a design system, not a runtime.

Question 3: Is there more than one customer organisation?

This is the question that separates a web app from SaaS. A portal for one distributor and its dealers is a web app, even if hundreds of dealers log in. A tool you sell to fifty distributors, each with their own dealers, is SaaS.

SaaS adds a few things you can't bolt on cheaply later:

• Tenancy. Usually a tenant_id on every row with strict scoping in queries (or row-level security in Postgres). Separate schemas or databases per tenant are possible, but they make migrations and reporting harder.
• Billing. Plans, trials, upgrades, failed payments, invoices with GST if you sell in India. Subscription billing through a gateway like Razorpay or Stripe is a project in its own right.
• Onboarding and admin. Sign-up, inviting teammates, a super-admin view for your own support team.

If the client isn't planning to sell the software to other companies, don't build tenancy "just in case". It's the most common over-engineering we see in early briefs.

Question 4: Does a ready-made tool already do 80% of it?

Before custom anything, we check whether existing SaaS covers the job. CRMs, booking tools, invoicing, helpdesks. If it does, the right build is usually a good website in front of the tool, plus a thin integration layer: the website form posts to the CRM's API, a webhook sends a WhatsApp alert, a small script updates a sheet.

Custom earns its place when:

• The team spends hours a day copying data between tools
• A missing feature in the current tool causes real mistakes
• Per-seat pricing keeps climbing as the team grows
• The process itself is the business's edge (a particular quoting or dealer pricing system, say)
• The software is the product

Most of our software and API work lives in that thin layer, not in replacing tools that already work.

Question 5: Who looks after it in year two?

This one decides more than the stack.

A website mostly needs content edits, dependency or plugin updates and someone watching uptime. A web app needs all that plus bug fixes, database care, auth patches and small feature requests that never stop. A SaaS adds on-call for paying customers.

So we ask who will own it after launch, and scope that up front. If the honest answer is "nobody technical", that pushes us towards simpler choices: a hosted CMS, fewer custom parts, managed infrastructure. If you're weighing a headless setup for a content-heavy site, we wrote up when a headless CMS makes sense and when it's overkill.

What changes in the estimate

Once the bucket is clear, the estimate changes shape:

	Website	Web app	SaaS
Main unit we price	Unique templates and content	Screens, roles and workflows	Everything in web app, plus tenancy, billing and onboarding
Rendering	Pre-rendered or cached	Per request or client-side	Per request or client-side
Auth	None (CMS login only)	Yes, with roles	Yes, with roles per tenant
Testing focus	Layout, speed, forms, SEO	Permissions, edge cases, data	All of that, plus tenant isolation
Year-two work	Updates, edits, uptime	Fixes, features, data care	Same, plus support and billing issues

We also split mixed briefs into two lines: "marketing website" and "client portal", each with its own estimate. Clients can see where the money goes, and they can launch the website first while the app is still being built.

The short version

1. Read or do? That's website vs web app.
2. One customer organisation or many? That's web app vs SaaS.
3. Can a ready-made tool do most of it? Then build the website and the glue, not the tool.
4. Who maintains it? Let that answer simplify your choices.

We wrote a longer, non-technical version of this for business owners: website vs web app vs SaaS: what does your business actually need?. It's handy to send to a client before the first call.

How do you sort briefs like this? Do you split the marketing site and the app from day one, or keep them in one codebase? Tell us in the comments.

Written by the team at Brightcode, a Delhi NCR agency that builds websites, e-commerce stores and custom web apps.