Adding AI to a product you already run Where to start, what it needs and how to test it small

Where should I start?

With a job, not a technology. Look for work in your product or your team that happens often, follows a pattern, and costs someone time or a customer patience. Good candidates are usually unglamorous: sorting incoming requests, copying the same fields out of documents, answering the same questions, spotting the unusual case in a pile of normal ones.

Write each candidate as one sentence: who does what, how often, and what a mistake would cost. That last part decides more than anything else how careful the design has to be.

Automation, machine learning or an LLM feature: what's the difference?

They overlap, but they solve different problems, and picking the wrong one is a common way to lose a quarter.

Automation with a language model in the loop

Best when the work is moving information between tools and reading messy text: emails, PDFs, support tickets, call notes. The language model reads and drafts; ordinary code does the routing, checks and record-keeping; a person approves anything that would cost money if it were wrong. It's often the quickest win, because it uses your tools as they are. See AI automation.

Machine learning on your own data

Best when you want a number or a ranking from patterns in your history: a forecast, a churn risk, a recommendation, a fraud score. It needs past examples of the outcome you want to predict, recorded consistently, and usually plenty of them. It's judged by how much better it does than a simple rule. See machine learning.

Language-model features inside the product

Best when your users would gain from asking in their own words or getting a first draft: search over your help content, a writing assistant, summaries of long records. Most of the work is grounding answers in your own content, deciding what it must refuse, and testing it on real questions.

If the input is photos or video (counting, inspecting, reading labels), that's computer vision, which has data needs of its own.

Is my data ready?

For automation, it's usually readier than teams fear. For machine learning, it's often less ready than they hope. Five questions settle it:

• Do you have examples of the thing you want, with the right answer attached? Past tickets with how they were resolved; orders with whether they came back.
• Has it been recorded the same way over time? A field whose meaning changed last year is really two fields.
• Can you get it out? An export or an API beats screenshots of a dashboard.
• Are you allowed to use it this way? Check your customer terms and privacy law before anything leaves your systems, including to a model provider.
• Does someone know what good looks like? You need a person who can judge the outputs, at least at first.

If most answers are no, the first project is collecting the data properly. That's worth doing anyway.

What does a small pilot look like?

A pilot answers one question: is this good enough to build around? It should be small enough to stop without regret. Run it in this order:

1. Pick one job and one measure, such as the share of incoming emails sent to the right team without a person touching them.
2. Measure how the job goes today, by hand if you have to: how long, how accurate, how often.
3. Set the bar before you start: what result would justify building it in properly, and what would mean stop.
4. Build the smallest version that can be measured, on a sample of real data, with a person checking every output.
5. Compare against today, read the failures one by one, and decide.

At Dayframe, a pilot like this runs as our ongoing team or ml pilot option (sample price: from $4,000 a month), which you can pause or stop with a month's notice.

What can go wrong, and how do I limit it?

• Confident wrong answers. Language models can state false things fluently. Ground answers in your own content, show where they came from, and keep a person in the loop wherever an error costs money or trust.
• Quiet decline. A model that worked in spring can drift as customers and products change. Log what goes in and comes out, and review a sample regularly.
• Leaking data. Know what you send to which provider, what they keep and for how long. Strip what doesn't need to be sent.
• Cost that grows with use. Per-request fees are small until they aren't. Work out the cost per action before launch and set limits.
• Building around a demo. Ten hand-picked examples prove little. Test on a few hundred real ones, awkward cases included.
• Nobody owns it. Someone on your team should know how it works, how to switch it off, and what to do when it's wrong.

What's a sensible first step this month?

List three candidate jobs, each in one sentence with how often it happens and what a mistake costs. Pick the one with the clearest measure and the cheapest mistakes. Pull a sample of real examples. That's enough for a useful conversation with any team, including ours.

When you write it up, our guide to writing a software brief covers the rest of what a studio will ask.