Lawyers are building more tools for themselves, some are put together AI-powered helpers, others try a bit of Streamlit or whip up a quick workflow that fixes something the wider firm never quite gets round to. It is refreshing to seem, you are closest to the pain, so you often spot opportunities the formal delivery channels miss.

All this though creates a new challenge. A personal project suddenly becomes something colleagues depend on and once that happens... oh boy do expectations rise. People want stability. Risk want to know where the data goes. IT want confidence it will not fall over the moment someone uploads the wrong file. Before long, engineering get asked (told) to "support it", even though they have never seen the code and could not run it if they tried.

This guide is not about turning lawyers into software engineers. It is about giving you the things that matter if you want your tool to have a life beyond your laptop.

Build with the firm’s world in mind, not just your laptop

Most internal tools begin life locally, because it is quick and comfortable. Problems appear when more people start using the tool and everything about it assumes your setup.

• A Streamlit app reading files from your Documents folder.
• A Flask service exposed through ngrok.
• An Excel macro that relies on a plugin only you have installed.

These are brilliant first versions, but they do not travel well. A sustainable tool needs an environment that is not tied to an individual developer.

Things to think about:

• Could someone else run this without your machine or personal settings?
• Is the tool dependant on paths, plugins or tokens that only exist locally?
• Would anyone know how to deploy it if you were offline?

Use technologies the engineering team can actually support

The freedom to build in anything is appealing. Python, Streamlit, Rust, low-code, no-code. The first version works regardless. The issue appears when the tool is useful enough to adopt properly.

If the engineering team maintain TypeScript and .NET but you deliver a Python app stitched together with niche libraries, they will struggle to support it. It is not resistance. It is capacity.

Firms standardise for good reason. Tools written outside those stacks often get stuck in limbo. Too valuable to throw away, too awkward to maintain.

Choosing something closer to what the firm already supports gives your idea a genuine roadmap.

Things to think about:

• Does your chosen stack match what engineering know today?
• Will someone else be able to patch or extend the code?
• Are you building a throwaway prototype or something that might scale?

Write down your reasoning, or the tool dies the day you move on

Every firm has at least one haunted Excel-based app built by someone who left years ago. It still powers a key workflow, nobody understands it, and everyone avoids the hidden tabs like they’re cursed.

Vibe coded tools can fall into the same trap when the logic lives entirely in your head instead of in a simple decisions file. Engineers do not mind unusual choices, they make them every day, but they do mind having no idea why something was built a certain way.

Let’s say you built a clause comparison assistant. You chose a particular library because it handled awkward edge-case formatting in your documents. Months later, someone tries to “tidy up the dependencies” and swaps it out. The whole thing unravels and no one knows why. If a section of code is brittle or relies on a specific behaviour, write that down.

You are not creating bureaucracy, you are protecting your own reasoning from future confusion.

Things to think about:

• Would someone understand the structure without speaking to you?
• Are the fragile or quirky areas called out so no one breaks them accidentally?
• If you left, would the tool still make sense?

Accessibility becomes essential once more people rely on the tool

Accessibility is easy to overlook when you are the only user. The moment your colleagues depend on the tool, it becomes unavoidable.

Tools get blocked for:

• missing labels for screen readers
• poor colour contrast
• keyboard traps
• components that do not announce changes

None of this is there to slow you down. It is compliance. It is fairness.

You do not need to solve it from scratch. A good UI framework does half the work. Something like MUI gives you accessible components by default. If you stick to those components and name things clearly, you are already ahead of most prototypes.

Things to think about:

• Can someone use this without a mouse?
• Will a screen reader understand your interface?
• Are you using a framework that handles accessibility well?

Authentication and identity decide whether a tool is viable

A simple login screen is fine for personal use. It collapses the moment a practice area want to adopt the tool. Firms expect:

• single sign on
• role-based access
• proper session handling
• auditability

If your prototype stores usernames in a text file or uses a password field you invented yourself, it will fail any risk review.

Modern frameworks make this easier than people think. If you tell your coding assistant “this must use OAuth2 or OpenID Connect with Azure AD,” it will scaffold the right structure for you. The earlier this is baked in, the smoother the path to adoption.

Things to think about:

• Would this be acceptable if a whole practice area used it tomorrow?
• Is the identity model consistent with the firm’s?
• Does it leave an audit trail engineers can work with?

Test the edges, not just the ideal path

Lawyers tend to test the app with the exact scenario they built it for. Real users behave differently. They paste badly formatted text, upload documents with inconsistent metadata, click buttons repeatedly and push every edge you never considered.

If you have only tested the perfect path, your tool will feel unreliable.

A simple example. A deadline calculator works brilliantly with six sample orders. The first time someone from litigation uploads a 40-page document with unusual formatting, the app panics. These failures are predictable if you test beyond your ideal cases.

AI can help. Ask it to generate messy inputs and watch what breaks.

Things to think about:

• What does the tool do when given unexpected data?
• Does it fail gracefully or collapse?
• Have you tested the kinds of inputs that different teams actually use?

Build with the assumption that the data store will change

You don’t need to design the firm’s final data architecture, but it helps to assume the storage layer will change long before anything touches real client data. You might use Supabase, Firebase or a local database while you’re testing. That’s all fine. The issue is when the whole tool becomes welded to that specific provider or region.

In practice, the production setup may need a different vendor, a different region for data residency, or a different permission model entirely. An EU practice area won’t be able to run client data through a US-hosted free tier. A team with strict contractual requirements might need an internal store rather than a public cloud service. These aren’t edge cases. They’re routine constraints once a prototype starts to matter.

This is why a bit of data abstraction helps. Keep read and write operations in one place. Avoid sprinkling direct vendor calls across the whole codebase. Treat the testing database as temporary, because it almost certainly is. If you ever need to move from Supabase to an internal SQL instance or shift regions because of residency requirements, the change should be mildly irritating rather than a full rewrite.

You’re not expected to solve compliance. You’re just building with the awareness that the storage layer is the first thing likely to change.

Things to think about:

• Could the tool point at a different database without ripping out half the logic?
• Are data operations grouped sensibly or scattered everywhere?
• Would the design survive a region change or a vendor swap?
• Are you treating your test environment as temporary rather than the final destination?

Keep the code readable so someone else can take over

AI can generate functioning code very quickly. What it cannot always do is generate code that others enjoy reading. If your repo contains one giant file with UI and business logic tangled together, the engineering team will struggle to take ownership.

Readable code is not about elegance. It is about survivability.

You can shape this easily by telling your coding assistant to:

• separate components
• extract business logic into clean modules
• avoid hardcoded values
• include basic tests

All those small choices compound into maintainability, believe me I've done the opposite before and paid for those choices.

Things to think about:

• Can someone scan the repo and understand where things live?
• Are the responsibilities separated logically?
• If you revisited the code six months later, would it make sense?

Prepare for handover even if you’re not planning to hand it over

A tool becomes real when it can survive without its creator. You do not need a novel-length manual. A clean README, a diagram and a few setup notes are enough.

A simple example of what helps:

• a one-paragraph summary of what the tool actually does
• a note on where it runs and any environment variables it expects
• a short explanation of the major folders, so someone knows where logic, UI and tests live
• a line on how to start it locally and how to run the tests
• any “don’t touch this without reading this first” warnings for brittle parts

Nothing heavy, just enough that a new developer could open the repo and feel confident rather than lost.

Ask your coding assistant to generate a first pass and then tidy it. It takes minutes and saves hours of confusion later.

Things to think about:

• Could an engineer make sense of this without ringing you?
• Are secrets and environment variables documented clearly?
• Is there at least a minimal map of how the parts fit together?

Be honest about whether this is a prototype or something people will rely on

Not every tool needs to grow. Personal helpers can stay personal. Others clearly have potential to reshape a workflow and deserve a stronger foundation.

The danger zone is the middle. Tools widely used but fragile under the hood.

Being honest early helps you decide how strict to be. If the tool has real adoption potential, ask for more structure. If it is a short-term experiment, enjoy the freedom.

Things to think about:

• Who is going to use this in six months?
• Does it need engineering support eventually?
• Does the design support growth or is it held together with tape?

Use frameworks and prompts to carry the boring, essential parts

You do not need to remember every standard. You can design your starting prompt so the assistant carries half the load for you.

A good prompt can enforce the stack, accessibility defaults, authentication, file structure, error handling and testing patterns. A good framework can enforce the UI and accessibility layers. You are not only writing code. You are directing the scaffolding.

Once you set the foundations correctly, every feature becomes easier to build and easier to support.

Things to think about:

• Does your chosen framework give you sensible defaults?
• Are you prompting your AI tool with the firm’s standards or making it guess?
• Could you reuse the same structured prompt on every new feature?

A prompt framework you can reuse

This is a practical prompt file lawyers can start every project with. It sets the guardrails so the assistant produces something closer to what engineering can support:

You are helping a lawyer at [Firm Name] build an internal legal tech tool.

This tool may eventually be supported by the firm’s engineering team, so follow these expectations:

Supported stack:

• Languages and frameworks: [TypeScript, React, Node.js, .NET etc]
• UI framework: [MUI]
• Authentication: single sign on using [Azure AD / Okta] with OAuth2 or OpenID Connect
• Hosting: must deploy cleanly on [Azure App Service / internal infrastructure]
• Data: treat all inputs as confidential legal data

When generating code or design:

• Use the supported stack and UI framework
• Use the UI library’s accessible components
• Implement authentication using OAuth2/OpenID Connect, not custom passwords
• Separate UI, logic and configuration into sensible modules
• Store secrets in environment variables
• Add basic unit tests and functional tests
• Include graceful error handling and logging points
• Avoid niche or unsupported libraries
• Write short explanations of design choices

If my request conflicts with these standards, highlight the issue and propose a compliant alternative.

Now I will describe the app/feature I want to build:
[Insert description]

There is incredible potential in what lawyers are building. When someone closest to the work spots a gap and has the confidence to fill it, the results are often sharper and more practical than anything delivered through a long formal programme. The challenge is making sure those ideas survive first contact with governance, security and scale.

A little structure at the start makes all the difference. It helps engineering say yes more often, it keeps risk comfortable but most importantly, it lets your idea grow without losing the creativity that sparked it.

Over the past few years we've seen engineering teams and legal tech teams get closer, and when they meet in the middle, that is when the real breakthroughs happen.