What I Won't Build
Five things I turn down, and the one question worth asking any AI vendor.
I build software for law firms and assisted living facilities. Almost every conversation starts the same way: someone describes a demo they saw, and asks whether I can build that.
Usually I can. Often I say I’d rather not, and explain why. That conversation is the most useful hour either of us spends, so I’ve written down the version of it I give most often.
To be clear, this isn’t a list of my capabilities. It’s a list of the things I decline, because what a person refuses to do tells you more about how they work than what they’re willing to sell you.
1. I won’t build something that changes your records without you knowing
This is the big one, and it’s the one people push back on hardest, because the whole appeal of an AI assistant is that it does the work.
Here’s my problem with it. When a person on your staff makes a mistake in a file, there’s a human being who remembers doing it. There’s a conversation, a sticky note, a moment where somebody said “wait, I thought we agreed on the other date.” That’s not a great error-detection system, but it’s a real one, and you’ve been relying on it for years without noticing.
When software makes the same mistake, there’s none of that. There’s a field that used to say one thing and now says another, and no one who remembers. And the mistakes software makes aren’t the obvious kind — they’re the plausible kind. A date that’s wrong by a year looks exactly like a date that’s right.
So the question I care about isn’t how accurate is it. It’s what happens on the day it’s wrong. If the answer is “we’d find out eventually, from the consequences,” that’s not a tool I want to have built for you. In a law firm, the consequence is a deadline. In an ALF, it’s a resident record that doesn’t match what actually happened, discovered by someone holding a clipboard.
The version I will build tells you things. It says: this file hasn’t moved in thirty-one days. This resident’s service plan is out of date. This document should be here and isn’t. Then a person decides what to do, and the record shows that a person decided. That’s slower. It’s also the version where nobody has to audit the software’s work, because the software didn’t do any.
There are cases where I’d build the acting version. It needs a review step, a record of who approved what, and different levels of approval depending on what’s at stake — a document getting filed is not the same as a deadline getting changed. That’s real work, and it should be built deliberately rather than switched on because it demoed well.
2. I won’t use AI for something arithmetic already does
A lot of what gets sold as artificial intelligence is a calculation with a chatbot in front of it.
Whether a file has been idle for thirty days is subtraction. Whether a required document is missing from a checklist is a comparison. Whether a resident’s assessment is past due is a date and a rule. None of that needs a language model, and putting one in the middle makes it worse — not because it would get the arithmetic wrong, but because it stops being reliable. Ask the same question twice and you can get different answers, and nobody, including me, can tell you why.
So in the systems I build, the rules that decide what matters are plain settings in a file you can read. Thirty days. Fourteen days. This document is required for this kind of case. You can change them, and you can see who changed them and when, and the same input always produces the same result.
The language model gets a much smaller job: taking the things the rules flagged and writing them in readable English instead of a table. That’s a job it’s genuinely good at, and one where an awkward sentence costs nothing.
The practical version of this: if a vendor can’t tell you which parts of their product are rules and which parts are the model guessing, that’s the answer to your question.
3. I won’t send your records somewhere I can’t account for
You already know this instinct. It’s the same one that makes you careful about which vendors touch your files.
The specific risk with AI tools is that many of them work by sending your text to a company you have no relationship with, and some of those companies use what they receive to improve their systems. What that means concretely is that information from your files becomes part of something you no longer control.
The way I build around this is unglamorous: the model runs inside your own cloud account, under your own agreements, and your data doesn’t leave it. It’s more setup. It also means that when you ask me where your information goes, the answer is one sentence long, and it’s a sentence you could repeat to a client, a family member, or a regulator without checking with me first.
Related, and worth saying plainly: I’m a HIPAA business associate, I sign BAAs, and I treat that as a real obligation rather than a form. It shapes what I build. The demos on this site run entirely on invented data — invented residents, invented cases, invented facilities — because I’m not willing to show you a real one, including to win your business.
4. I won’t build something you can’t fire me from
You talk to the person writing the code, so nothing gets lost between a salesperson and an engineer. The flip side is a question you should be asking of anyone you bring in: what happens to your operation if this arrangement ends?
So I build for the case where I’m gone. Settings in plain files rather than buried in a database only I can reach. Documentation aimed at the next developer, not at me. Your data in systems you own and can export. No proprietary format that only my software reads.
I’d rather you stay because the work is good. Building a system that traps you is a way of being paid for something other than the work, and it tends to produce exactly the kind of software that needs trapping.
5. I won’t sell you the demo
Every AI demo works. That’s what a demo is — a path someone walked through until it went smoothly.
What determines whether the thing is worth having is a set of questions demos don’t answer. What happens when the export format changes? When someone types a name three different ways? When the model returns something confident and wrong? When your one staff member who understood the system leaves?
I’d rather show you the shape of the real thing and be direct about what it doesn’t do. The engineering piece on this site is about a system I built for a law firm, and a good chunk of it is about the system’s limits — a person still does the data entry, and some firms find that disappointing. I left that in on purpose. If the limits are dealbreakers, both of us are better off knowing in the first conversation.
The question worth asking
If you take one thing from this: when someone shows you an AI tool, ask them what happens on the day it’s wrong, and how you’d find out.
You’ll get one of three answers. Some vendors have thought about it carefully and will walk you through it. Some haven’t thought about it and will tell you how accurate the model is, which is not the question. And some will tell you it doesn’t get things wrong, which tells you the most of all.
You don’t need to understand the technology to evaluate the answer. You just need to notice which one you got.
What this looks like in practice
I work with two kinds of operation: personal injury law firms, and Florida assisted living facilities. Different regulators, same underlying problem — a business where the records are the business, and where a gap in them is the thing that hurts you.
The work usually starts small and specific. Not “AI for your firm,” but: your files go quiet and nobody notices until it matters. Your document checklists are complete in theory. You find out what’s missing from a resident’s chart when someone comes to look at it. Those are narrow problems, they’re expensive, and they’re solvable without asking you to change how you work.
If that sounds like your operation, the demos on this site are open — no form, nothing to fill in. Look at them, forward them to whoever else should see them, and get in touch if it’s worth a conversation.
I’m not a lawyer and I’m not a compliance consultant. I build software, and I design it against the rules that apply to the business it’s for. What your obligations are is between you and your own counsel — I can only tell you what I designed for and why.