How to Build a Law Firm Client Portal: A Step-by-Step Technical Guide
The technical architecture of a law firm client portal on Bubble.io: the data model, the user roles, the document access control, the messaging system, and the billing integration. Everything a legal tech founder or a law firm principal needs to understand before commissioning a build.
The Foundation of a Correctly Built Portal
A law firm client portal built on Bubble.io is a multi-tenant application where each law firm is a tenant with its own clients, matters, documents, and invoices, fully isolated from every other firm’s data. The data architecture has four layers: the firm layer (the Account data type, representing the law firm); the user layer (the User data type, with a role of Client, Fee Earner, or Admin, and a Membership data type linking each user to a specific firm); the matter layer (the Matter data type, representing a specific client engagement, with relationships to the client, the responsible fee earner, the practice area, and all associated records); and the record layer (the data types for each category of record associated with a matter: Document, Message, Invoice, Appointment, and Activity).
What to Build in the Database
Matter
Fields: matter reference number (auto-generated), title (e.g. ‘Smith v Jones — Employment Tribunal’), practice area (option set: Employment, Conveyancing, Family, Immigration, Commercial, Other), status (text: Instruction Received, Documents Requested, Investigation, Advice Provided, Proceedings Issued, Settlement Negotiations, Concluded), status_updated_at (date), client (relationship to User), responsible_fee_earner (relationship to User), supervising_partner (relationship to User), opened_date (date), estimated_completion (date), billing_type (option set: Fixed Fee, Hourly, Conditional Fee), estimated_fee (number), and notes (text).
Document
Fields: matter (relationship to Matter), title (text), document_type (option set: Correspondence, Court Filing, Evidence, Contract, Client ID, Financial, Internal Note, Client Upload), file_url (file), uploaded_by (relationship to User), uploaded_at (date), direction (option set: Firm to Client, Client to Firm, Internal), status (option set: Uploaded, Awaiting Review, Reviewed, Approved, Signed), visible_to_client (boolean — defaults to false; fee earner must explicitly set to true before the document appears in the client portal).
Message
Fields: matter (relationship to Matter), sender (relationship to User), sent_at (date), body (text), read_by_client (boolean), read_by_firm (boolean). Messages are always bidirectional within a matter thread; there is no separate inbox — all messages for a matter appear in the matter’s message thread in chronological order.
Invoice
Fields: matter (relationship to Matter), client (relationship to User), invoice_number (auto-generated), issue_date (date), due_date (date), line_items (a related LineItem data type with fields: description, quantity/hours, rate, amount), subtotal (number), vat_amount (number), total (number), status (option set: Draft, Sent, Partially Paid, Paid, Overdue, Written Off), stripe_payment_intent_id (text), and paid_at (date).
Appointment
Fields: matter (relationship to Matter), client (relationship to User), fee_earner (relationship to User), appointment_type (option set: Initial Consultation, Progress Meeting, Signing Appointment, Court Hearing, Telephone Call), date (date), start_time (text), duration_minutes (number), location (text), notes (text), status (option set: Scheduled, Confirmed, Completed, Cancelled).
🔗 Related reading on sasolutionspk.com
Bubble.io Database Design: The Complete Guide for Founders in 2026
The foundational data model principles that underpin a correctly structured legal client portal — including multi-tenancy, privacy rules, and role-based access design.
Bubble.io Stripe Integration: The Complete Guide for SaaS Founders
The Stripe integration that powers online invoice payment in the legal client portal — including the payment flow, webhook handlers, and invoice status update workflows.
Non-Negotiable Security Settings
Client sees only their own matters
The Matter data type privacy rule: ‘This Matter is visible to a user when that user is the Matter’s client OR that user is a member of the Matter’s firm with the role Fee Earner or Admin.’ A client logged in to the portal can only see and search the matters where they are the client; they cannot access other clients’ matters even if they know the matter reference number.
Documents visible to client only when explicitly shared
The Document data type privacy rule: ‘This Document is visible to a user who is the Matter’s client ONLY when visible_to_client is true.’ Internal notes, draft documents, and correspondence between firm staff are never visible to the client regardless of whether the client knows the document URL. Fee earners must explicitly set visible_to_client to true before a document appears in the client portal.
Cross-firm data isolation
The Account-level privacy rule: ‘All data types (Matter, Document, Message, Invoice, Appointment) are only visible to users whose Membership record links them to the same Account (firm) as the record.’ A fee earner at Firm A cannot see any data belonging to Firm B, regardless of the URL or ID they attempt to access.
Q: How do I handle the case where a client has multiple matters with the same firm?
The data model described in this post supports multiple matters per client natively: a client (User) can be related to multiple Matter records. The client portal’s matter list page shows all matters where the current user is the client, sorted by most recently updated. The client clicks on any matter to open the matter detail page, which shows the status, documents, messages, invoices, and appointments for that specific matter. There is no limit to the number of matters a client can have with the same firm.
Q: Can the portal send automated email notifications when a fee earner updates the matter status?
Yes — via a triggered backend workflow in Bubble.io. When the Matter’s status field is updated (which triggers the Bubble.io ‘a thing’s field value is changed’ workflow trigger), the workflow sends an email to the client (via the API Connector to Postmark or Loops) with the new status and a link to the portal. The email is sent only when the status is updated to a value that the firm has configured as a client-notifiable status (excluding internal status changes that the client should not be informed of). This automation replaces the manual process of calling or emailing the client every time a significant development occurs.
Q: How long does SA take to build a law firm client portal?
A core client portal with the five data types described in this post, three user roles, document sharing with visibility control, client messaging, invoice viewing and Stripe payment, and a matter status dashboard typically takes 6-9 weeks with SA and costs $15,000-25,000. The Discovery Sprint ($345, credited toward the build) produces the exact specification and a fixed build quote before the build begins.
Ready to Build Your MVP?
SA Solutions builds MVPs in weeks using Bubble.io. Start with a free audit or scope your build in 48 hours with a Discovery Sprint.
