01
Customer / service portal
For B2B services, professional firms and advisory teams: service progress, document exchange, billing visibility and customer requests connected to CRM, accounting or case workflows.
Scope of this page
Choose this service when external users are part of the workflow
This service combines an external user area with the internal layer that operates it. If every user is part of your own team, Internal Tools is usually the better fit. If the product spans several public and private surfaces or multiple core business domains, start with Custom Platforms.
Portal types we build
External-facing portals — six common shapes
Start with who enters the system and what they need to complete. The workflow should shape the portal — not a generic dashboard template.
02
Partner portal
Channel sales, distribution networks, dealer networks. Multi-tier access, deal registration, training content, co-marketing assets, performance reporting.
03
Investor portal / Data room
Family offices, funds, M&A advisory boutiques. LP/GP access tiers, document versioning, audit trails, portfolio reporting, deal flow.
04
Vendor / supplier portal
Procurement, supply chain, RFQ flow. Vendor onboarding, document exchange, invoice submission, performance tracking.
05
Contractor / external workforce portal
Contractor and freelancer onboarding, document collection, access requests, time or delivery records and signed agreement workflows.
06
Client case portal
Legal, tax, compliance and advisory services. Secure intake, case state, document upload, billing visibility and traceable case history.
Why architecture comes first
What breaks when portals are added too late
01
External users inherit internal workarounds
A thin portal cannot remove the email, spreadsheet and copy-paste steps behind it. Customers see an interface, while every meaningful action still waits for someone inside to move the work forward.
02
The back-office remains the real system
If staff update users, approvals and status elsewhere, the portal is always one step behind. The customer view becomes a partial copy rather than the operational source.
03
Documents and status data drift between systems
Files, workflow state and billing facts diverge because no system owns the complete transition. Reconciliation becomes routine work instead of an exception.
04
Access rules become inconsistent as the portal grows
Permissions added screen by screen are difficult to reason about and test. Who can see or change each record must be a system rule, not a collection of interface exceptions.
Build vs Buy
When a custom portal earns its complexity
Standard tools are often the better choice for login, file sharing and a simple status page. Custom development becomes justified when adapting your operation to the tool would create more risk and manual work than owning the workflow:
- 01Your service depends on workflow states a standard portal cannot represent cleanly
- 02External actions must change real operational or revenue-critical work
- 03Several systems must agree on ownership, status and the next action
- 04Customer organisations need reliable separation and different access rules
- 05The portal is a long-lived product capability rather than a temporary convenience
Where an existing tool covers the requirement cleanly, we will recommend configuration or integration rather than a custom build.
Security boundary
Engineering controls and legal responsibility are separate
We translate the agreed risk and data-handling requirements into technical controls, testable behaviour and delivery evidence. The required level depends on the users, data, actions and systems in the actual portal — not on a generic security checklist.
The client and its advisers remain responsible for legal classification, policy decisions and any formal certification or regulatory assessment. We make those decisions implementable and verifiable in the software.
