To add AI to business software without wasting money, start from one specific task instead of a model. Pick a job that involves reading or drafting text, test it on real examples before building anything, keep fixed text and calculations in ordinary code, have a person review output where a mistake would matter, and measure the running cost.
Most requests we get to "add AI" arrive without a task attached. The owner has seen a demo, knows competitors are talking about it, and wants some of it in the product. That is the expensive way to start, because a feature with no job to do cannot be tested, and a feature that cannot be tested never gets finished.
We use language models in several things we run: a practice management system, a website chat, and a case hub for a personal injury practice. In each one the model does a single narrow job, and the rest of the product is ordinary code. This post is the order we work in.
Where does AI actually help in business software?
AI helps in business software where the work is reading or writing text that changes every time. In our own projects that means three jobs: drafting the paragraphs of a document that depend on the facts, reading long records and summarizing them, and answering questions from website visitors in plain language.
Each of those comes from something we run.
- Drafting variable paragraphs. CaseCobra generates court documents. The caption, parties, and judge are filled in by code. A model is used only for the paragraphs that depend on the facts, and an attorney reviews them.
- Reading records. Medical records are the slow part of an injury case. The AZLG Case Hub reads them and drafts a chronology the attorney can check instead of write.
- Answering questions. Ask Tamou gives website visitors an immediate, careful answer, then hands the conversation to a person at the firm.
What these have in common: the input is messy text, the output is a draft or a reply, and a person is close by.
What are the steps to add AI to existing software?
The steps to add AI to existing software are: choose one task, collect real examples, test a model on them by hand, decide what stays in plain code, build the smallest version, add a review step, and track cost and errors after launch. Most wasted money comes from skipping the second and third steps.
- Name one task. Write it as a sentence with an input and an output: "Given these records, produce a dated list of treatments." If you cannot write that sentence, you are not ready to build.
- Collect real examples. Gather a set of actual inputs, including the ugly ones: scans, half-finished forms, rambling messages.
- Test by hand first. Run the examples through a model in a plain chat window or a short script. This costs very little and tells you whether the idea works at all.
- Split the work. Decide which parts are fixed and belong in code, and which parts need a model. We cover that split in when to use AI and when plain code is better.
- Build the smallest version. One screen, one task, inside the software people already use.
- Add the review step. Decide who sees the output before it counts, and make checking it easy.
- Watch it after launch. Log what went in, what came out, and what the reviewer changed.
How do you know if a task is a good fit for AI?
A task is a good fit for AI when the input is language, the right output varies with the input, a reasonable draft saves real time, and someone can check the result. It is a poor fit when the answer must be exactly the same every time or when no one will review it.
| Question | Good sign | Bad sign |
|---|---|---|
| What is the input? | Free text, documents, messages | Clean fields in a database |
| Does the output vary? | Yes, with the facts | No, it is fixed wording or arithmetic |
| Who checks it? | A person who knows the subject | Nobody |
| What does a mistake cost? | A corrected draft | Money, a deadline, or trust |
| How often does it happen? | Many times a week | A few times a year |
If most answers land in the right-hand column, write normal code or leave the process alone.
What should stay out of the model?
Text that must be identical every time, calculations, permissions, and anything involving money should stay out of the model and in ordinary code. A language model produces likely text, and it can answer the same input differently each time, which is exactly what you do not want from a total or a legal caption.
In our document engine the boilerplate never passes through a model. It is stored as templates and assembled by code, because it has to be the same on the hundredth document as on the first. The model only sees the part where judgment is involved, and a person reads that part.
The same rule applies to lookups. If the answer is in your database, query the database. Do not ask a model to recall it.
How do you keep an AI feature from becoming a money pit?
An AI feature stays affordable when it has one task, a clear way to tell whether it is working, and a limit on how much text it processes. Costs climb when the scope is vague, when every request sends far more text than needed, or when nobody notices the feature is unused.
There are two costs: building it and running it. Running cost is usually billed by the volume of text sent and returned, so a feature that reads a long file on every click costs more than one that reads it once and stores the result. We go through both in what it costs to add AI to an app.
The cheaper option is sometimes no AI at all. If testing by hand in step three shows the drafts need as much fixing as writing from scratch, stop there. You have spent an afternoon instead of a budget.
Frequently asked questions
Do I need to train my own AI model?
Almost never. Most business features work by sending your own text to an existing model through an API along with clear instructions. Training or fine-tuning a model is a separate, heavier project, and it only makes sense after the simple approach has been tried and found lacking.
Can AI be added to software that is already built?
Usually, yes. A model is reached through an API, so it can be called from an existing application like any other outside service. The harder part is getting the right data to it and deciding where the output appears and who reviews it.
Is my data safe when it is sent to an AI provider?
That depends on the provider's terms and how the feature is built. Read what the provider says about retention and training on your data, send only what the task needs, and check any rules that apply to your industry before sending client or patient information.
What is the smallest useful AI feature to start with?
A draft that a person already writes by hand many times a week, such as a summary of a long record or a first reply to a common question. It is easy to test, easy to review, and the time saved is visible.
How long before we know if it is working?
You learn the most before building, by testing real examples by hand. After launch, the reviewer's edits tell you quickly whether drafts are useful or being rewritten.
If you have a task in mind and want a straight opinion on whether a model belongs in it, tell us what the job is.