The request usually arrives as one line in a meeting: add AI. It may come from an investor, a competitor's launch, or a customer who met a chatbot elsewhere. For a dozen-person company with no data scientist, finding a model is the easy part, since capable ones can be rented by the request. The harder decision is what to point it at first.
One test settles most of that decision. Assume the model will sometimes be wrong, then ask what each mistake costs and who will notice it. A first project chosen this way looks modest in a demo and holds up once real customers use it.
Pick a Task Where a Mistake Is Cheap
Language models write fluent answers whether or not the answers are right. That makes the best first tasks the ones where a person sees the output before it matters: a draft reply that a support agent edits, incoming messages sorted into queues, amounts and dates pulled from photographed invoices. A misfiled ticket gets moved. A wrong figure in a loan decision or a dosage instruction gets acted on.
Some tasks need no model at all. A rule, a filter or ordinary search is cheaper and never invents anything. Many teams that ask for a chatbot turn out to need better search over their own documents.
Check What Data Actually Exists
A model knows nothing about a company's price list, refund policy or customers until someone hands that material over. In a small business it is often scattered across spreadsheets, chat threads, scanned PDFs and one long-serving employee's memory.
A practical check is to collect a few dozen real examples of the task and write the correct result beside each one. If nobody can assemble that set, the first project is tidying the data. The set should also look like real traffic: customers in Lagos or Nairobi may switch between English and a local language in one message, send voice notes, or photograph a receipt in poor light.
Name the Person Who Checks
In a small team, review means a named person with time set aside for it. At launch that person reads every output. Later, a sample each week is enough.
The example set becomes the test. Run it again whenever the instructions or the model change, because providers update their models and behaviour can shift with no change on the company's side.
Decide What Happens When It Fails
For a wrong answer, users need a way to flag it and reach a human, and the team needs a record of what the model said. For no answer at all, the old manual path has to keep working, since providers have outages and rate limits, and connections drop.
Cost belongs here too. Model usage is billed per request, often in a foreign currency, and the bill grows with every new user. A monthly ceiling, and a decision about what is switched off when it is reached, should exist before launch.
Leave the Build Decision for Last
The technical question comes last. The trade-offs of AI integration versus building your own AI matter more as a product grows, but for a first feature a hosted model reached through an API is usually enough.
A team that can state the task, show the examples, name the reviewer and describe the fallback has done most of the planning. A team that cannot has found out cheaply what to fix before building anything.
