A test that settles most arguments
If anonymous visitors are the main users, you are in website territory. If signed-in users with different permissions are the main users, you are in application territory. A brochure site with a blog is a website. A client portal, a booking back-office, a dealer dashboard, an internal ops tool — those are applications that happen to use a browser.
Calling an application a “website” to make it sound cheaper is how you get a WordPress build that cannot do roles, audit trails or reporting, and then a second project to replace it.
What changes in the build
| Website | Web application | |
|---|---|---|
| Primary job | Explain, persuade, convert | Let people complete work correctly |
| SEO | Central | Usually irrelevant behind login |
| Performance target | Core Web Vitals, public pages | Snappy UI under real data volumes |
| Typical stack here | Modern site on a CMS or a small custom front | ASP.NET Core, SQL Server, proper auth |
| Failure mode | Nobody finds you | Staff invent a spreadsheet beside it |
Cost follows the job
A marketing site is a web development job. A system people work in is .NET development, and it should be estimated like custom software, not like a five-page brochure. If you need both — a public site and a logged-in product — they can share a brand and still be two builds with two definitions of done.
Examples that settle the briefing
A company site with services, a blog, and a contact form is a website. A WooCommerce or custom store is still mostly a website, with a checkout that must not fail. A client portal where customers upload documents and staff change case status is a web application. The booking back-office your receptionist lives in all day is a web application even if customers book on a pretty page in front of it.
We rebuilt this very site as a custom ASP.NET application because the old WordPress install could not carry the content model and SEO work we needed. That was still a website: public pages, no staff workflow behind the login except admin. The line is the user’s job, not the framework.
What goes wrong when you pick the wrong bucket
Website treated as an app: you pay for roles, audit logs and a database design you do not use, and the pages ship late. App treated as a website: you get a theme, a plugin for “members”, and a support inbox when two staff edit the same record. The second mistake is the expensive one. It usually ends in a rewrite.
How the brief goes wrong
“We need a website” when the receptionist will live in it all day. “We need a web app” when you wanted five service pages and a blog. The first mistake funds a rewrite. The second funds roles and a database you will not use, and the pages ship late. Write who the daily user is. Price from that sentence.
If you need both — a public site that ranks and a portal people work in — they can share a brand, a header, and a design system. They still need two definitions of done, two hosting stories, and often two codebases that talk through an API. That is cheaper than forcing one CMS to be an operations tool.
Hosting and who gets the 2 a.m. call
A marketing site can live on simple hosting with backups and a CDN. An application needs a database you can restore, identity that is not a shared password, and a person who knows how to roll back a release. Calling both “the website” is how the application ends up on cheap shared hosting that cannot take a backup.
We run public content and authenticated software on ASP.NET Core when they belong together; we still estimate them as two jobs. If you are only publishing, that is web development. If staff will use it every day, budget it as an MVP, not as a five-page brochure.
A one-page brief that sorts the quote
Who uses this every day — visitors, staff, or both? Do they sign in? What is the one job that must work on Tuesday? Must Google find the pages? Which other systems must it talk to? That page tells you whether you are buying a site, an application, or two builds that share a brand. Send it to every vendor. The one who replies with a theme and a plugin list for a staff-facing job has told you enough.
This site is the website example: public pages, knowledge, blog, contact — and an admin login that is not the product. A client portal on the same hostname would still be a second definition of done. Mixing them in one estimate is how the blog ships and the portal does not, or the other way around.
SEO, login, and why they fight in one codebase
Public pages want clean URLs, fast first paint, and HTML a crawler can read. Applications want roles, validation, and screens that do not break when last year’s orders load. You can do both in ASP.NET Core — we do — but the caching, the auth, and the definition of “fast” differ. A cache that is perfect for a blog will serve the wrong user’s dashboard if you are careless. A dashboard that is perfect for staff will be a poor landing page if you hang a marketing hero on it.
Decide the primary job of each URL. Marketing URLs are a website problem, including Core Web Vitals. App URLs are a .NET problem, estimated like custom software. Sharing a header is not the same as sharing an estimate.
If you are still arguing in the briefing, use the daily-user test again. Receptionist, warehouse, dealer, customer on a phone — those are application users. A journalist, a buyer comparing three vendors, a person who wants a phone number — those are website users. Both can exist on lavistech.com-shaped sites. They still want two definitions of done. Write both before anyone opens a theme or a solution template.
If the public pages must rank, read Core Web Vitals.
A booking page and a back-office — two jobs
Customers book on a public page. That page is a website: fast, crawlable if you want it found, simple enough to finish on a phone. The receptionist’s all-day screen — change a slot, take a deposit, see who has not paid — is a web application. They can share a brand. They must not share one “website” quote. Price the public page as web development. Price the back-office as an MVP. Mixing them is how the pretty page ships and the desk still runs on a diary. Write both definitions of done on the same brief so nobody “simplifies” them into one number. If a vendor returns one number anyway, ask them to split it. A single line is how the diary survives.