A custom client portal earns its cost the moment client updates stop living in your inbox. The mistake in client portal development is treating it as a platform build. Ship the smallest version that kills the three emails you send most, then grow it once clients actually log in.
Right now you are the status API for every project. A client emails 'any update?' and you stop real work to screenshot a folder, paste a link, and reassure them it is on track.
You have probably patched this with shared Drive folders, a WeTransfer link, a Calendly, and a spreadsheet only you can read. That stack holds until you pass a handful of clients. This guide covers when a portal beats another SaaS login, the v1 worth building first, the stack that keeps it cheap to own, and the point where it pays back.
- Build for three jobs: status, documents, and the one action clients keep emailing you to do. Everything else is v2.
- Buy when the workflow is generic, build when the workflow is your business. A portal that mirrors how you actually deliver is the part no SaaS sells.
- A first portal runs €20K to €50K, shipped in weeks. Most of that price buys auth, permissions, and reliability work. The screens are the cheap part.
- The payback is operational: fewer status emails, faster handoffs, and turnaround you can put a number on.
What a Client Portal Actually Replaces
A client portal is one authenticated place where a client sees their work with you and acts on it. Strip the buzzwords and it replaces a pile of tools you already pay for.
The usual pre-portal stack is a shared Google Drive folder, an email thread per client, a WeTransfer link when files get big, a Calendly for scheduling, and a spreadsheet only you can read. Each tool is fine alone. Together they leak: links expire, the wrong version gets sent, and nobody answers 'where are we' without you.
A portal collapses that into three jobs clients keep emailing you about.
- Status. The client sees the current stage without asking, so the 'any update?' email stops arriving.
- Documents. Upload and download in one versioned place behind a login, so the right file is the only file.
- Action. The one thing they keep asking you to do: approve a draft, sign off a stage, or submit the next piece of information.
Most teams cross this line without noticing. If shared folders and a status spreadsheet have started costing you billable hours, that is the moment to scope a build. webvise builds custom client portals on a stack designed to stay cheap to own, and the discovery call scopes the v1 before any code gets written.
When a Custom Portal Beats Another SaaS Login
Plenty of client-portal SaaS exists. HubSpot has portals, SuiteDash and Copilot sell client-portal products, and Notion or Google Sites can fake one. Buy one of those when your client interaction is generic: share a doc, collect a file, show an invoice.
Build a custom portal when the workflow is the product. If the steps a client moves through are specific to how you deliver, a generic tool only models them with a workaround, and the workaround is the thing clients feel every time they log in.
This is the build-versus-buy call applied to one tool. The full build-vs-buy framework covers the general version. Here is the call by situation.
| Your situation | Cheapest fit | Why |
|---|---|---|
| Share files and show invoices, nothing custom | Buy a client-portal SaaS or use HubSpot | Generic need, generic tool, lowest cost to start |
| A fixed multi-step process clients move through | Build a custom portal | The steps are your business, and a generic tool forces a compromise clients notice |
| A few clients, low volume, occasional files | Do nothing yet, tighten your Drive and email | A build will not pay back at this volume |
| You re-key the same data into two systems | Build, and connect the systems with an API | The portal removes the double entry, which is where the hours go |
What to Build First: the v1 That Pays Back
The fastest way to waste a portal budget is to ship a platform. The version that pays back is small and opinionated, scoped to one workflow you run every week.
Build one object and the loop around it. For an agency that object is a project, for a lender it is an application, for a clinic it is a case. Give it a login, a status, a place for documents, and a notification when the status changes. That is the whole v1.
- Authentication and roles. The client sees only their data, your team sees everything. This is the part that has to be right.
- One object with a status timeline. The client watches it move through stages without sending a single email.
- Document upload and download. Versioned, behind the login, with an audit trail of who did what and when.
- Email notifications. A status change sends one email, so nobody logs in to discover that nothing changed.
The features that feel essential in a kickoff meeting are usually the ones to defer. Here is what to leave for later, and why waiting costs you nothing.
| Tempting in v1 | Ship it in | Why wait |
|---|---|---|
| In-portal chat | v2 or never | Email already works, and chat adds moderation and notification load |
| Client billing and payments | v2 | Payments sit outside the v1 status loop, and Stripe bolts on once clients log in |
| A native mobile app | Maybe never | A fast responsive web portal covers around 95% of client use |
| SSO and enterprise permissions | When an enterprise client asks | No payoff until someone actually requires it |
The Stack That Keeps a Portal Cheap to Own
A portal lives for years, so the build cost is smaller than the cost of owning it. The stack decides that second number, and a portal built on glue gets expensive the first time something breaks.
The portals we build run on Next.js and React, so frontend and backend share one codebase. tRPC gives type-safe APIs, which means a renamed field breaks the build instead of production. PostgreSQL with Drizzle holds the data, and Better Auth handles login and roles. Stripe covers payments when billing arrives, Resend sends the notifications, and the whole thing deploys to Vercel straight from a commit.
Two numbers matter for a client tool. It should load in under 1.2 seconds on a normal connection and score above 90 on Lighthouse, because a slow tool gets abandoned and people email you again. We hold builds to that standard and hand over a performance report measured on the live system.
When It Pays Back, and When It Does Not
A first client portal runs roughly €20,000 to €50,000, the same band as the customer-portal tier in our custom web application cost guide. The payback is operational.
Count the hours your team spends each week answering 'any update?', re-sending files, and re-keying data between systems. A portal removes most of that, and it removes the dropped handoff that quietly costs you a client. When those hours are real, a portal in this band pays back inside a year.
It does not pay back at low volume. With a handful of clients and the odd file, a tidy shared drive and a clear email template beat a custom build. The signs you have outgrown that setup are operational, and they show up in your numbers before they show up in a meeting.
If client updates are still living in your inbox, name the one object and three jobs your portal would cover, then scope the v1 against the volume you actually have. webvise builds custom client portals on the stack above and scopes that v1 on a short discovery call. Start one at webvise.