Web portal development for people outside your organisation
Customer, partner, vendor, and employee portals — self-service access to your systems with the permissions and audit trail that requires.
the same portal, a different view for every role
- Role-based access
- Self-service workflows
- Document exchange
- Best when
- Customers, partners, or vendors keep asking your team for information they could get themselves.
- Not a fit when
- The data they need does not live in any system yet.
- First thing you get
- One role's portal live on real data, with access scoped at the data layer.
What is a web portal?
A web portal is a secure website that gives customers, partners, vendors or employees self-service access to your internal systems, such as order status, statements, invoices and documents, so they stop phoning your team for it. The hard part is the boundary. We build portals where each party sees strictly its own data, with every action recorded.
Every portal exists to remove a phone call. A customer wants order status, a partner wants their commission statement, a vendor wants to submit an invoice — and today each of those interrupts someone on your team who looks it up and reports back.
The engineering challenge is not the interface, it is the boundary: giving outside parties genuine self-service access to internal data while ensuring each one sees strictly their own, with every action recorded.
What this includes
- 01
Role-based access
Permission models where external users see exactly their own data and nothing adjacent.
- 02
Self-service workflows
Requests, submissions, and status tracking handled without your team in the middle.
- 03
Document exchange
Secure upload and download with versioning and access records.
- 04
Backend integration
Live data from your existing systems rather than a separately maintained copy.
- 05
Notifications
Email and in-app updates so users do not have to keep checking.
- 06
Audit trail
A record of who accessed and changed what, which matters the moment anything is disputed.
Situations we see most often
Customer self-service
Orders, invoices, tickets, and status available directly instead of through your support queue.
Partner and franchise portals
Distributors or franchisees managing their own operations against shared central data.
Vendor portals
Suppliers submitting invoices and tracking payment without emailing accounts payable.
Employee self-service
Internal requests and records handled without routing everything through HR or IT.
What to know before you start
What kinds of portals do businesses build?
Customer portals for order status, documents and support requests. Partner and franchise portals for commissions, leads and stock. Vendor portals for purchase orders, invoices and compliance documents. Employee portals for HR and internal requests.
Each exists to remove a phone call or an email: information someone outside your team needs, and that today someone inside your team has to look up and send.
How is each organisation kept to its own data?
Access is scoped at the data layer, not only in the interface. Every query is filtered by the user's organisation and role on the server, so even a hand-crafted request cannot reach another organisation's records. We test that boundary explicitly, including attempts to cross it.
Every action is recorded in an audit trail, so you can see who viewed, downloaded or changed what, and when.
How does a portal connect to internal systems?
Portals work best as a controlled window onto live data, not a copy of it. We connect to your ERP, CRM or database through their APIs, and where a system has none, build an integration layer in front of it.
That keeps the portal current without anyone re-entering data, and keeps your internal systems the single source of truth.
How do you get outside users to actually adopt a portal?
By making the portal faster than the phone call it replaces. The two or three things each audience asks for most, such as order status, an invoice copy or a document upload, sit on the first screen, sign-in is simple, and every page works well on a phone.
We launch with one audience and one high-value workflow, measure usage, and add the next based on what people actually use rather than everything at once.
Can a portal start small?
It should. One audience, one workflow and real data is enough to prove value. A customer order-status page or a vendor invoice upload often removes a surprising share of inbound calls on its own, and tells you what to build next.
What drives the cost of a web portal?
Portal cost depends mainly on how many kinds of users it serves and how many systems sit behind it. These factors move it most.
| Factor | Effect | Why it matters |
|---|---|---|
| User types and roles | High | Each audience, such as customers, partners or vendors, needs its own workflows, views and permissions. |
| Backend integrations | High | Connecting to ERPs, CRMs and databases, especially ones without APIs, is usually the largest piece of work. |
| Self-service workflows | Medium | Read-only status is simpler than workflows where outside users submit, approve or update records. |
| Document exchange | Medium | Uploads, versioning, approvals and secure downloads add storage and access-control work. |
| Sub-user administration | Medium | Letting partner organisations manage their own users adds a layer of delegated permissions. |
| Audit and compliance | Low | An audit trail on every action is built in; regulated retention rules add some configuration. |
What a typical engagement looks like
- 011–3 weeks
Discover
Process map
- 022–4 weeks
Design
Interactive prototype
- 03two-week cycles
Build
Working software each cycle
- 04ongoing
Ship & support
Automated pipeline
What we build it with
- Access
- Role-based accessRow-level scopingAudit log
- Frontend
- Next.jsReactTypeScript
- Integration
- REST APIsExisting databasesDocument storage
Where we have done this
Service contracts visible before they lapse
A command centre for a franchise service network — service complaints, AMC renewals, customer devices, and branch-level cash and revenue in one operational view.
- Web application
- Companion customer app
Approvals with a trail an inspector can read
A controlled-access portal where every software, instrument, and equipment access request is approved through a defined workflow and permanently recorded in an audit trail.
- Web application
- Role-based portal
Questions we get asked
01How do you keep external users from seeing each other's data?
Access scoping enforced at the data layer rather than only in the interface, so a crafted request cannot reach another organisation's records. This is tested explicitly rather than assumed.
02Can it connect to our existing systems?
Yes, and it should. Portals work best as a controlled window onto live internal data. Where a system has no API, we build an integration layer in front of it.
03Can partners have their own sub-users?
Yes. Multi-level access where a partner organisation administers its own users within the permissions you grant them.
04Can the portal send notifications?
Yes. Email and in-portal notifications for events like a new invoice, a status change or a pending approval, so users do not have to keep checking.
05Does it work on mobile?
Yes. Portals are responsive by default, and for field partners or vendors we can make key workflows installable and offline-capable as a progressive web app.
06Can users sign in with their company accounts?
Yes. Single sign-on through Google, Microsoft or your identity provider can sit alongside email sign-in, so partner organisations can use the accounts they already manage.
Adjacent capabilities
Tell us what you are building.
Share the problem and we will come back with an approach, a rough shape of the work, and what it would take to deliver it.