Check status
Customers can follow a case, order, task or process without contacting the company first.
Client portals · specialised web app
Keep status, documents and customer information in one place
I build client portals where customers can sign in, check status, download documents and submit information without the entire process happening in email threads.
When the customer process ends up in email threads
A client portal is most useful when it removes concrete friction from the way customers and employees exchange status updates, files and information today.
- Documents are scattered across email threads and attachments.
- Customers repeatedly ask for status updates or the next step.
- Files are sent back and forth manually.
- Employees answer the same questions repeatedly.
- Customer data and case information live in several places.
- Customers submit information through disconnected forms and emails.
- There is no single place where the customer can see what happens next.
If the main problem is data flow between existing systems without customer logins, an integration is often more relevant than a client portal. See integrations and automation.
What customers can do in the portal
These functions are described from the customer's point of view. The exact combination depends on the process the portal needs to support.
Download documents
Relevant documents, reports, files or agreements can be kept together around the customer or case.
Submit information and files
Customers can upload documents or provide missing information directly through the portal.
Keep relevant communication together
Messages can be linked to the customer or case so important context is not scattered across separate email threads.
Manage their own information
Where relevant, customers can update their own contact, profile or company information.
Receive notifications
Customers can be notified when a status changes, a document is ready or an action is required.
What the business gets from it
The value is not the login itself. It comes from bringing recurring customer processes, information and actions into a more consistent workflow.
Fewer manual status requests
Customers can find status and relevant information themselves instead of asking employees to send it manually.
Less manual file exchange
Documents and uploads are kept in one place instead of being handled ad hoc through email.
More consistent information flow
Customers follow the same structure and process instead of relying on different email threads and manual routines.
One place for customer data
Relevant customer information, files and status can be grouped around the same customer or case.
Better overview for employees
Employees can work from the same data and process instead of searching for information across several places.
Room for automation
Notifications, status changes and other repetitive steps can be automated where the workflow supports it.
A typical user flow
This flow shows how self-service and employee work can connect in practice. It is an example, not a fixed feature package.
Step 1
The customer receives access and signs in
Step 2
The customer views the case and current status
Step 3
The customer uploads a missing document
Step 4
The relevant employee is notified
Step 5
The case is processed and the status is updated
Step 6
The customer can follow the change in the portal
The technology sits underneath the user flow.
Authentication, roles and permissions, database, file storage and notifications can be included when the flow requires them. The architecture is defined after users, data and workflow have been scoped.
Example of implemented system functionality
A concrete in-house system project demonstrates work with data, Storage, access-related configuration, integrity checks and recovery.
Technical proof · in-house system project
pgDumpster
pgDumpster is a source-available backup and restore tool for hosted Supabase projects. The project documents concrete work with Auth configuration, Storage, data integrity and recovery.
View the project- Implemented Storage catalogue and streamed object capture.
- Implemented Auth, SSO and third-party Auth coverage with explicit handling of platform limitations.
- SHA-256 verification, checkpoints, resume and fail-closed restore flows are part of the documented implementation.
- The published release SHA is documented through CI, CodeQL and hosted source-to-target E2E.
Price level and complexity
Prices are indicative. Access model, data, workflows, files and integrations drive the scope — not the number of screens in the portal.
Simple client portal
DKK 40,000 – 65,000
Login, basic user roles, document sharing, simple status and a small number of defined workflows.
Advanced client portal
DKK 65,000 – 120,000
More roles, more advanced status or case flows, notifications, integrations, an admin interface and a more complex data model.
Larger platform
DKK 120,000+
Multiple user types or organisations, complex workflows, several integrations, an advanced permissions model and ongoing development.
What typically drives the price
- Number of user roles
- Permissions model
- Data model and relationships
- Number of workflows and statuses
- Document and file handling
- Notifications
- Integrations and APIs
- Admin interface
- Reporting
- Number of separate user interfaces
- Tenant or organisation structure
- Migration of existing customer data
The process
Client portal projects start with the current customer process and access model before features and technology are locked in.
1
Needs and current process
We map what customers ask about today, which data and documents are exchanged, how employees work and which systems the company already uses.
2
Scope and access model
Customer types, roles, permissions, data, documents, workflows, integrations, the first release and price are made concrete before development starts.
3
Development
The central customer and employee flows are built within the agreed scope, with focus on the friction the portal is meant to remove.
4
Launch and operation
The solution is deployed, user setup and relevant production checks are completed, and operation, maintenance or further development can be agreed as needed.
FAQ
Questions about client portals
The price mainly depends on roles, permissions, data model, workflows, file handling and integrations. A simple client portal is typically DKK 40,000–65,000, an advanced portal DKK 65,000–120,000, and larger platforms typically start from DKK 120,000. The final quote is based on the agreed scope.
Yes. Roles and access can be structured so different customer types or employees can only view and change the data and functions they need.
Yes. Access can be scoped per customer, user or organisation. The exact model is defined as part of the scope because it is closely tied to the data model and permissions.
Yes, when the relevant systems provide a usable integration or API. Integration requirements are clarified early because they can affect the flow, data model and price.
Yes. File upload and document sharing can be included when they are part of the workflow the portal needs to support. Access and structure are defined together with the rest of the data model.
Yes. Notifications can be connected to relevant events or status changes when they are part of the agreed workflow.
Yes. The first release can be limited to the most important customer and employee flows, with later functionality added in subsequent scopes.
Yes. Operation and maintenance can be agreed as needed after launch, and further development can be scoped separately.
Are you spending too much time on status updates, files and repeated customer questions?
Describe how your customer process works today, where communication gets stuck and what customers should be able to do themselves.
Describe your needs