AI in your app or business: where it actually helps

Start with a task that costs you time

Most business owners I talk to ask whether they should add AI. I answer with a question: which task takes your customers or your team too long, and could a machine produce a good first version of it?

Write that task in one sentence, such as ‘Our support staff spend most mornings answering the same delivery questions on WhatsApp’ or ‘Someone types every supplier invoice into the accounting system by hand’. It tells you who loses time, how often, and what a good result looks like.

If you cannot write it, stop there. AI without a clear task adds a monthly bill and nothing you can measure.

AI is also usually one feature, not the product. In 90Plus, a bilingual Flutter football app I worked on, the AI assistant sits next to live scores, quizzes and predictions: one useful feature attached to a real need.

A quick test for a good fit

Before anything is built, I run the task through a few questions. The more yeses, the better the fit:

• Does the task repeat many times a week, in roughly the same shape?
• Is it mostly about reading or writing text, such as messages, documents, descriptions or notes?
• Is a good first draft useful, even if a person finishes it?
• Can a person check the result quickly, faster than doing the task from scratch?
• If the result is wrong, can you catch it before it reaches a customer, or is the damage small?
• Is the knowledge it needs already written down somewhere: your website, a policy, a catalogue, past replies?

Answering repeated customer questions

This is the request I get most, and often the best place to start. Most businesses answer the same questions every day: delivery times, returns, opening hours, sizes, service areas.

An assistant on your website, in your app or connected to your support inbox can answer those at any hour from your own content: your FAQ, policies and product information, not whatever the model knows about the world.

Done well, it shows where each answer came from, admits when it does not know, and hands over to a person with one tap. Done badly, it invents a return policy you never had.

Before building anything, export a few months of real questions, remove names and phone numbers, and group them. You will see which questions repeat, and which ones your content does not answer at all.

Replying in Arabic and English

In Egypt and the Gulf, customers write in Arabic, in English, and often both in one message. Current language models handle both, so one assistant can reply in whichever language the customer used, from the same content.

You do not need two knowledge bases kept perfectly in step, as long as someone who reads both languages checks a sample of answers. The exceptions are product names, prices and legal wording: keep official versions in both languages, and make the assistant quote them rather than translate them.

Summaries and first drafts

• Summarising a contract, a tender, a long email thread or a month of reviews into the points that matter.
• Turning a voice note or a meeting recording into text, then into a task list.
• Drafting product descriptions from a few facts, for an online store with hundreds of products.
• Drafting replies to customer messages for a team member to edit and send.
• Rewriting content for different places, such as a short version for the app and a longer one for the website.

In every case the output is a draft. A person reads the summary before acting on it, and checks a description for wrong sizes or claims you cannot back up.

Do not publish hundreds of generated pages without review. They sound alike, and Google's spam policies cover pages produced at scale with little value for readers.

Pulling data out of documents and invoices

Small companies lose a lot of time copying information between systems: supplier invoices into accounting, order forms into a spreadsheet, CVs into a database.

Models can read a PDF or a photo of a document and return the fields you ask for in a fixed structure, like the example at the end of this section.

Your own code, not the model, then checks the result. Are the required fields present? Is the date valid? Does the subtotal plus VAT equal the total? Does the supplier exist in your system? Anything that fails goes to a person. The rest is ready to approve with one click instead of being typed from scratch.

Handwriting, poor photos and unusual layouts are harder, so test with your real documents, including the worst ones.

{
  "supplier_name": "Example Supplies Co.",
  "invoice_number": "INV-20417",
  "invoice_date": "2026-09-14",
  "currency": "EGP",
  "subtotal": 12500.00,
  "vat": 1750.00,
  "total": 14250.00
}

Search and sorting that understand meaning

Normal search on a website or in an app matches words. If a customer types ‘something for a sore back’ and your product is called ‘ergonomic lumbar cushion’, keyword search finds nothing. Search based on meaning finds it, because it compares what the words mean, not how they are spelled.

The same idea works for sorting. Messages, support tickets, reviews or orders can be labelled automatically: complaint or question, urgent or not, which department, which product. Your team starts the day with a sorted queue instead of a pile.

Sorting is a good first project because mistakes are cheap. A ticket in the wrong queue takes seconds to move, and you can measure accuracy by comparing the labels with the ones your team would have chosen.

Where AI is the wrong tool

• Anything that must be exactly right with no one checking: prices, stock, order status, balances, delivery dates. Show these from your database as they are. An assistant may look them up, but must never write them from memory.
• Calculations such as totals, taxes and discounts. Normal code gets them right every time.
• Legal, medical or financial decisions about a real person. A model can help a professional read faster; it should not decide or advise.
• A task a simple button already does faster. A ‘Track order’ button beats a chat.
• Questions whose answers are not written down yet. The model cannot know a policy that lives only in your team's heads.
• Rare tasks. If something happens twice a month, setup and upkeep cost more than the time saved.

A model can sound completely sure while being wrong. That is fine for a draft a person reads, not for a final answer about money, health or the law.

If unsure, ask what happens when the answer is wrong. If the honest reply is ‘a customer loses money or trust and nobody notices’, keep a person in charge.

How an AI feature is built

Most AI features I build for websites and Flutter apps share the same shape, and knowing it helps you question whoever builds yours:

• Your data. FAQ, policies, product catalogue, help articles and good past replies, cleaned up and current. This is often the biggest part of the work, and it affects quality most.
• Retrieval. The content is split into short pieces and indexed by meaning. For each question, the system finds the few pieces most likely to hold the answer.
• A model API. Your server sends the question, those pieces and a set of rules to a language model, and gets an answer back. The call never goes straight from the app, so the API key stays private.
• Guardrails. Written rules like the example below, topic limits, checks on the answer before it is shown, and a cap on requests per user.
• Human review and handover. A person approves drafts or reviews a weekly sample, and customers can reach a person at any point.
• Logs and feedback. Questions, answers and a ‘Was this helpful?’ button are stored without personal details, so you can fix what goes wrong.

You are the assistant for [Business name].
Answer only from the documents provided below.
If the answer is not in the documents, say you are not sure
and offer to connect the customer with our team.
Never state a price, stock level or delivery date unless it
appears in the order or product data provided.
Do not give legal, medical or financial advice.
Reply in the language the customer used. For Arabic, use
simple, clear Arabic that readers in Egypt and the Gulf
both understand.
Keep answers short: three sentences at most.

Arabic dialects need real testing

Your customers do not write textbook Arabic. People in Cairo, Riyadh and Dubai ask the same question in different words, often mixed with English or written in Latin letters and numbers, like ‘3ayez a3raf el se3r’.

How well a model understands each dialect varies between models, and a demo in English or formal Arabic tells you little. Test with real messages from your own customers, with names and numbers removed.

Decide how the assistant replies. I usually suggest simple Arabic close to the formal language, which readers in Egypt and the Gulf all understand, unless your brand voice is deliberately local. Put that choice in the rules.

Search needs care too. The same Arabic word can be written with or without a hamza, with ة or ه at the end, with ى or ي. Normalise these before searching, so that اسعار and أسعار return the same results.

Finally, test on real devices that answers mixing Arabic, English product names and numbers display right to left correctly. Flutter handles most of this, but check it with real answers.

Privacy and your customers' data

• Send only what the task needs. A question about returns does not need the customer's phone number.
• Mask names, phone numbers, addresses and ID numbers before text is sent or stored, wherever the task allows.
• Read your API provider's data terms: whether your data may be used to train their models, how long it is kept, and where it is processed. Business API terms often differ from free consumer apps.
• Never paste customer data into a free chat tool to ‘test quickly’.
• Decide how long you keep conversation logs, and who can read them.
• Update your privacy policy to say that an AI service processes certain messages, and why.

Egypt, Saudi Arabia and the UAE each have a personal data protection law, and Europe has the GDPR. They differ on consent, on sending data abroad and on what you must tell customers. For sensitive data, or customers in several of these places, get legal advice before launch.

Also tell customers when they are talking to an automated assistant. It is honest, and it makes asking for a person feel natural.

What drives the running cost

• Usage. Most model APIs charge by the amount of text going in and out, so more customers and questions mean more cost.
• What you send with each request. The question is small; the rules, retrieved content and conversation history sent with it are often much larger.
• Answer length. Short answers cost less, and usually serve customers better.
• Which model. Larger models cost more per request. Sorting or invoice extraction often works well with a smaller, cheaper model, so test before assuming you need the biggest.
• Documents and images. Long PDFs and photos use more than short messages.
• Everything around the model: the server, the search index, monitoring, and someone's time to review answers and update content.

Building the feature is a one-time cost; model usage is monthly and grows as the feature succeeds. Many providers let you set spending limits or alerts, and your app should cap requests per user per day to stop abuse.

To keep the bill down, use shorter rules, send only the most relevant content, reuse answers to frequent identical questions, and use a smaller model for simple steps.

For an accurate estimate, start from your monthly volume of messages, documents or orders. Run the pilot, read the real usage in the provider's dashboard, and scale it up. That beats any estimate made before a single real request.

How to know whether it helped

Decide what success means before launch, and measure the same thing before and after:

• Time per task: how long your team takes to answer a message, process an invoice or write a description.
• How many questions are fully answered without a person, and how many are handed over.
• How often a person has to correct the output, and how big the corrections are.
• Wrong answers found in your weekly review, especially any about prices, policies or promises.
• Customer feedback: helpful buttons, complaints, and whether people ask for a person straight away.
• Monthly running cost compared with the time saved.

A small pilot plan

This is the plan I usually suggest for a first AI feature. It keeps the risk small and gives you real numbers to decide with:

• Pick one task, write it in one sentence, and choose the measure you will judge it by.
• Measure how it is done today for a couple of weeks, so you have something to compare with.
• Collect the content and real examples, with personal details removed.
• Build a small version for your team only, with a person reviewing every output.
• Write a test set of real cases, including hard ones, Arabic dialects and English, and rerun it after every change.
• Open it to a small group of customers, with a clear way to reach a person and the old way still available.
• Review the logs every week: wrong answers, gaps in your content, daily cost.
• Decide from the numbers: expand it, fix it or stop it. Stopping is a valid result.

Common mistakes to avoid

• Starting from ‘we need AI’ instead of a task that costs time.
• Launching to every customer on day one, with no way to reach a person.
• Letting the assistant state prices, stock or order status from memory.
• Feeding it old or contradictory content, then blaming the model.
• Testing only in English or formal Arabic, then launching to customers who write in dialect.
• Putting the API key inside the mobile app, where it can be extracted.
• No spending limit, no per-user limit, and nobody reading the logs.

Almost all of these are planning mistakes: cheap to avoid at the start, expensive to fix after launch.

What to do next

Take one task that costs your team or your customers time, and write it in one sentence. Run it through the quick test above. If it passes, gather real examples and the content it needs, without personal details.

Then ask whoever builds your app or website for a small pilot, not a big launch, and ask how they will handle retrieval, guardrails, privacy, handover to a person and spending limits. Clear answers there matter more than which model they use.

If you want a second opinion, send me the task and a few anonymised examples. I build Flutter apps and websites for businesses in Egypt, the Gulf and Europe, and I will tell you honestly whether AI is the right tool or a simpler feature would do better.

Common questions

How can AI help a small business?

It helps most with repeated work that involves text: answering common customer questions, summarising documents, pulling data from invoices, sorting messages and drafting descriptions or replies. The best starting point is one task that clearly costs your team time. AI is a poor choice for anything that must be exactly right without a person checking it.

Can I add an AI chatbot in Arabic to my website or app?

Yes. Current models understand and answer in Arabic and English, and one assistant can reply in whichever language the customer used. Understanding of dialects varies between models, so test it with real messages from your own customers before launch. Make sure it answers only from your content and always offers a way to reach a person.

How much does it cost to add AI to an app?

There are two parts: a one-time cost to build the feature, and a running cost that grows with usage, because most model APIs charge by the amount of text processed. The running cost depends on how many requests you get, how much text each one sends and receives, and which model you use. The most accurate way to estimate it is a small pilot that shows real usage.

Is it safe to send customer data to an AI service?

It can be, if you send only what the task needs, remove personal details where possible, and use a business API whose data terms you have read. Check whether your data may be used for training, how long it is kept and where it is processed. Data protection laws in Egypt, the Gulf and Europe also apply, so get legal advice for sensitive data.

Will AI replace my customer service team?

It is better to plan for it to change their work rather than replace them. It can take the simple repeated questions and prepare drafts, so your team spends more time on cases that need a person. You still need people for complaints, for checking answers and for keeping the content up to date.

Do I need to train my own AI model?

Almost never for a small or medium business. The usual approach is an existing model that answers from your own content, which is found through retrieval at the moment of the question. Training or fine-tuning your own model is slower and harder to maintain, and it is rarely the right first step.

How do I know if an AI feature is working?

Choose a measure before launch, such as time per task, how many questions are answered without a person, or how often answers need correcting, and measure it before and after. Review a sample of real answers every week. If the measure does not clearly improve, fix the feature or stop it.