Website Development for Business: Site, Web App or CMS?

When a business asks for a website, they may mean any of three things, and the three have almost nothing in common technically. Getting this wrong at the quoting stage is the most common reason a web project disappoints.

A marketing site: built to be found

If the job is to rank in search, explain what you do and generate enquiries, the priorities are page speed, crawlable markup, structured data and content that answers real questions. There is no logged-in area and very little state. This should be server-rendered and aggressively cached, because a marketing page that takes four seconds on a mid-range phone loses the visitor before your copy is read.

A web application: built to be used

If people log in and do work, you are building an application that happens to run in a browser. Now the priorities invert: search engines never see it, but state management, permissions, validation and error handling become the bulk of the effort. Dashboards, portals, booking systems and internal tools all belong here.

"Ask one question before quoting: does this page need to be found by a stranger, or used by someone who logged in? The answer changes the entire build."

A CMS-driven site: built to be changed

If your marketing team needs to publish without a developer, you need a content management layer. The mistake is treating this as a checkbox: a CMS that lets anyone place any block anywhere produces an inconsistent site within three months. Constrain the editor to the components your design system defines, and the site stays coherent as it grows.

What good looks like technically

Whichever you build, the same fundamentals apply: images sized and lazy-loaded, no layout shift as the page settles, a single canonical URL per page, accessible contrast and keyboard navigation, and HTTPS with sensible caching headers. These are not extras. They are what separates a site that ranks and converts from one that merely exists.