Customers should log in to see their orders. Sales wants a quote calculator. Bookings need rules about staff, rooms and deposits. Then a quote arrives with a line called “custom development”, and the web app vs website question stops being academic.
Settle it early, because the answer decides the platform, the build budget and what you will pay to keep things running for years.
The short answer
A website mainly publishes information and takes enquiries: most visitors are anonymous, everyone sees the same content, and your team updates it through a content management system (CMS). A web application lets signed-in users do work with their own data: customer portals, quoting tools, dashboards and bookings with complex rules.
Most projects that raise the question sit in between: a website on a standard CMS with a few custom features, built as a small plugin or custom blocks. A separate application is justified when signed-in users, their data and your business rules are the core of the project, not a feature on the side. Either way, custom code must be maintained, so budget for its upkeep as well as its build.
Web app vs website: what actually separates them
It isn’t how it looks. A site with bold animation is still a website; a plain grey screen where customers track orders is an application, and so are online banking, webmail and project-management tools. What matters is who uses it, whose data it holds and how much logic runs behind the screen.
| At a glance | Website | Web application |
|---|---|---|
| Main job | Explain, persuade and take enquiries | Let users complete tasks |
| Typical user | An anonymous visitor, often on a first visit | A signed-in customer, partner or employee who returns |
| Data | Content your team publishes, plus form submissions | Records users create, change and rely on |
| Logic | Page templates and forms | Business rules, permissions, calculations and workflows |
| Typical build | A CMS such as WordPress, a theme and plugins | An application framework, a database and custom code |
Four questions that settle it
Ask these of each feature on your list:
- Do users sign in to see something that belongs to them? Their orders, documents or bookings, rather than content everyone can see.
- Do users create or change records that are stored and used later? A form that sends an email doesn’t count. A quote a customer saves, edits and accepts does.
- Does the result depend on rules specific to your business? Pricing that varies by customer, availability that depends on staff and rooms, approvals routed to different people.
- Would a wrong result cost you money or trust? An incorrect price, a double booking, one customer seeing another’s invoice.
All no: you are building a website. One or two yeses for a single feature: you most likely need a website with custom functionality. Mostly yes, and those features are why the project exists: you are building an application, and it should be planned as one.
The three shapes a project can take
A standard website
Service pages, case studies, articles, enquiry forms, versions in the languages your customers use, and tracking. A well-chosen CMS, a lean theme and a few maintained plugins cover all of this without custom code, and there is nothing second-best about that: the value comes from strategy, content, design and speed. See how to choose a CMS and how websites are built for the platform and the layers underneath.
Custom design is a separate question: a site designed from a blank page can still run entirely on standard software (see custom website design vs a template).
A website with custom features: the middle path
Here the site stays a website, edited through the CMS, and a few specific jobs get custom code:
- A price estimator on a service page, with rates your team updates in an admin screen.
- An availability table for properties or products, fed from a spreadsheet or stock system.
- A custom block that lets editors add specification tables without breaking the layout.
- Enquiry forms that create a lead in your CRM, with the source page attached.
On WordPress, the maintainable way to build these is a small custom WordPress plugin for the feature, custom post types and fields for structured content, and custom blocks for anything editors place on a page. A plugin keeps working through a redesign. Code pasted into a theme’s functions.php file stops running the day you switch themes, and in a third-party theme the next update can wipe it out. Our WordPress best practices checklist shows how to spot a fragile build, and since many “custom features” are really connections to other systems, read the website integrations guide too.
A separate web application
Sometimes the application is the point. A separate build is justified when:
- Customers or partners need their own accounts, such as a customer portal website where clients follow project progress, download invoices and share files.
- The rules are complex and central, like bookings across several locations and resources, or multi-step quotes with internal approvals.
- The data is sensitive or high-volume and needs an access model and audit trail designed for it.
- It will grow like a product, with a roadmap and people who rely on it daily.
These are usually built on a web application framework such as Laravel, Django or Ruby on Rails, with their own database, hosting and release process. The marketing website often stays on a CMS and links to the application at an address like app.yourdomain.com, so a headline change never waits for a software release. If the two must share content, a headless CMS is one set-up worth understanding first.
When to build custom features, and when not to
Custom code is usually the most expensive way to add a feature and keep it working, so reach for it last. Knowing when to build custom features mostly means ruling out the cheaper routes:
- Use what already exists. Mature plugins and services handle memberships, bookings, forms with calculations and gated downloads. If one covers most of the need, adapt your process to it.
- Use the portal you already pay for. Many CRM, accounting and booking systems include a customer portal. A clear link to it may be all you need.
- Integrate rather than rebuild. If the data lives in another system, connect to it instead of recreating it.
- Simplify the process. A complex quote builder can often become a short qualifying form and a quick, human reply.
- Prove demand manually. Handle requests by email for a few months. If people use it, you will build a better tool from real requirements.
Build custom when the feature reflects how you genuinely sell, when off-the-shelf options would give customers a worse experience, or when the workaround costs more over time than the code would to build and maintain.
What custom code really costs over time
The build price is the down payment. Much of the web application vs website cost difference only shows up after launch, because every line of custom code is something you now own.
Maintenance never stops. WordPress, PHP and the libraries your code relies on keep releasing new versions, some fixing security holes, some changing how things work. A popular plugin spreads that upkeep across many sites; your own feature is updated only when you pay someone to do it.
Security becomes your job. Every login, form and upload can be probed by attackers. Widely used software is tested by many people; custom code is checked only by whoever you pay to check it. If it stores personal data, data protection law applies too. The OWASP Top 10 is a sensible reference for the risks to guard against.
Documentation decides who can help. Without notes on what a feature does and why, every future developer starts by reverse-engineering it, at your expense.
You depend on the original developer. If only one person understands the code, their availability, prices and priorities become yours. Fine while the relationship is good; risky when it isn’t.
| Over the years | Standard website | Website with custom features | Web application |
|---|---|---|---|
| Build | Lowest | Moderate: the site plus scoped features | Highest: data model, permissions and testing |
| Updates | Core, theme and plugins | The same, plus testing your own code | An ongoing development budget |
| Who can take it over | Most developers who know the CMS | The same, if the custom code is documented | Developers who know that framework and codebase |
Ask any provider for a three-year total, not just the build figure. Our starting prices are on the pricing page, every project gets a fixed written quote, and our guide to website maintenance costs shows what ongoing care should cover.
A feature-by-feature checklist
Most wish-list features belong in the middle column; move one right only if that description genuinely fits.
| Feature | Usually a website feature | Becomes an application when… |
|---|---|---|
| Quotes and estimates | A form, or a calculator with editable rates | Quotes are saved, revised, approved and turned into orders online |
| Bookings | A booking plugin or embedded booking service | Rules span staff, rooms, locations, deposits and changes |
| Customer area | Gated downloads, or a link to your CRM’s portal | Each customer sees their own documents and history from several systems |
| Product catalogue | Custom post types, filters and enquiry forms | Customers order online, with account pricing and live stock (see catalogue or online store) |
Before you approve any custom feature, tick off:
Listing these features separately in your website brief makes every quote easier to compare.
Frequently asked questions
Is a website with a login a web application?
Not necessarily. A login that opens brochures, price lists or members-only articles is a website with a membership feature, and standard plugins handle it well. It becomes an application when signed-in users create, manage and depend on their own records.
Can WordPress be used to build a web application?
WordPress can handle lighter application features: user accounts, roles, custom data types and a REST API for connecting other systems. For heavy data, complex permissions or a product that changes every month, a dedicated application framework is usually the sounder foundation. Let the data and rules decide, not familiarity with a platform.
Can we launch a website now and add an application later?
Yes, and it is often the smarter order. Launch the website, run the process manually or with an off-the-shelf tool, and build the application once real use has shown what it must do. Plan a place for the sign-in link from the start.
What to do next
Many projects that start with “we need custom development” turn out to be a strong website with two or three well-built features. Some genuinely need an application, and it is better to know that before the first line of code.
If yours is a website, or a website with a few specific features, that is what our website design and development service covers: planned around your customers, built on WordPress with the integrations you need, and handed over so your team can edit it. Not sure which shape yours is? Talk to us about what your website needs in a free 30-minute call, and we will give you a straight answer, including when a separate application is the better route.