Website or Web App? The Signs You've Outgrown a Marketing Site

There is a conversation I keep having with business owners who think they have a website problem. The site is “slow,” or “messy,” or “needs a rebuild.” Then we walk through what is actually bolted to it: a customer portal plugin, three shared spreadsheets, a form tool, a scheduling tool, a Zapier account holding it all together, and one employee who spends Friday afternoons moving data between them by hand.

That is not a website problem. That business needs an application, and nobody has said it out loud yet.

The line is invisible until you cross it

A website and a web application look identical from the outside: both live in a browser. The difference is one question: does the page do the same thing for everyone?

A marketing site answers yes. Every visitor sees the same pages, and the site’s whole job is to load instantly for a stranger and turn them into a lead. That job rewards static-first architecture, which is why every marketing site I build runs on Astro.

An application answers no. What appears on screen depends on who is logged in. That single difference drags in authentication, a database, permissions, and state, and none of those belong on a marketing site.

The line is invisible because businesses cross it gradually. Nobody wakes up and says “we need an application.” They say “can the site remember which customer this is?” and “can we let clients check their project status?” Each request sounds like a small website feature. Together, they are an application wearing a website costume.

The symptoms you’ve already crossed it

If two or more of these describe you, the line is behind you:

People need to log in. Customers, staff, or partners each need an account to see their own view of things.
“Show this client their invoices” is a database query with permissions, not a web page.
Work moves through stages that hold state: intake, approval, fulfillment, follow-up. A form submission is a snapshot; a workflow is a machine.
The real business logic lives in spreadsheets that a person reconciles by hand against what the website collects.
You rent several tools that each do 70% of the job, and the missing 30% is bridged by a human. You are paying subscription prices for the privilege of doing integration work by hand.
Feature requests start with “can the site remember…” Memory is state, and state is an application.

What happens if you build it with website tools

The tempting path is to stay in website-land and bolt the features on: a membership plugin here, a portal plugin there, an automation plugin to tie it together. I have written about what that plugin economy does to a WordPress site, and the app version of the story is worse, because the stakes are higher.

A slow marketing page loses a lead. A duct-taped portal loses a customer’s data, or shows it to the wrong customer. Plugins from different vendors were never designed as one system: each has its own update cycle, its own security surface, and its own idea of where data lives. The assembly works in the demo and degrades under real users, and because no one owns the whole workflow, every failure is somebody else’s plugin.

The other failure mode is quieter: the marketing site gets heavier and slower with every bolted-on feature, so you end up with a bad app and a bad website in the same codebase.

The right-sized stack

When the answer is an application, it does not need to be an enterprise project. The stack I build on is deliberately boring:

Next.js runs the application itself: the logged-in interface, the dashboards, the workflows. It is a mature framework built for exactly this kind of interactive, user-specific rendering.
Supabase is the foundation: authentication, a real Postgres database, and row-level security so each user can only ever see their own rows, enforced at the database, not by hoping the interface behaves.
AstroAstroAstro is a modern web framework for building fast, content-driven websites that ship zero JavaScript by default. still runs the marketing site. The public site does not join the app. It stays static-first and instant, and the two link to each other.

The point of this stack is proportion. It is powerful enough that you will not outgrow it next year, standard enough that any competent developer can pick it up, and your data sits in ordinary Postgres you own, not inside a SaaS tool’s export button.

The honest cost conversation

An application costs more than a website, and it should. You are not buying pages; you are buying a system that runs part of your operation. Weigh the app against what you are already paying now, not against a hypothetical website: the stack of subscriptions that almost fit, plus the hours of manual reconciliation, plus the errors, multiplied by every month you keep renting the workaround. For plenty of businesses the workaround genuinely wins for another year or two, and when that is true, the right advice is to wait. What is not fine is paying app money in subscriptions and labor while telling yourself you just have a website that needs a plugin.

A worked example, at its real size

I will use my own build as the example, framed at its actual maturity. My clients used to get reporting the way most agency clients do: a monthly summary. I am replacing that with a reporting dashboard on exactly this stack, Next.js in front, Supabase underneath, where a client logs in and sees their own leads, sources, and spend.

It is in pilot with active clients right now. It is not a polished product, and I am not dressing it up as one. But it is a live demonstration of the whole argument: the marketing site you are reading stayed a fast Astro build, the application went on application architecture, and one partner is accountable for both sides of the line.

If your website has been quietly accumulating an application inside it, this is exactly the work I do on Next.js and Supabase.

Frequently Asked Questions

Three symptoms are nearly definitive: people need to log in, people need to see data that is specific to them, and work needs to move through steps with state that a form submission cannot hold. If you are paying for several SaaS tools that each almost do the job, and a person glues them together manually, you have probably crossed the line already.

Because a membership plugin, a forms plugin, a table plugin, and an automation plugin were never designed as one system. Each one adds weight, an update cycle, and a security surface, and none of them owns the whole workflow. That approach works right up until real users depend on it, which is the worst possible time to find its limits.

Next.js is a mature framework for genuinely interactive interfaces, and Supabase provides authentication, a real Postgres database, and row-level security without inventing a backend from scratch. Together they are a right-sized stack for portals, dashboards, and internal tools: powerful enough to grow, boring enough to maintain, and your data stays in a standard database you own.

Usually, yes, and they should be different builds. The marketing site's job is to load instantly for strangers and convert them; the application's job is to serve logged-in users. Forcing one codebase to do both jobs makes it mediocre at each. The site stays a fast static-first build, the app gets real application architecture, and they link to each other.