"Do we need a website or a web app" gets answered by page count or visual complexity more often than it should be. The distinction that actually matters, and actually predicts cost, is simpler and less intuitive: does the thing manage state for a logged-in user.
The actual line
A website serves largely the same content to every visitor: a marketing site, a blog, a brochure site with a contact form. A web app manages state and behavior specific to an individual user: a dashboard, a logged-in account area, a cart that persists, data the user creates or modifies that needs to be stored, retrieved, and kept consistent. That line, not visual polish or how many pages exist, is what actually separates the two.
Why this changes the cost model entirely
A website's cost scales roughly with content volume, design complexity, and how many page templates it needs. A web app's cost scales with something different: the complexity of the state it manages. Auth and session handling, a real data model, permissions (who can see or edit what), and correctness under concurrency, what happens when two users or two requests touch the same data at close to the same time. None of that shows up in a page count, and all of it is where a web app's actual engineering effort goes.
Where this mismatch actually bites
The common failure: a project gets scoped and quoted like a website, pages, design, content, and the state-management requirements, auth, a real data model, what happens under concurrent access, get discovered mid-build once the "add a customer login" feature turns out to need all of it. That's not a sign the original scoping was careless; it's a sign the website/web-app distinction wasn't made explicit early, when it would have changed the estimate honestly instead of surprising everyone later.
Not sure if what you're building is a website or a web app?
Tell us what it needs to do for a logged-in user, if anything. We'll tell you honestly which category it falls into, and what that actually means for timeline and cost.
Talk to an engineer →A practical test
Ask: does this need to remember anything specific to one user, across visits, that isn't just "they filled out a form once"? A saved cart, a dashboard of their own data, permissions that differ by account, anything with real concurrent-access implications. If yes, it's a web app, and the estimate should reflect state-management complexity, not page count. If no, it's a website, and content and design complexity are the honest cost drivers.
The rule
Don't scope by page count or visual ambition alone. Ask whether the product manages real state for a logged-in user, name that distinction explicitly during scoping, and price the engineering effort it actually implies, auth, data modeling, concurrency, rather than discovering it mid-build. For how a full web-app's underlying data model gets structured well from the start, see five content-model mistakes that make Directus painful later. We scope and build both under web app development engagements.