How to build a legal consultation app: request, office acceptance and in-app chat

What a legal consultation app does, and what it does not

A legal consultation app replaces the round of phone calls that usually starts a search for a lawyer. Instead of explaining the same matter to several offices, a client writes it down once, attaches the relevant papers and sends it to the offices that handle that kind of matter. The office that takes the case continues the conversation inside the app.

The app is infrastructure, not counsel. It organizes discovery, the request, the hand-off to an office and the conversation that follows. It does not assess the case, predict an outcome or tell the client what to do. That boundary is not just a legal disclaimer at the bottom of a screen; it shapes the features, the wording and who owns each step.

AlMizan, the legal consultation marketplace FLUIDS designed and built for Oman, is a clear example. It connects clients with licensed law offices: a client describes a case once, sends it to one office or several, and chats in-app with the office that accepts. AlMizan states directly that it is a marketplace, not a law firm, and that consultations are provided by the offices themselves.

How a consultation flows from request to closed chat

A consultation moves through a short, predictable sequence: the client builds a request, offices receive it, one accepts, a chat opens, and the consultation is closed and rated. In AlMizan the sequence looks like this:

1. Choose a specialization. The client picks the area of law first: commercial, labor, family, real estate, and others. Choosing the area first frames the rest of the request before any text is written.
2. Describe the matter. The client explains the request in their own words, in one place, instead of repeating it on several calls.
3. Attach documents or photos. Contracts, notices or photos of papers travel with the request, so the office sees the material it needs to judge whether it can help.
4. Select offices and review. The client sends the request to several offices at once, or directly to one office or a specific lawyer, and reviews everything before sending.
5. An office accepts. When an office takes the request, the chat opens with that office. With a request sent to several offices, the conversation opens with the first one that accepts.
6. Consult in the app. Questions, clarifications and follow-up documents stay in one thread tied to the request.
7. Close and rate. When the work is done, the consultation is closed and the client rates it.

A request does not have to start from a blank wizard. In AlMizan it can also begin from an office, lawyer or service the client is already viewing, so the next step follows where the client started. That small decision matters: a client who has already chosen an office should not have to choose it again.

The request states a consultation app needs

Every request needs a small set of explicit states, because both the client and the office have to know at a glance what is waiting on whom. AlMizan lets clients track each request as awaiting a reply, active or completed. Those three states cover most of the journey; the scope document should also decide how the edge cases behave.

The edge cases are where trust is won or lost. A client who sends a request and hears nothing needs to know whether to wait, widen the request or try another office. An office that opens a request another office already accepted needs a clear message, not an error. These rules are product decisions: the platform owner should approve acceptance and routing rules in writing before development, rather than leaving developers to improvise them in code.

What the client side and the office side each need

A consultation app is two products sharing one database: a simple client journey and a working tool for offices. Teams that design only the client screens end up with offices that cannot keep up with the requests they receive.

The client side

• Discovery. Browse office and lawyer profiles and the services they offer.
• The request wizard. Specialization, description, attachments, office selection and a review step.
• Request tracking. Every request with its current state, in one list.
• Consultations. The chat with the accepting office, then closing and rating.

The office side

• A dashboard. In AlMizan the office sees new requests, active consultations and its performance: rating, response rate and average response time.
• Office details. Lawyers, services, branches and working hours, managed in one place.
• Visibility. Whether the office appears to clients, so an office can control when it receives new requests.
• Request handling. Reviewing a request with its attachments and accepting it, which opens the consultation.

The office side is also where the marketplace earns its keep. Response rate and average response time give offices a reason to answer quickly, and they give the operator an honest signal about which offices are serving clients well. We cover routing and performance in more depth in our guide to lawyer marketplace platforms.

Where the app stops and the law office starts

The app stops at organization and communication; the office starts at advice. Writing that line into the product, not only into the terms of use, protects clients, offices and the operator.

• Wording. Buttons and empty states should say "send to offices" and "consult with the office", not "get legal advice" from the app.
• No automated answers. If the product adds any assistant, it should help the client complete the request, for example by suggesting a specialization, and never comment on the merits of a case.
• Office responsibility. Profiles, services and the consultation itself belong to the office, which answers for them.
• Onboarding. Who may join as an office, and how licences are checked, is an operating process the platform owner defines and runs.

Confidentiality deserves the same care. A consultation can contain sensitive personal and commercial information, so access to each thread should be limited to the client and the accepting office. Our article on secure client–lawyer messaging covers access, attachments and retention in detail.

What to decide before building a legal consultation app

Most of the cost and risk in a consultation app sits in decisions, not screens. Settle these before development starts, and the build becomes far more predictable:

• Market and language. Which country or countries, and whether the first release is Arabic-first with English, or both from day one.
• Routing model. Broadcast to several offices, direct to one, or both, and the exact rule for who gets the conversation.
• Specializations. The list clients choose from, and who maintains it.
• Office onboarding. How offices apply, how their licences are checked, and who can hide or suspend a profile.
• Business model. Whether offices subscribe, pay per accepted request, or the platform charges clients, and what that means for payments in the app.
• Records. How long requests, chats and attachments are kept, and who can export or delete them.

AlMizan was built as a Flutter app on Supabase, with FLUIDS responsible for product design and the mobile build, including the client journey and the office tools behind it. The same pattern carries over to other professional services where a client describes a need and a qualified provider accepts it, from clinics to engineering consultancies; our article on legal client intake looks at the request itself in more detail.

If you are planning a consultation app or a professional-services marketplace, see the AlMizan case study, read how we approach marketplace platform development, or start with the mobile app MVP guide. Scope, price and timeline are agreed in a written proposal before development.