A common request is for a website, when what is described is a portal. It usually goes something like this: "We need a new website, and customers should be able to log in and see their orders." That second half changes the project entirely — the budget, the timeline, and the questions worth asking first.
The two are genuinely different kinds of software. Confusing them is expensive in both directions: you can spend portal money on a problem a website would have solved, or you can commission a website and discover four weeks in that it needs to do something a website fundamentally does not do.
Here is how we think about the distinction, and the questions we ask to work out which one a business needs.
The core difference
A website presents the same information to everyone. It explains what you do, who you do it for, and how to get in touch. Its job is to convert a stranger into an enquiry. Every visitor sees the same pages.
A portal shows each person something different, based on who they are. Its job is to let someone do something: check their own order, upload a document, submit a request, approve an item. It requires a login, because without knowing who the visitor is, it cannot show them anything.
That single difference — does the content depend on who is looking at it — drives almost everything else. Once content is personal, you need accounts, authentication, permissions, a database that holds records per user, and a way for your own team to manage all of it. That is a different scale of project, and it should be.
A simple test
Ask this: can a visitor get value from the page without telling you who they are?
If yes, it belongs on a website. A price list, a service description, a case study, a contact form — none of these need to know the visitor.
If no, it needs a portal. "Where is my order," "what is my outstanding balance," "which documents am I still missing" — these are unanswerable without identity.
Most businesses need both, which is where the confusion begins. The public site brings in enquiries. The portal serves the customers you already have. They can share a design language and even a codebase, but they are separate pieces of work with separate purposes.
What a website is genuinely good at
We want to be clear that "just a website" is not a lesser thing. For a great many businesses, a well-built website is the highest-return digital investment available, and a portal would be a distraction.
A website earns its cost when:
- Most of your enquiries come from people who do not know you yet
- Your buyers research before contacting, which is now most B2B buying
- You need credibility before a first meeting
- Your competitors' sites are better than yours and you are losing comparisons
- You want to rank for the services you actually sell
If you are in that position and you also build a portal, you have spent a large part of the budget on something your existing twenty customers will use occasionally, and underspent on the thing that brings in the next twenty.
What a portal is genuinely good at
A portal earns its cost at a specific, recognisable moment: when a meaningful share of your team's day is spent telling people things a screen could tell them.
That is the signal we look for. Not "customers would like a login" — customers always say yes to that question. The signal is on your side of the relationship. Count how many times a week your team answers "where is my order," re-sends an invoice, or tells a vendor when they will be paid. If that number is large, a portal converts a recurring labour cost into a one-off build cost.
The secondary benefits are real but usually not enough on their own:
- A complete record of what was shared with whom and when
- Customers able to act outside your working hours
- A more professional impression when competing for larger accounts
- Documents in one place instead of scattered across inboxes
Four questions that usually settle it
When someone is unsure, these four questions almost always produce a clear answer.
1. Who is the audience — people who know you, or people who do not?
If the audience is prospects, build a website. If it is existing customers, vendors or staff, you are describing a portal.
2. What does the visitor want to do?
"Understand what you offer and decide whether to contact you" is a website. "Check something specific to them, or submit something" is a portal.
3. Where is the pain right now?
If the pain is not enough enquiries, that is a website problem. If the pain is too much time servicing existing relationships, that is a portal problem. Businesses often have both, and the honest answer is usually that one is costing considerably more than the other.
4. Does the information already exist somewhere?
A portal is a window onto data you already maintain — in an ERP, an accounting system, a database. If that data does not exist in a structured form anywhere, the portal is not your first project. Getting the underlying system in order is.
That last point catches people out more than the others. A typical case: a business wants a customer portal showing order status, but order status is not recorded anywhere systematically — it lives in a WhatsApp group and one person's head. No portal can display information the business does not capture. The real project is an order management system; the portal is phase two.
Cost, honestly
Ranges are risky because scope varies enormously, but the shape of the difference matters more than the numbers.
A business website is bounded work. The page count is known, the content is largely static, and there is no user data to secure or maintain. Once launched, the running cost is small.
A portal is open-ended in a way websites are not. Every user role multiplies the testing. Permissions need thinking through carefully, because a bug that shows one customer another customer's data is not a cosmetic issue. It usually needs to integrate with a system that holds the real data. And it needs ongoing maintenance, because it is now part of how your business operates rather than how it markets itself.
As a rough shape: a portal is typically several times the cost of a website of comparable visual quality, and it carries a genuine ongoing commitment. That is not a reason to avoid it. It is a reason to be sure the recurring cost it removes is larger.
The sequence we usually recommend
For most businesses that need both, this order works:
- Build the website properly. It brings in enquiries, which funds everything else, and it is the cheaper of the two.
- Make sure the underlying data is captured. If order status or document records do not exist systematically, fix that. This is often an internal tool rather than a customer-facing one.
- Build the portal module that removes the most work. Not all of it. The single highest-volume query, done well.
- Extend based on what people use. Usage data after three months will tell you more about what to build next than any planning session.
Trying to do all of this at once is how projects run long and get abandoned partway through.
Where this leaves you
If you are reading this trying to decide, the shortest version is: count the questions.
If you spend your week trying to be found by people who do not know you, you need a website.
If you spend your week answering the same questions from people who already know you, you need a portal.
If both are true, do the website first, and be honest about whether the data behind the portal actually exists yet.
If you would like help working out which situation you are in, that is exactly what an initial discussion is for — and it is free. We will tell you plainly if the smaller project is the right one.
