For most of the profession's history, a law firm delivered advice, documents and judgment through people. Now some firms are building software their clients use directly. It might be a tool that answers questions about a client's own portfolio of agreements, a tracker for obligations across a client's deals, or an assistant grounded in the firm's guidance on a regulated area. The clients asking for these tools are often the firm's largest, and they're asking because their own AI programs need the firm's knowledge inside them.
I've been in the rooms where these decisions get made. Building the software is manageable. What surprises firms is that, for that one product, they've become a software company, with obligations most firms have never carried. Four decisions shape everything that follows, and each is easier to make before a client is using the product than after.
Decide the deployment model before the first client asks
The first client will ask where their data lives and who else is on the system. Have the answer ready. There are two basic models. In a shared deployment, clients use one system, and separation between them is enforced in the data and the permissions. In a dedicated deployment, each client gets its own instance, often in its own cloud environment, and separation comes from the infrastructure itself.
A shared deployment costs less to run, and every fix reaches every client at once. A dedicated deployment is easier to explain to a demanding client's security team, and your largest clients may insist on one. Many firms will end up offering both: a shared version for most clients and dedicated instances for the few that require them. I covered the security side of this choice in where legal AI runs.
The deployment you offer clients doesn't have to match how the firm runs its own internal systems. Treat it as a product decision, make it with IT in the room, and write it down before the first contract goes out.
Price the first versions as a collaboration
The first clients who use a firm-built product are shaping it. Their feedback is worth more to the firm than the fee. I'd price early versions near cost, say so openly, and ask for real engagement in return: named users, regular feedback sessions, and agreement that what the firm learns about the product itself can improve it for other clients, with the client's own data kept out of it.
Charge something anyway, even to the largest clients. A client that pays for a pilot tends to assign people to use it and to tell you what's wrong with it. The price can rise once the product is proven and the client depends on it.
Work out who carries the risk
Is the product's output legal advice? A great deal depends on the answer. If it is, the firm's professional obligations and its malpractice coverage attach to what the software says, and the engagement terms need to say which matters it covers and which lawyers stand behind it. If it isn't, the terms need to say that just as clearly, and the product has to be designed so a client can't mistake its output for advice.
Bring the general counsel and the firm's insurer in early. Ask the insurer directly whether the current policy covers a client-facing software product. Many firms will find the honest answer is that nobody has looked yet.
Ownership needs the same care. When a firm builds a product with a client's input, the contract should say who owns the software, who owns the client's data, and what the firm may reuse. The firm will want to reuse its methods and its own knowledge. The client will want its data, and anything specific to its business, kept out of other clients' products. Both positions are reasonable, and both belong in writing.
Build the operating model before launch
Clients who use software expect what software companies provide. Someone answers when it breaks. Updates arrive on a known schedule and don't break what the client depends on. Security questionnaires get answered, and incidents get reported within agreed windows.
Most firms already run these disciplines inside IT for internal systems. A client product needs them facing outward: a named product owner, a support path the client can reach, a change process, and service commitments the firm can actually meet. The engineers who built the product can't also be its support desk indefinitely, and the partner who sponsored it shouldn't be the person the client calls at midnight.
Keep every client's knowledge separate, and test it
A firm-built product draws on the firm's knowledge, and the firm's knowledge includes every client's matters. The product built for one client must never surface another client's documents, including indirectly through a summary or a suggested answer. That separation has to hold where the data is stored, with every record tied to the client and matter it belongs to. It has to hold again when a question is asked, with ethical walls and permissions checked before anything comes back.
Test it on purpose. Before launch, have someone try to get the product to reveal information belonging to a different client. Keep that test in the release checklist for every version that follows.
Put the economics in front of the partners
A client product changes the economics of the relationship. Some questions that used to become billed hours will be answered by the software. Partners will ask whether the firm is building something that shrinks its own revenue, and the question deserves a direct answer. In my view the product is how a firm keeps work its clients would otherwise take in-house or give to another provider, and it opens conversations about work the firm couldn't reach before. The billable-hour economics are real, so bring the numbers to the partners early, with the client's commitment attached.
Reframe works on the layer underneath products like these. We build a governed model of the firm's matters, clients and documents in the firm's own cloud, with client separation enforced on every record and every request. A firm can build client-facing tools on top of it knowing each client's product sees that client's matters and nothing else, and every answer cites the document it came from.
If your firm is being asked for a client product this year, write down the deployment model, the pricing approach, the risk position and the operating model before anyone writes code. Those decisions will shape the product more than any technical choice.
Drafted with Reframe Editorial Agent, an AI employee at Reframe. 