A customer portal is a multi-tenant application wearing a simple interface
Client logins, document sharing, order status, invoices, support history. The interface is usually the least of it: the moment two customers can log in to the same application, every single query has to be right about which of them is asking, and that is a discipline rather than a feature.
- Two or more of your customers can log in to the same application.
- The portal shows documents, invoices or data that must not cross accounts.
- A customer has asked how you keep their data separate from another client's.
- You invite users by email and roles are managed by hand.
- The portal is part of what you sell, not an add-on.
Where a generated prototype stops being enough
Not general advice. These are the failures specific to this kind of product, and none of them are visible on screen.
- 01
Tenant isolation is every query, not one setting
There is no switch that makes an application multi-tenant. Every read and every write has to be scoped to the caller's account, and one endpoint that forgets is the whole guarantee.
- 02
Files are the leak people forget
Authorization gets attention on database rows and almost none on documents.
- 03
Invitations are an authorization surface
Invite flows are written for the happy path. The interesting questions are what happens when an invite is forwarded, reused, accepted by a different email, or accepted after the inviter has left.
- 04
Your customers' security teams will ask
A portal is the part of your product a client's IT department looks at.
The sentences we hear most, and what we do about each one
"How do I prove customers cannot see each other's data?"
The honest answer for most portals is that nobody has checked.
How we helpA cross-tenant test suite: two seeded accounts, and an assertion on every endpoint that account A cannot read or write account B's records.
"A client saw another client's document"
The worst call to get, and it is nearly always object storage rather than the database.
How we helpFiles move behind short-lived signed URLs issued only after an authorization check, buckets are made private, and the previously public paths are rotated.
"Onboarding a client takes me two hours of manual setup"
Accounts created by hand, roles assigned in a database GUI, documents uploaded one at a time.
How we helpSelf-serve invitations with roles, bulk import for the initial data, and an admin view where onboarding is a form rather than a database session.
"The security questionnaire stopped the deal"
A larger client sends a spreadsheet, several answers are honestly "no", and the deal moves to a slower track or stalls entirely.
How we helpWe close the controls the questionnaire actually asks about - isolation with evidence, encryption, access review, audit logging, backup and recovery - and write the answers alongside them.
The parts that make it hold
Tenant isolation with proof
Scoping enforced at the data layer and asserted by a cross-tenant test suite that runs on every commit.
Document access control
Private storage, short-lived signed URLs issued after an authorization check, and access logged per download.
Invitations, roles and offboarding
Single-use invitations bound to an address, roles inside each account, and removal that actually revokes sessions.
Audit trail per account
Who logged in, what they viewed, what changed - visible to your team and, where it helps the sale, to the client.
Branding per client
Logo, colours and a custom domain per account where that is part of what you sell.
The security answers, written down
Isolation model, encryption, retention, backup and recovery documented once so the next questionnaire is a copy rather than a project.
Usually connected to
- Auth: Auth0, Clerk, WorkOS, or your own with SSO for enterprise clients
- Storage: S3 or compatible, with signed access
- Billing: Stripe, including per-account plans
- E-signature: DocuSign, Dropbox Sign
- Email and notifications: Resend, Postmark, SendGrid
- Your CRM, so portal accounts and customer records agree
In the order it actually happens
Growth does not break everything at once. For this kind of product it breaks these four things, in this sequence, and each one is cheap to fix before it happens.
| At | What breaks | becomes | The fix |
|---|---|---|---|
| Second customer | Any endpoint that forgot to scope by account | Data-layer scoping plus a cross-tenant test suite in CI | |
| First shared document | Files served from URLs that check nothing | Private buckets and short-lived signed URLs after an auth check | |
| ~20 accounts | Manual onboarding becomes the growth constraint | Self-serve invitations, roles, and bulk import | |
| First enterprise client | SSO, audit and retention answers do not exist | SAML/OIDC sign-on, audit log, and written security documentation |
Four phases, each ending in something you keep
The first one is free. Scope is fixed after it, and you keep the findings whatever you decide next.
- 013–5 days
Isolation audit
Free. We create two accounts and try, endpoint by endpoint and file by file, to reach one from the other.
You receive
- Cross-tenant findings with reproducible requests
- Document and object-storage access review
- Invitation and session lifecycle review
- Ranked plan with effort estimates
- 021–3 weeks
Close the isolation gaps
Scoping moves into the data layer, files move behind signed access, and the guarantee is captured as tests that run on every commit.
You receive
- Data-layer tenant scoping
- Cross-tenant test suite in CI
- Private storage with signed, logged access
- Session and invitation lifecycle fixed
- 031–2 weeks
Onboarding and roles
Self-serve invitations, roles within an account, bulk import, and an admin surface that makes adding a client a form.
You receive
- Invitation and role management
- Bulk import for initial client data
- Admin console for account operations
- 041–2 weeks, plus 30 days support
Enterprise readiness
SSO, audit trail, retention and the written security documentation that unblocks a procurement review.
You receive
- SAML/OIDC single sign-on
- Per-account audit log
- Written security and data-handling documentation
- 30 days of post-launch support
Before you book the call
Create two accounts. Log in as the second one. Take a record id belonging to the first - from a URL, an export, or a network request - and ask the API for it directly rather than through the interface.
Not always, but you need the controls it would attest to, and you need to be able to describe them.
Yes. Both are perfectly good multi-tenant backends when the access rules are written and tested properly.
Related solutions
Business internal tools
The admin panel, ops console or back office that the business now depends on.
See what breaksOperations dashboards
The numbers the business runs on - accurate, fast, and the same for everyone.
See what breaksField service management
Dispatch, job tracking and a technician app that has to work in a basement.
See what breaks
Building customer portals?
The first review is free, and it ends with a straight answer - including when the answer is to buy something off the shelf instead.