Custom Client Portal: Build These 3 Core Screens First

I'd build a custom client portal only if it removes a specific piece of work: chasing approvals, resending files, answering status emails, or finding invoice links. If another subscription already handles those jobs without duplicate entry, I'd keep it.

For a service business, I'd start with three client screens—not a replacement for the entire business. A multi-feature portal with integrations and user roles fits my $5,000–$15,000 medium-build range, delivered in 2–4 weeks, provided the scope fits that band.

The decision isn't whether you want your logo on a login page. It's whether clients can get the answer or complete the action without pulling someone on your team away from paid work.

The first version needs three client screens, not another CRM

Here's how I'd scope a custom client portal for a service business sharing files, approvals, project status, and billing links.

1. Project status and the next action

I'd show the current stage, the next milestone, who's responsible, and anything waiting on the client. One clear answer to “Where are we?”

I wouldn't expose your entire internal task board. Internal notes, staffing problems, draft estimates, and unfinished work don't belong in the client view just because they're in the same project record.

The minimum useful screen answers:

• What's happening now?
• What do I need to do?
• What happens after I do it?

2. Files and approvals

I'd give each project a file area with a clear distinction between reference material, work awaiting approval, and approved versions.

An approval should record who approved which version and when. “Looks good” in an email thread isn't a dependable approval record if someone later replaces the attachment.

My minimum scope includes uploads, downloads, approval requests, approve-or-request-changes actions, and a history. I'd skip live chat and collaborative document editing unless they're the actual reason for the build.

3. Billing links and invoice status

I'd link clients to the payment experience you already use. If you collect through Stripe, the portal can send the client to the appropriate hosted payment or invoice page rather than collecting card details itself.

I'd leave accounting in QuickBooks or Xero. A portal can display an invoice reference and billing link without becoming a general ledger.

For version one, I'd accept an authorized staff member attaching the right billing link. Automatic invoice syncing earns its place only if the manual step creates enough work or errors to justify the integration.

There's also a small staff-side control area: invite clients, assign projects, update status, upload files, and request approval. Three client screens still need somewhere for your team to run them.

A portal won't fix a workflow that nobody owns

The mechanism behind disappointing portals is usually duplicate work. Someone updates the internal system, copies the update into the portal, and then emails the client because nobody trusts the portal to be current.

That's another subscription attached to the same problem.

I built an automated SEO blog platform that runs from keyword research through publication. Claude writes drafts against a custom voice profile; Grok, Gemini, and ChatGPT review them, and agreement from any two reviewers triggers revisions. Publishing can happen immediately or on a schedule, and Zapier pushes posts to Facebook and the Google Business profile.

The result is a publishing pipeline that runs without a content team behind it. It also includes its own analytics. I don't have a build price or measured labor savings to attach to that project, so I won't invent a payback period.

It's not a client-portal case study. The useful connection is the workflow: generation, review, revision, publication, and distribution belong to one defined process instead of becoming disconnected jobs for someone to coordinate.

I'd apply that same test to a custom client portal. Uploading a file should create the appropriate next action. Approval should move the work forward. A status change should have a clear owner—not depend on someone remembering to update three places.

If the underlying CRM is the real problem, I'd settle whether to build or buy that core system before putting a client-facing layer over it.

My go/no-go checklist before replacing the subscription

Before I quote a custom client portal, I'd want concrete answers to these checks. A vague “our current software is frustrating” isn't enough to scope a replacement.

• Repeated client requests: Can you identify the status questions, file requests, or approval reminders your team handles repeatedly?
• A source of truth: Does each field have an owner—your project system, accounting software, or the portal itself?
• A workable exit: Can you export client records and files from the current subscription?
• Permission to connect: Does the existing system offer the API access your plan needs, or a practical export process?
• Stable approval rules: Can you describe who approves what without redesigning the process during development?
• A staff owner: Who keeps status accurate and handles failed syncs or client access requests?
• A replacement target: Which subscription or manual step actually disappears after launch?

That last check matters most for the money. If you keep every subscription and add hosting, maintenance, and a new interface, you haven't cut the software bill. You might still save staff time, but that's a different argument.

Don't hire me for a custom client portal if an inexpensive subscription already covers your workflow, your current platform blocks the access we need, or you want a permanently embedded developer rather than a fixed-scope build. Those aren't small objections to work around after signing.

I'd also pause if nobody can agree on what “approved” means. Software makes a rule repeatable; it doesn't settle a business disagreement.

The wider decision behind this checklist is owning your software instead of renting it. I care less about owning another application than owning the part of your workflow that keeps getting taxed or constrained.

Renting, extending, or building: which cost actually goes away?

I'd compare three paths before choosing a custom client portal. The best one depends on what you're escaping.

For a real subscription reference, Assembly's 2026 client-portal guide lists a starting price of $39/month, billed annually. I'd verify the current plan's user limits, storage, and required features before treating that as your complete bill.

At that starting rate, the subscription arithmetic is $39 × 36 months = $1,404 over three years, assuming the price and plan don't change. A custom build doesn't beat that on subscription savings alone.

Here's my published build pricing—not an industry average:

I'd usually scope the three-screen portal described here in the medium band. Complicated client hierarchies, unusual approval chains, or difficult integrations can move it into advanced territory. A genuinely narrower application may fit the simple band.

I wouldn't add AI to this minimum scope. Files, approvals, status, and invoice links don't need it. Where AI features are justified, my estimator applies a 1.25 multiplier; the overall published envelope is $2,500–$25,000.

For broader budgeting, I break down which scope choices move a fixed-price estimate. A screen count alone won't tell you whether an integration needs a few straightforward calls or a reconciliation process.

Illustrative payback only: assume a $10,000 build and $500 per month in net avoidable expense after hosting and maintenance. That's 20 months to recover the build cost. Over 36 months, the assumed net savings total $18,000 before subtracting the build, leaving $8,000.

Those are assumptions, not a project result or a savings promise. I'd separate canceled subscriptions from staff capacity: hours freed up are useful, but they aren't automatically cash back in the bank.

Client A must never get Client B's files

Access boundaries aren't a finishing touch on a custom client portal. They're part of its foundation.

I'd define a client organization, the people who belong to it, the projects it can access, and the actions each person can take. An invited reviewer might approve a deliverable without seeing billing. A billing contact might see invoice links without seeing working files.

I'd require the server to check those permissions on every relevant request. Hiding a button in React isn't access control; someone can request the underlying record directly.

My access checklist includes:

• Organization isolation: Changing a project or file identifier must not reveal another client's records.
• Private files: I'd require private storage and authorized downloads. If I use signed download URLs, they're short-lived and issued only after a permission check—not a workaround for a public bucket.
• Approval authority: Only designated people can approve, and the approved version stays identifiable.
• Staff permissions: Staff access follows an explicit role rather than everyone automatically becoming an administrator.
• Revocation: Removing a client user ends their access, including the relevant active sessions.
• Audit history: Invitations, approvals, and access changes leave a usable record.

For a Next.js application backed by Postgres, I'd enforce authorization in the application and use database-level restrictions where appropriate. I'd test the boundaries with separate client accounts, not just the administrator login.

Notifications need the same care. An email can say there's a file awaiting review and link to the protected portal. It doesn't need to attach confidential material or reveal project details to a forwarded address.

Owning the code doesn't make an application automatically secure. Nor does buying a platform mean your specific configuration or workflow is SOC 2 compliant. I'd ask what controls are actually implemented and tested.

Move active projects first, then retire the old portal

I'd migrate a custom client portal in stages. Moving every historical attachment before anyone can use the new system is an easy way to spend the budget on archives.

My default sequence looks like this:

1. Inventory the export. Identify clients, contacts, active projects, files, approval records, and invoice references. Check what the old tool actually lets you retrieve.
2. Map ownership. Match every project and file to the right client organization. Resolve duplicate contacts before sending invitations.
3. Import active work first. Bring across the records needed to complete current projects. Preserve older history in an accessible archive when that meets the business's retention needs.
4. Test in a staging environment. Verify file counts, sample downloads, approval history, billing links, and cross-client restrictions.
5. Pilot before switching everyone. Use a limited group to complete real portal actions while the old system remains available.
6. Cut over deliberately. Establish where new updates belong, handle changes made during migration, and confirm the rollback path before ending the subscription.

I wouldn't migrate payment credentials or recreate accounting transactions just to populate a dashboard. The custom client portal needs the right references and links—not a second financial system pretending to be authoritative.

Integration scope needs a failure plan, too. If a webhook arrives twice, it shouldn't create duplicate records. If an API hits its rate limit, the portal should queue or retry the work rather than silently dropping the update.

For a small first release, a controlled manual update may be the better trade. I'd rather ship an honest status field your team owns than an unreliable “live” sync.

The portal isn't handed off until someone can run it

My delivery window is measured in weeks, but your involvement still matters. I'd plan around a scoping call, a short weekly review, and a final test pass. You'll also need to supply access, representative files, and a person who can settle workflow questions.

I'd agree on that involvement before quoting. Migration cleanup or a missing API permission shouldn't appear as surprise homework halfway through the build.

For the agreed scope, fixed price means overruns are my problem, not yours. New requests get a separate scope decision; they don't quietly turn into an open-ended hourly invoice.

The code lives in your own repo from day one. You own the custom source code throughout the build, and another developer can take over without negotiating a release fee. I'd keep hosting, service accounts, and data under your control; third-party services and dependencies still have their own terms, licenses, and bills. That's the opposite of vendor lock-in dressed up as managed service.

I'd put these items in the handoff scope:

• Source control, deployment instructions, and environment configuration.
• Hosting and service accounts under your control.
• Backup and restore procedures, plus a documented data export path.
• Permission rules and the tests used to check them.
• Instructions for invitations, failed integrations, and routine administration.
• Clear responsibility for monitoring, dependency updates, and ongoing support.

Maintenance isn't free because the code is yours. Hosting, file storage, email delivery, updates, and occasional API changes remain operating costs. I'd identify those separately from the build instead of pretending a launch invoice buys permanent upkeep.

I distrust calculators that hide the price to harvest an email, just as I distrust paid discovery that takes months to produce a slide deck. My free project estimator shows the range on screen before it asks who you are.

This week, list the three client screens that would remove the most back-and-forth, then put that list through free project estimator. It's the ninety-second way to price the smallest useful portal: range first, form second, with a fixed quote back inside a business day after submission.