"We need a website" is one of the most common requests I get, and about a third of the time, what the person describes is not a website. It is a web application: a system where customers or staff log in, enter data, track things and get work done. The two look similar in a browser, but they are built, priced and maintained very differently.
Getting this right at the start saves you from two expensive mistakes: paying for an application when a simple site would do, or forcing a website builder to behave like an application until it collapses.
The simple test
Ask one question: do people log in and change things?
- If visitors mostly read, look and contact you, it is a website. Home, services, about, projects, blog, contact form.
- If users have accounts, enter data, see their own records, and the business manages those records in a back office, it is a web application.
A website is like a brochure. A web app is like a tool.
Examples of websites
- A company presenting its services and projects, like AgriDev or Alpha Green, built on WordPress with Elementor so their teams edit content without code.
- A restaurant site with a menu, opening hours and a map.
- A clinic site listing doctors and services, with a contact or appointment request form.
- A portfolio, like this one.
These are mostly content. The important qualities are clear messaging, good design, speed, search visibility and easy editing.
Examples of web applications
- The dispatcher and admin app for NeonTask: work order intake, queues, map and schedule, receivables and reports, built in Next.js on a .NET Core API.
- The admin desk behind Pro Clean+, where the business manages availability, bookings, quotes and visits.
- A customer portal where clients see their invoices and open support requests.
- An internal tool replacing a set of spreadsheets.
These are mostly logic. The important qualities are correct business rules, permissions, data integrity, reliability and speed of daily use.
Why the difference matters for cost
A website's cost is driven by design and content: how many page types, how custom the design is, how many languages. Once built, it changes mostly when content changes.
A web app's cost is driven by rules and data: roles, workflows, statuses, calculations, integrations, reports. It needs a database, authentication, backups, monitoring and security work. It keeps evolving as the business learns how it uses it.
So a quote for "a website" and a quote for "a web app" are not comparable, even if both show a login button in the design mockup.
The common trap: the plugin-powered app
The most expensive mistake I see is a website platform stretched into an application. It starts as a WordPress site, then gets a booking plugin, a membership plugin, a form builder with conditional logic, a custom table plugin, and a few snippets glued together. Each piece works alone. Together they are slow, hard to update and fragile, and nobody fully understands how data flows between them.
WordPress is excellent for websites. When the centre of your product is workflow and data, build that part as an application. I compare the two approaches in more detail in WordPress with Elementor or a custom Next.js site.
When you need both
Many businesses need a website and an app, and that is fine. A common structure:
- A public website for marketing, SEO and enquiries, which the team edits freely.
- A web app, on a subdomain such as
app.yourcompany.com, for logged-in customers or staff. - Sometimes a mobile app on top of the same backend, for customers or field staff.
The website and the app can use different technologies. What matters is a consistent design and a clear handoff, like a "Log in" button that leads to the app.
Signs your "website" is really an app
Watch for these in your own requirements:
- "Customers should see their orders/bookings/history."
- "Staff need to update the status."
- "The manager needs a report of..."
- "Different users see different things."
- "It should calculate..."
- "We want to replace our Excel sheet."
Each of these is application logic. One or two can sometimes be handled on a website with a good form tool. When the list grows, plan an application.
Signs your "app" can start as a website
The reverse also happens. Sometimes a business asks for an app when what they need first is visibility and a way to receive enquiries. If you are not yet sure customers will use self-service features, a strong website with a well-designed enquiry or booking request form can validate demand. Once requests come in regularly, you know exactly what the app needs to do.
What a web app needs that a website does not
If you are going the application route, expect these as part of the work:
- Authentication and permissions: logins, password resets, roles.
- A database design that reflects your business accurately.
- An admin back office to manage everything.
- Audit and history: who changed what and when, for anything that matters.
- Backups and restore tests. See Postgres backups that actually restore.
- Monitoring and alerts, because people depend on it during the working day.
- A deployment pipeline, so changes ship safely and often.
These are not optional extras. They are what makes an application trustworthy.
Hosting and running costs
A website can often live on simple hosting: a managed WordPress host, or static files served from a fast server. Traffic spikes are mostly about caching.
A web app needs a server or platform that runs your backend, a database, file storage for uploads, backups, and a way to deploy updates without downtime. My own setup for applications is Dockerized services on Linux servers with a CI/CD pipeline that builds and ships every change. That has a running cost in both server fees and someone's time to keep it healthy, which belongs in your budget from day one. See hosting a business website for the website side.
How to brief a developer
Whichever you need, describe it in terms of people and tasks:
- Who visits or uses it?
- What do they need to find out, or get done?
- What does your team do with the result?
- What do you use today, and what is painful about it?
A good developer will tell you from that description whether you need a website, an app or both, and explain why. If you would like that conversation, see my work and get in touch.