A client portal sounds simple until you ask what the client should actually do after logging in.
If the answer is only:
Download two PDFs.
You may not need custom software.
If the answer becomes:
See project status, upload documents, approve work, view invoices, make payments, raise requests and track history.
Now you are designing a product.
For 2026 planning:
| Portal type | Planning budget |
|---|---|
| Basic secure portal | $10k–$20k |
| Operational client portal | $20k–$40k |
| Integrated multi-role portal | $40k–$80k+ |
| Enterprise / regulated portal | Scope individually |
Start with the five emails clients keep sending
A portal should remove repeated operational friction.
Ask the team:
- “Can you resend that document?”
- “What stage is my work at?”
- “Have you received my payment?”
- “What do you still need from me?”
- “Who is handling my account?”
Those questions reveal useful client tasks.
The first portal scope might simply let a client:
- see current status;
- upload requested documents;
- approve a deliverable;
- view invoices;
- contact the responsible person.
That is much clearer than starting with a 60-feature portal wishlist.
Permissions are the foundation
Portals usually contain information that is not public:
- contracts;
- invoices;
- client files;
- internal status;
- personal details;
- messages.
A password is not enough.
The system needs to understand which organization or person owns each record and enforce that access consistently.
Supabase, for example, recommends Row Level Security for exposed Postgres tables and documents multi-tenant access as a common use case. See Supabase RLS.
Whatever stack is used, test a simple rule:
Can Client A ever reach Client B’s record by changing an ID or calling an API directly?
If the answer is “the button is hidden,” the authorization design is incomplete.
Documents add more scope than the upload control
A real document area may need:
- allowed file types;
- file-size limits;
- virus/security handling where appropriate;
- storage;
- previews;
- versions;
- access control;
- deleted-file behaviour;
- retention;
- audit history.
Sensitive documents deserve more design than a drag-and-drop component.
Billing creates state
Showing an invoice is easy.
A dependable payment workflow may have to understand:
- amount due;
- payment attempt;
- success/failure;
- retry;
- partial payment;
- overpayment;
- refund;
- manual transfer;
- receipt;
- reconciliation.
Do not treat a checkout redirect as the authoritative financial record.
Administration is part of the product
The first customer will eventually get stuck.
Your staff may need to:
- invite/remove users;
- reset an account;
- inspect a failed upload;
- correct a status;
- resend a notification;
- review payment state;
- see audit history.
If the portal has no safe admin tools, support becomes database surgery.
Should you build or buy?
Buy an existing portal when:
- your workflow is standard;
- branding flexibility is sufficient;
- integrations are simple;
- recurring pricing is acceptable;
- security/compliance fit your requirements.
Build custom when:
- the portal is part of how you deliver the service;
- several internal systems need to appear as one experience;
- permissions are unusual;
- customers perform proprietary workflows;
- generic products force staff into duplicate manual work.
Custom software should remove operational friction, not reproduce a SaaS product you could have subscribed to tomorrow.
Good fits for custom portals
Strong candidates often include:
- law firms;
- accountants;
- consultants;
- property businesses;
- agencies;
- financial/professional services;
- logistics companies;
- B2B service firms.
The pattern is repeated exchange of information between company and client.
Privacy and security belong in scope
The OWASP ASVS provides a useful framework for security verification of web applications.
At minimum, define:
- account lifecycle;
- role/permission model;
- file access;
- sensitive fields;
- logging;
- backup/recovery;
- session behaviour;
- support access.
For Nigerian organisations processing personal data, also review current guidance from the Nigeria Data Protection Commission.
What should appear in the quote?
I would expect clarity around:
- user types;
- invitation/onboarding;
- permissions;
- document storage;
- requests/approvals;
- notifications;
- billing;
- integrations;
- admin tools;
- audit history;
- migration;
- security;
- deployment;
- support.
Without this, “client portal” is too vague to price responsibly.
Build the portal around tasks, not dashboards
A dashboard is not a product outcome.
“Client can upload the required tax documents and see whether they have been reviewed” is.
That difference keeps scope grounded.
If your team spends too much time resending files, answering status questions or reconciling client approvals across email and WhatsApp, send me the current client process. I can help determine whether an existing portal product, a lightweight custom layer or a full custom workspace makes sense.
