Customer Portals
External self-service areas where customers can submit, track, and retrieve their own records without contacting support.
Software & Product Engineering
Business Applications & Portals
Work that spans several roles usually ends up spread across email, shared files, and one spreadsheet that a single person understands.
Build role-aware business applications and portals where records, approvals, permissions, and reporting live in one system with an audit trail.
Overview
Give multi-role work a system of record
When a process crosses roles — a customer submits, a manager approves, finance records, an auditor reviews — the absence of a shared system shows up as reconciliation work and disputes about what happened.
A business application makes the process explicit: who can see what, which transitions are allowed, what gets recorded, and how the result is reported. Portals extend the same model outward to customers or staff.
What this includes
Business Applications & Portals capabilities
A customer portal and an internal approvals system share machinery but little else; scope follows the roles and the records involved.
Employee Portals
Internal workspaces bringing requests, approvals, documents, and status into one role-aware place.
Workflow and approvals
Explicit states, transitions, and permissions so a process cannot skip a required step.
Records and audit trail
Change history that answers who did what and when, without reconstruction from logs.
Operational reporting
Reports and exports built on the same model that runs the process, so numbers agree.
What you receive
Concrete deliverables
- Role, permission, and workflow definition
- Portal and application implementation
- Reporting, export, and audit capability
- Administrator documentation and user onboarding material
Why it matters
Practical outcomes
One version of the record
Reconciliation between parallel copies stops being a routine task.
Approvals are enforceable
The system prevents the shortcut instead of documenting it afterwards.
Self-service reduces load
Customers and staff retrieve their own status rather than asking for it.
Reporting agrees with reality
Numbers derive from the operational model rather than a separate spreadsheet.
How a portal engagement runs
From scattered records to one system with an audit trail.
-
Map roles and permissions
Identify who uses the system, what each role may see, and where approval authority genuinely sits.
-
Model records and workflow
Define the records, their states, and the approval steps that move them between those states.
-
Implement the portal
Build the interfaces each role needs, rather than one screen with everything conditionally hidden.
-
Set up reporting and audit history
Implement the operational reporting and the activity history the organisation has to be able to produce.
-
Roll out and support adoption
Migrate existing records, train each role, and support the transition away from the spreadsheets.
What we hold ourselves to
A portal is only trusted if its record is trustworthy.
These are the commitments behind a system that becomes the reference rather than another copy.
- 01
Role-aware access by construction
Permissions are enforced in the data layer, so a role cannot reach records it should never see.
- 02
Approvals recorded as history
Who approved what, and when, is stored as an immutable record rather than a mutable status field.
- 03
One authoritative record
The system is designed to be the source of truth, not a further copy that drifts from the others.
- 04
Reporting from live data
Operational reports read the same records staff work in, so numbers do not disagree between screens.
- 05
Access review made possible
Permission assignments are visible and reviewable rather than accumulating silently over years.
Relevant technology
What a role-aware portal rests on
Application services, the interfaces each role uses, the record store, and the access controls around it.
Capability domain
11 tools
Backend
- Laravel
- PHP
- Node.js
- NestJS
- .NET
- ASP.NET Core
- Python
- Django
- FastAPI
- Java
- Spring Boot
Capability domain
8 tools
Frontend
- TypeScript
- JavaScript
- Angular
- React
- Next.js
- Vue.js
- Nuxt
- Tailwind CSS
Capability domain
7 tools
Databases
- PostgreSQL
- MySQL
- SQL Server
- Oracle
- MongoDB
- Redis
- Elasticsearch
Capability domain
5 tools
Security
- OAuth 2.0
- OpenID Connect
- OWASP practices
- Role-based access control
- Secrets management
Scope boundaries
Where this work hands off
A portal leans on the systems and safeguards around it, so those neighbouring pieces of work are named rather than assumed.
-
Custom Software Development
Portals start from a known shape. When the process being supported has no recognizable pattern of roles, records and approvals, it is a bespoke build rather than a portal.
-
API & Integration Development
A portal is usually a face over systems that already hold the data, so the integrations behind it are frequently the larger half of the work and are scoped on their own terms.
-
Application Security & Hardening
Role-aware access and audit trails are designed in; verifying that one customer cannot reach another’s records is an independent review worth commissioning.
-
AI Workflow Automation
Recording an approval and deciding one are different responsibilities. Where a step should be automated rather than routed to a person, that is examined as automation work with its own oversight.
Questions
Useful context before a consultation
Portal questions usually concern role modelling, migrating existing records, and what the audit trail must capture.
How is this different from custom software development?
It is a focused subset. Business applications and portals share the same engineering approach but start from a known shape: roles, records, approvals, and reporting.
Can a portal sit on top of existing systems?
Frequently, and it is often the better option. Feasibility depends on the APIs, data ownership, and authentication those systems expose.
Can it replace the spreadsheet the process currently runs on?
That is usually the point. The work is less about rebuilding the spreadsheet than about recovering the rules living in one person’s head and making them explicit states the system can enforce.
How do external customers sign in?
Through their own accounts, or through an identity provider you already operate. Customer-facing and staff-facing access are kept as separate concerns so a permission mistake cannot cross between them.
Can we see who changed a record?
Yes. Change history is part of the data model rather than something reconstructed from server logs, so who did what and when is answerable directly.
Start a conversation
Discuss a portal or business application
Describe the roles involved, the approvals that matter, and where the record currently lives.