By Content Team

Legal App Features Law Firms Need Before They Buy or Build

A legal mobile app is worth buying or building when it enforces matter access, captures time into the system of record, controls documents and client messages, and gives IT an audit trail and a same-day way to revoke access. Store ratings and “top app” roundups do not answer that. Require the features below as acceptance tests. If a product cannot demonstrate them with your identity provider and your matter list, it is not a fit, however polished the screen looks.

Hexagon IT Solutions uses this as a buyer and IT checklist for firms that are choosing a product or commissioning a build. This article does not rank apps, vendors, or firms.

Which features should be non-negotiable?

Answer: Require five, and treat anything else as optional until these work. The five are firm identity on the device, matter-level authorization including ethical walls, time and expense that post to the practice system, document access with a written offline rule, and an audit of who opened what. Client messaging belongs in the same list if lawyers currently text clients from personal phones. A chatbot, a news feed, or a generic “AI assistant” does not substitute for any of the five.

What does identity and matter access look like?

The app should sign lawyers in through the firm’s identity provider, or through an equivalent the firm administers. Shared passwords and a single office login fail the test. When someone leaves, IT must be able to revoke the session and the device trust without waiting on a vendor ticket that has no stated time.

Authorization follows the matter, not the person’s seniority. If a lawyer is walled off from a client, search, notifications, recent documents, and offline copies must all respect that wall. Ask the vendor to show a walled-off matter on a test account. A policy PDF is not a demonstration.

Admin features the firm should see before purchase:

• Role assignment that IT or the process owner can change without a developer.
• A list of enrolled devices and a revoke action.
• Logging of sign-in failures and of access to matters.
• A stated path for lost phones, including what remains readable on the device.

What work must the app write back?

Time captured only on the phone is a shadow system. The app should post entries to the practice or billing system the firm already trusts, with the matter, the timekeeper, and a status the billing team can see. The same rule applies to expenses and to tasks if you include them. Define which system owns the record, what happens when the phone is offline, and how a duplicate post is prevented.

That write-back is an integration, not a screen. Scope it the way you would any other API integration: fields, identity of the timekeeper, retries, and a queue for entries that fail. If the vendor’s connector cannot target your practice system, budget a build or drop the feature. Do not plan on lawyers retyping the day from memory.

How should documents and client messages behave?

Document features to require, in writing:

• The lawyer sees documents only for matters they may open.
• Sharing with a client or co-counsel uses a firm-controlled link or a stated channel, not a personal file app.
• Offline copies expire or can be wiped, and the firm knows which documents were saved to the device.
• The official copy stays in the document system. The phone is not a second archive.

If the app includes client messaging, keep those threads out of consumer texting. Retention, who on the matter team can read the thread, and what is stored on the handset all need an owner. A message the firm cannot produce later is a risk decision, not a convenience feature. Review both document handling and messaging under the firm’s software security requirements before pilot users install anything on personal phones.

What should you leave out of the first release?

Leave out features you cannot operate. A broad “AI research” button with no description of the sources, the matter boundary, and whether a partner must review the output is not a requirement. It is an unscoped risk. Also leave out consumer-style social features, app-store badges as acceptance criteria, and any sync that copies the full document repository onto every phone “just in case.”

Write acceptance tests instead of adjectives. Example: a departed timekeeper’s phone cannot open a matter ten minutes after IT revokes the account; a walled-off user cannot search that client’s name and see a hit; a time entry created on the subway appears once, on the correct matter, when the phone reconnects. If the test fails, the feature is not done.

How Hexagon applies this

Hexagon IT Solutions builds firm mobile apps and connects them to identity, practice, and document systems. We scope the non-negotiable features first and keep later ideas on a separate list so the first release can be administered by the firm’s own IT. If you are unsure whether to buy or build, schedule a call and bring the five tests above. The useful outcome is a feature list your risk reviewer and your IT lead will both sign.

Key takeaways

• Judge a legal app by matter access, time write-back, document control, messaging retention, and audit, not by a ranked list of products.
• Identity, ethical walls, and same-day revocation are acceptance tests, not brochure lines.
• Leave unscoped AI and full-repository sync out of the first release until the firm can operate them.