How to Build a Legal Client Portal: Step-by-Step

A client portal is a deceptively simple product. The visible part — a login, a status page, a list of documents — takes a competent developer a few weeks. The part that determines whether the firm can safely put privileged material behind it takes considerably longer and is where most builds go wrong.

This guide is the build itself: requirements, architecture, the decisions that matter, the testing that is not optional, and a realistic timeline. If you are still deciding whether your firm needs a portal at all, that question is answered separately in the guide to client portals for Nigerian law firms.

Decide what version one contains

The most important build decision is what to leave out. A focused first version delivers value in weeks; an ambitious one delivers a demonstration in months.

Version one should contain: client login, a list of that client's matters, the current stage with a plain-language description and the date it changed, a stage history, documents issued by the firm, secure upload of documents the client has been asked for, an outstanding-items list, and the name and contact details of the responsible lawyer.

Version two candidates: invoices and payment, secure messaging, appointment booking, multiple contacts per corporate client, and reporting for clients with many matters.

Version three or never: e-signature inside the portal, live document collaboration, mobile applications, and client-facing dashboards.

Write this split down and hold it. Scope expansion is the main cause of overruns on portal builds.

Step 1: Map the matter stages clients will see

Before any technical work, the firm must define, per practice area, the stages a client will be shown. This is legal work, not development work, and it cannot be delegated to the developer.

For each practice area, produce a table with four columns: the internal stage name, the client-facing label, a one-sentence plain-language explanation, and what the client typically needs to do at that point.

An illustrative conveyancing sequence: instructions received; searches commenced; search results received; contract or deed drafted; executed by parties; consent and stamping in progress; registration submitted; documents released to client.

Three rules:

• Six to nine stages per practice area. Fewer conveys nothing; more creates maintenance work and confusion.
• Never show internal states. "Awaiting counsel's opinion on merits" is an internal note; "Under legal review" is a client-facing stage.
• Avoid predictions in stage descriptions. Describing what is happening is factual. Stating when it will finish is a promise the client will rely on.

Get partner sign-off on the stage tables before development begins. Changing them later means changing data, interface and content at once.

Step 2: Write a prioritised requirements list

Agree this list in writing with the developer. It is the scope, and anything added later is a change with a cost.

Step 3: Choose the technical approach

Indicative 2026 ranges; actual quotations vary with scope, vendor and exchange rate.

For most Nigerian firms, a custom web application on a mainstream stack is the sensible choice. It should be a server-rendered application rather than a heavy single-page application: it loads faster on mobile data, is simpler to secure, and is easier for another developer to maintain later.

Practical technology guidance: a mainstream framework your developer knows well, a relational database, object storage for documents, and a cloud or VPS host. Avoid unusual technology choices; a portal will outlive the relationship with whoever built it.

Step 4: Build the six components that matter

Authentication

Individual accounts created by the firm when a matter opens, never self-registration. Email or phone as the identifier, a strong password policy, secure password reset with expiring tokens, session timeout, and rate limiting on login attempts. Two-factor authentication is mandatory for firm-side users and should be available to clients. A one-time code by SMS is more practical for Nigerian individual clients than an authenticator application.

Access control and data separation

This is the component that must be correct. Every request for a matter, a document or an upload must verify, on the server, that the requesting user is entitled to that specific record. Never rely on the interface simply not showing a link.

Practical rules: authorise on the server for every single request; use non-sequential identifiers so record numbers cannot be guessed; scope every database query by the authenticated client; and implement role-based permissions on the firm side so staff see only their matters. Write automated tests that attempt cross-client access and assert failure.

Document storage and uploads

Store documents in object storage rather than in the database or the web root. Serve them through short-lived signed links generated after an authorisation check, so a copied link expires.

Uploads need: file type restrictions, a size limit sized for phone photographs, malware scanning, immediate on-screen confirmation, and a record linking the file to the matter and the request it satisfies. Accept common image formats gracefully — most Nigerian clients will photograph documents rather than scan them — and consider converting images to text so the firm can search them later.

The outstanding-items list

Underestimated and cheap to build. Each item has a description, who it is for, status, and a date. When a client uploads a file against an item, it moves to "supplied, under review". This single feature does more to accelerate matters than any other part of the portal.

Notifications

Nigerian individual clients do not reliably check email. Build notification around SMS, with WhatsApp where the firm uses the WhatsApp Business Platform, and email as a secondary channel. Keep messages short, include a direct link, and never put confidential detail into a notification. Allow clients to set their preferred channel, and record delivery for your own records.

Audit logging

Log every authentication, view, download, upload and permission change, with user, timestamp and record. This serves professional obligations, supports data protection accountability, and is invaluable when a client asks whether a document was ever provided. Make the log immutable from the application and retain it according to a written policy.

Step 5: Connect it to where matter status actually lives

A portal is only as good as its data source, and the integration decision shapes the whole project.

Option A: the portal is the system of record. The firm updates stages directly in the portal. Simplest and cheapest, appropriate where the firm has no matter management system. Risk: staff must remember to update it.

Option B: the portal reads from an existing system. Matter status lives in practice management software and the portal mirrors it. Better, because there is no duplicate entry. Requires the existing system to expose an API or a reliable export.

Option C: two-way synchronisation. Uploads and messages flow back into the matter file automatically. Best experience, highest cost and complexity; treat it as a second-phase project.

Choose A or B for version one. Whatever you choose, nobody should have to enter matter status twice, because the second entry is the one that will be skipped.

Step 6: Add invoices and payments

If invoices are in scope, keep the portal read-only for financial data: show invoice number, date, amount, status and a downloadable copy, drawn from the firm's accounting system.

For payment, integrate a Nigerian payment provider supporting cards, bank transfer and dedicated virtual accounts. A per-client or per-invoice virtual account number allows transfers to reconcile automatically, which removes the manual matching of bank statements that consumes accounts staff time.

Two cautions. First, client money and firm money must remain separate in line with professional and accounting requirements; take advice on how payments are routed. Second, never store card details in your own system; the payment provider handles that.

Step 7: Test properly before launch

Security testing is not optional for a system holding privileged material.

Access control tests (all must fail to grant access):

• Change a matter identifier in the address bar to another client's matter
• Request a document identifier belonging to another client
• Reuse an expired or already-used signed document link
• Access a matter after the client's account has been deactivated
• Upload a file against another client's outstanding item
• Call an application endpoint directly without an active session
• Use a firm-side account from a different practice group to view a restricted matter

Additional technical tests:

• Password reset tokens expire and cannot be reused
• Rate limiting blocks repeated failed logins
• File type and size validation rejects disallowed uploads
• HTTPS enforced everywhere, with a valid certificate
• Backups restore successfully into a clean environment
• Audit log records every view, download and upload

User acceptance tests with real people:

• A partner updates a stage and the client sees it within a minute
• A client on a mid-range Android phone on mobile data can log in, view a stage and upload a photograph in under three minutes
• Password reset works without staff assistance
• Notifications arrive on the chosen channel
• A support staff member can create a client account unaided

Timeline, team and indicative cost

A version-one portal is realistically eight to sixteen weeks from stage mapping to pilot. Indicative cost is ₦800,000 to ₦4,000,000 depending on scope, rising where integration with an existing system is required. Recurring costs include hosting of ₦150,000 to ₦800,000 or more per year, document storage that grows with use, notification charges per message, and maintenance of ₦20,000 to ₦150,000 per month.

Budget separately for an independent security review. It is a small proportion of the build cost and the most valuable line item in a system holding privileged material.

Example (hypothetical): a twelve-week build

Illustrative scenario, not a Linestech client result.

A firm with immigration and conveyancing practices wants a portal. Weeks one to three are spent by two partners defining eight conveyancing stages and seven immigration stages, with plain-language descriptions and the client action at each point. The requirements list is fixed at thirteen "must" items.

Weeks four to nine build the application: authentication with SMS one-time codes for clients, per-matter access checks on every request, a matter list, stage history, a document area using signed links, uploads accepting photographs with a ten-megabyte limit, and the outstanding-items list.

Weeks ten and eleven cover notifications by SMS, an audit log, and access control testing including deliberate attempts at cross-client access. Week twelve runs a pilot with eight clients across both practices.

The two things that consume unplanned time in a build like this are almost always the same: agreeing the stage descriptions, because partners disagree about what clients should be told, and handling poor-quality photographed documents. Plan for both.

Launch and rollout

1. Pilot with five to ten clients. Mixed: one corporate, several individuals, at least one client who is not technically confident.
2. Fix what the pilot reveals. Usually login friction and stage descriptions, rarely anything technical.
3. Write the internal procedure. Who creates accounts, who updates stages, how quickly, and who handles client login problems.
4. Add portal introduction to matter opening. The account is created and demonstrated when the client signs the engagement letter, after a short staff training session.
5. Roll out to new matters first, then offer it to existing clients.
6. Monitor logins weekly for two months. Low usage means a process problem, not a software problem.
7. Review the audit log monthly for unexpected access patterns.

What changes when you build this in Nigeria

Assume mobile, assume metered data. Test on a mid-range Android phone on a normal connection. Keep pages light and avoid automatic large downloads.

Assume photographed documents. Uploads must accept images, handle large photographs, and ideally convert them to searchable text.

Notify by SMS or WhatsApp, not email. Email is a secondary channel only for individual clients.

Plan for identity verification. Firms handling property, corporate and financial matters collect identity documents; the portal is a far safer place for these than a messaging app, provided access control is right.

Price recurring costs in naira carefully. Object storage, SMS and any dollar-denominated services accumulate. Model them at a conservative exchange rate.

Apply the [Nigeria Data Protection Act 2023 from t](https://ndpc.gov.ng/)he design stage. Lawful basis, retention periods, access rights, your position as controller and your vendors' position as processors. Retrofitting compliance costs more than building it in.

Mistakes to avoid

Relying on the interface to hide data. If the server does not check authorisation on every request, the portal is insecure regardless of what the pages display.

Sequential record identifiers. Predictable numbers invite enumeration. Use non-guessable identifiers.

Serving documents from a public path. Anything reachable without an authorisation check is effectively public. Use signed, expiring links.

Building messaging nobody monitors. An unanswered message thread damages the client relationship more than having no thread at all.

Requiring double data entry. If staff must update both the matter system and the portal, the portal will go stale within a month.

Skipping the security review. The one cost saving that can end a client relationship and create a professional complaint.

Launching to the whole client base at once. Pilot first. The problems you find will be about wording and login, and they are cheap to fix at ten clients and expensive at two hundred.

Forgetting deactivation. Closed matters, departed staff and changed corporate contacts all need a defined revocation process.

Conclusion

Building a legal client portal is a manageable project if you resist the temptation to build everything. Define the client-facing stages with partner sign-off, fix a short "must" list, choose a mainstream technical approach, and put your effort into access control, document handling and the outstanding-items list.

Test cross-client access deliberately, commission an independent security review, and pilot with a handful of clients before rolling out. Make sure nobody has to enter matter status twice, notify clients on SMS or WhatsApp rather than email, and give the firm a named owner for the process after launch. A focused portal delivered in twelve weeks will serve the firm better than an ambitious one still in development after nine months.

If your firm wants a secure client portal built and connected to how your matters actually progress, Linestech develops web applications and portals for Nigerian professional firms, including access control design, document handling and payment integration. Talk to us about the stages you want your clients to see.

Frequently asked questions

How long does it take to build a legal client portal?

Eight to sixteen weeks for a focused version one, from stage mapping to pilot. Integration with an existing matter management system adds two to four weeks. The firm's own decisions about client-facing stage descriptions are usually the slowest part, not the development.

Can we add a portal to our existing law firm website?

Yes, if the site runs on a platform that supports authenticated areas and the firm's needs are simple. For anything involving privileged documents and strict access control, a separate custom application linked from the website is usually safer and easier to maintain, even though the client experiences it as part of the same site.

What technology should a legal client portal be built with?

A mainstream server-rendered web framework your developer knows well, a relational database, object storage for documents, and a reputable cloud or VPS host. Avoid unusual stacks. The portal will outlive the relationship with whoever builds it, and the next developer must be able to maintain it.

How do we make sure one client cannot see another client's files?

Authorise every request on the server against the authenticated user, scope all database queries by client, use non-sequential identifiers, serve documents through short-lived signed links, and write automated tests that attempt cross-client access and assert failure. Then have an independent reviewer try to break it before launch.

Should clients be able to message us through the portal?

Only if the firm commits to monitoring and answering it. An unmonitored message feature is worse than none. Many firms launch without messaging, keep WhatsApp for conversation, and add portal messaging later once matter statuses are reliable and someone owns the inbox.

How do we handle clients who cannot use the portal?

Keep the existing route open for them. Some clients will always prefer a phone call or a visit, and a portal should reduce your workload rather than exclude anyone. Measure adoption, support the clients who struggle, and never make portal use a condition of service.

Can the portal handle electronic signatures?

Technically yes, but confirm first which instruments can validly be executed electronically under Nigerian law, and whether additional formalities such as attestation, stamping or registration apply regardless. Treat e-signature as a later phase, with that legal analysis completed before any development.

Who should own and maintain the portal after launch?

A named person inside the firm owns the process — account creation, stage updates, client support — while a developer or agency holds a maintenance retainer for security updates, backups and changes. Ensure the firm controls the hosting account, the domain and the source code.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Act 2023 — NDPC
• WhatsApp Business Platform — Meta for Developers
• PostgreSQL documentation
• OWASP Top 10