A secure login area where your customers, staff, or suppliers can see their own information and do things themselves, instead of emailing someone to ask.
Most portals get built because someone is spending hours a week answering questions the customer could answer themselves if they had access.
Now
Someone searches their email, finds the PDF, and forwards it. Ten minutes, several times a week.
With a portal
They log in and download it themselves at eleven at night without anyone being involved.
Now
A phone call, then someone checks a spreadsheet, then a reply. Repeated for every client on every project.
With a portal
Updated once by whoever does the work, and seen by everyone who needs it without another conversation.
Now
Attachments over email, version three sent to the wrong person, and nobody sure which file is current.
With a portal
Uploaded once, visible to the right people only, with a record of who saw what and when.
Now
Two emails to find a new slot, one to confirm, and someone updating a calendar manually.
With a portal
Within whatever rules you set, with your calendar updating automatically and a notification if you want one.
Before scoping anything, this is the exercise worth doing yourself: count the repeated questions your team answers in a week and estimate the hours. If the number is small, a portal is an expensive solution to a minor annoyance and we'd say so. If it's most of someone's job, it pays for itself quickly.
They're built the same way underneath. What differs is who logs in and what they're allowed to see.
Type 01
Your customers see their own account, projects, documents, and history.
Type 02
Internal tools and information for your own team, often replacing shared spreadsheets.
Type 03
Outside organisations submit and receive information without emailing anyone.
Type 04
Paying members or subscribers get access to something the public doesn't.
Six questions we'd work through before quoting. The answers change the price far more than the number of screens does.
One type of user seeing their own data is simple. Several types with overlapping permissions is where complexity lives.
Worth askingCan a manager see their team's data? Can a client see their colleague's?
If the portal shows information that already exists in another system, it needs to connect to it rather than keep a second copy.
Worth askingDoes your accounting or job system have a way for other software to read it?
Showing information is straightforward. Letting people submit, edit, or approve brings rules, validation, and consequences.
Worth askingWhat happens if someone changes something they shouldn't have?
You creating accounts manually is simplest. Self-registration needs approval steps and a way to verify people are who they say.
Worth askingHow many new users a month, and who approves them?
Email or text when something changes. Useful, and easy to overdo until people stop reading any of them.
Worth askingWhich events genuinely need someone told immediately?
Someone on your side needs to add users, reset access, and fix mistakes. That interface is part of the build, not an afterthought.
Worth askingWho does this, and how technical are they?
Question three is where budgets move most. A portal that shows people things costs a fraction of one where they can also do things, because every action needs rules about who can do it, what happens if it fails, and how it gets undone. Starting read only and adding actions later is often the sensible order.
A portal holds information people expect to be private. These aren't optional extras, they're the baseline for anything with a login.
Hiding a link isn't security. The system verifies who someone is and what they're allowed to see every single time, including for data loaded behind the scenes.
A code as well as a password, at least for administrators. Passwords get reused across sites and that's how most breaches actually happen.
Who logged in, what they viewed, what they changed. It's how you answer questions later, and in regulated industries it's usually required.
When someone leaves a company or a client relationship ends, their access ends the same day. Sounds obvious, and it's the most common gap we find in existing portals.
If your portal will hold health records, financial data, or anything covered by specific regulation, say so at the start rather than after the build. It changes hosting, data location, retention, and the audit requirements, and retrofitting those is considerably more expensive than designing for them.
Smallest useful version first, in front of real users, before anything else gets built.
What people actually email about, and what your team does in response. The portal replaces this, so it has to be understood first.
The one or two things that remove the most work. Everything else waits, because feature lists written before launch are usually wrong.
A handful of real users first. Their confusion tells you more about what to build next than any planning session.
Wider release once it's proven, then features added based on what people actually asked for rather than what was assumed.
Only if it's easier than emailing you, which is a lower bar than it sounds and still gets missed. A portal that needs a password reset every visit loses to a two-line email every time.
The other half is that you have to stop doing it the old way. If people can still ring and get an answer in thirty seconds, most of them will.
Usually, if the system has a proper way for other software to read and write data. Most modern accounting, CRM, and job management tools do.
Older systems sometimes don't, and then the options are worse: scheduled exports, or someone entering things twice. Worth checking early, because it changes the shape of the project.
Check what exists first. If your industry has established software that does this, buying is almost always cheaper than building, and we'd tell you that.
Building makes sense when your process is genuinely unusual, when the available products need you to change how you work, or when you're paying per user for something you'd own outright.
It normally sits on the same domain, behind a login, so it looks like part of your business rather than a different product.
Technically it's often a separate application, which keeps a problem in one from affecting the other. To your users, it's just your site.
Hosting, which is modest, plus whatever it costs to keep it maintained and secure. Anything with a login needs updating when security issues appear in the tools it's built on.
Budget for that from the start. A portal nobody has updated in three years is a liability rather than an asset.
A focused first version is usually weeks rather than months. What extends it is connecting to other systems and the number of different user types.
If someone quotes a large fixed price for a long list of features, be cautious. Portals are the kind of project where half the original list turns out to be unnecessary once people start using it.
Scoped from your actual process rather than a feature list. Pricing sits on the main web development page.
Related services
Thirty minutes on what a portal would remove, and whether the hours saved justify building one.
Or email hello@culmen.digital