Client Portal for an Agency: Features, Architecture and Cost (Lessons From Four Multi-Role Systems)

Short answer: a client portal for an agency is a login-protected web app where each client sees only their own projects, files, approvals, invoices and messages, while your team sees everything through role-specific dashboards. A basic version costs $5,000 to $8,000, a standard one $8,000 to $14,000 and an advanced one with automation and integrations $14,000 to $20,000, taking six to twelve weeks. The architecture that keeps it cheap to run is Next.js, Prisma and PostgreSQL with role-based access enforced on the server and an audit trail from day one.

I have built four systems that are portals in everything but name: the UK ETA application system (public applicants plus admin, team leader and agent roles across thirteen workflow states), the Alemmi Network platform (trader, compliance, operations and admin dashboards), the Bounce childcare platform (administrators, teachers and parents) and the Kids Garden system (staff roles with audit logs). The patterns below come from those.

What must a client portal actually do?

Short answer: answer the four questions clients otherwise email you about: where is my project, what do you need from me, what have I approved, and what do I owe. Everything else is optional until real clients ask for it.

• Status. Each project or request with a clear stage, an owner, and the next action. Thirteen states was right for a government-style application flow; three to five is right for most agencies.
• Files. Upload, versioning, and "which version did the client approve". Storage on S3 or Vercel Blob, never in the database.
• Approvals. A button that records who approved what and when. This one feature removes the most email.
• Requests and tickets. Structured forms instead of free-text emails, with a status the client can see.
• Invoices. Read-only at first, pulled from your accounting tool or Stripe; pay-now later.
• Notifications. Email, and in the Gulf and Egypt often WhatsApp, when something changes that needs the client.
• Team view. Your staff sees all clients, filters by owner and stage, and can act on behalf of a client.

Which features belong to which tier, and what does each cost?

The ranges match the "custom business system or client portal" line on my pricing page. The single biggest cost driver is the number of roles, because each role is a separate set of screens, permissions and test cases. The second is integrations.

What architecture keeps a portal cheap to run and easy to extend?

Short answer: a monolith on Next.js with TypeScript, Prisma and PostgreSQL, deployed on Vercel or a small VPS, with files on object storage, email through a transactional provider, and every permission check in a shared data-access layer on the server.

• Framework. Next.js App Router with Server Components for the pages and Server Actions or Route Handlers for mutations. Laravel with MySQL was the right choice for the UK ETA and Kids Garden systems because the teams around them ran PHP; the architecture is the same.
• Database. PostgreSQL through Prisma. Every table that holds client data carries a clientId (or organizationId for multi-tenant products).
• Authentication. Auth.js, Clerk or a Laravel guard. Email plus password with verification, optional magic links, optional two-factor for staff. The SouqSoft marketplace on this site ships optional 2FA; I do not build custom crypto.
• Authorisation. A Membership table linking users to clients with a role enum, and a single can(user, action, resource) helper called from every data function. Middleware only redirects unauthenticated users; it is never the last line of defence.
• Files. Direct-to-storage uploads with signed URLs; metadata in the database; virus scanning if clients upload documents from the public.
• Workflow. A status enum and a transitions table. The UK ETA system's thirteen states were manageable only because the allowed transitions and their side effects (emails, assignments) lived in one place.
• Audit trail. An ActivityLog table written from the same data-access layer: who, what, which record, before and after. Cheap to add on day one, painful to retrofit.
• Notifications. Resend or Postmark for email; WhatsApp Business API through an n8n workflow when clients live on WhatsApp.
• Deployment. Vercel for most portals; a VPS in the client's region when data residency matters.

// The four tables every portal has, in Prisma
model Client        { id String @id @default(cuid())  name String  projects Project[]  memberships Membership[] }
model User          { id String @id @default(cuid())  email String @unique  memberships Membership[] }
model Membership    { userId String  clientId String  role Role  user User @relation(...)  client Client @relation(...)  @@id([userId, clientId]) }
model Project       { id String @id @default(cuid())  clientId String  status ProjectStatus  files File[]  approvals Approval[]  @@index([clientId, status]) }

enum Role          { OWNER MEMBER STAFF ADMIN }
enum ProjectStatus { BRIEF IN_PROGRESS REVIEW APPROVED DELIVERED }

What scoping mistakes make portals late or abandoned?

1. Starting with five roles. Launch with client and admin. Add staff and manager roles when the second person on your team needs a different view.
2. Building chat. Real-time chat is a product on its own. Threaded comments on a project with email notifications cover 95% of the need at 10% of the cost.
3. Rebuilding invoicing. Show invoices from Stripe, QuickBooks, Zoho or Xero. Do not create a second source of truth for money.
4. No status vocabulary. If the agency cannot list its project stages on a whiteboard in five minutes, the portal cannot show them. Do this before the first design.
5. Skipping the audit trail. The first dispute about "who approved this" pays for it.
6. Custom authentication. A week of work and a lifetime of risk, for a login page a library gives you in an hour.
7. Migrating history on day one. Import active projects only. Archive the rest as PDFs in the client's file area.

Buy or build: when does a custom portal make sense?

Short answer: buy a generic portal tool if your process is generic and you have fewer than about twenty active clients. Build when the portal is how you deliver work, when per-seat pricing punishes you for adding clients, when clients must see your brand and not a vendor's, or when data must stay in your region.

What does the first month look like?

1. Week 1: scope workshop, status vocabulary, roles, data model, written scope with a fixed price.
2. Weeks 2 – 4: authentication, clients and projects, files, status pipeline, admin views, on a preview URL from day three.
3. Weeks 5 – 6: approvals, requests, notifications, invoices; first real client invited.
4. Weeks 7 – 8: polish, audit trail, exports, handover documentation, launch; thirty days of fixes follow.

Frequently asked questions

How much does a custom client portal cost?

A basic portal with login, project status and document sharing is $5,000 to $8,000. A standard portal that adds approvals, invoices, tickets and notifications is $8,000 to $14,000. An advanced portal with several roles, automation and integrations with your CRM or accounting system is $14,000 to $20,000. Timelines run from six to twelve weeks.

Should an agency buy a client portal tool instead of building one?

Buy if your process fits a generic tool and you have fewer than about twenty active clients. Build when the portal is part of how you deliver, when you need white-label branding without per-seat fees, or when client data must stay on your own infrastructure.

What technology stack is best for a client portal?

Next.js with TypeScript, Prisma and PostgreSQL covers almost every portal. Laravel with MySQL is an equally good choice when the team already runs PHP.

How do you keep one client from seeing another client's data?

Every table that holds client data carries a clientId, every query is scoped by it in a shared data-access layer, and the tests assert that a user from client A receives a 404 for client B's records. Row-level security in PostgreSQL adds a second line of defence.

How long does it take to build a client portal?

Six to eight weeks for a basic or standard portal and ten to twelve weeks for an advanced one, after a written scope. The UK ETA application system, a four-role portal with thirteen workflow states and payments, took two months.

See also the direct answer on hiring a developer to build a client portal and the backend and API development service.