Short answer. AI in an app is not a chatbot wired to a vendor’s API; it is a precise function, with a known input, a constrained output and a threshold below which a human takes over. Six functions sell in Algerian companies in 2027: search in documents, reading invoices and documents, sorting messages, recommendation, generation and dialectal Arabic transcription. Each is built the same way: an orchestration layer that belongs to us, versioned instructions, retrieval of only the useful documents, output schema, business rules, human fallback, log; interchangeable models behind it, chosen per function, language and hosting location; and an evaluation set of sixty real cases written with the manager before the code, replayed at every change. Cost is held by caching the shared prefix, retrieving documents rather than sending everything, and a smaller model where the score holds. Twelve weeks, the first without code.
This guide is for the founder settled in France who has read “app with AI” and wants to know what it must contain, the company in Algeria re-entering invoices and sorting WhatsApp messages by hand, and anyone comparing three quotes where “AI” is one word. It does not say where to start or which uses pay, which the guide on the AI agent in the company does, nor how an agent lives on WhatsApp, described in the dedicated guide; it describes what gets built between the screen and the model.
What the figures say
AI has become ordinary in code, not yet in products. The 2025 DORA report, published on 23 September 2025 from nearly 5,000 responses, says 90 % of the professionals surveyed use AI at work; writing code is what changed, and the delivery guide says what that imposes on tests. Putting AI into the product itself, the one your customers open, is another matter: the question is no longer “can the model do it” but “what do we do when it is wrong, what does each answer cost, and where do our customers’ documents go”.
Arabic is no longer a blind spot. On 15 October 2026, MBZUAI’s Institute of Foundation Models and Inception42, in the UAE, released Jais 3, a family of six open models from 900 million to 375 billion parameters, available on Hugging Face, covering Modern Standard Arabic and regional dialects “to North African Arabic”, with Jais Speech, a speech recognition model that keeps English or French words in their original script when the speaker switches languages; we cite the press announcement, and the exact licence is read on the repository. Other families exist, Fanar in Qatar, ALLaM in Saudi Arabia, Falcon in the UAE, and European vendors such as Mistral host in Europe. What this imposes: a voice note in Algiers or Oran dialect can become usable text, provided it is tested on real voice notes from your customers, not on a demo.
Cost follows stable mechanisms, even though price lists change every quarter. Vendors bill per million tokens, input and output; according to their public price lists, an input prefix already seen and cached is billed a fraction of the full price, in the order of a tenth, and batched, non-real-time processing is billed around half; these are orders of magnitude to check on the day’s price list, and we quote no price because it will be stale before you sign. What does not go stale: a request that resends the whole context every time costs ten times the same request with a cached prefix and retrieved documents, and it is the architecture, not the model choice, that makes the difference. What we did not find: a measure of AI adoption in Algerian apps; this guide describes what we build, not a statistic.
The life of an AI request, in six moments
An AI function is not described by its model but by what happens to a request, from the photo taken by a retailer to the log line that will say what it cost.
The request arrives from the app with its context: a text, a voice note in dialectal Arabic, the photo of an invoice, with the user, the tenant and the originating screen; the app knows who is asking, not the model. Preparation cleans, chunks, retrieves only the relevant documents from the index, and assembles versioned instructions; nothing useless goes to the model, and half the cost is decided here. The model call uses the model chosen for this function, a general one for drafting, an Arabic one for voice, a reading model for the invoice, with the shared prefix cached and a token limit; the same call replayed costs the same.
Verification is the moment that separates a function from a chatbot: the output is constrained to a schema, an amount is a number, a date is a date, a category is one of the six planned, checked against business rules, the total equals the sum of the lines, and scored for confidence; what fails is not displayed. Action or fallback: within the limits written in the first week, the app acts or answers; below the threshold, the request goes to a human with the full context, and the takeover time is measured, as in the WhatsApp agent guide. Log and metering: every request is written with its cost, latency, score and source; this log feeds the evaluation set, the invoice, and the owner’s screen described in the dashboard guide.
AI in an app, in five layers
Behind the six moments, five layers, and the middle one is the only one that belongs to us.
The application shows the answer with its source and confidence level, and lets the user correct it; every correction becomes an evaluation case. Orchestration is the real deliverable: versioned instructions, document retrieval, tools, limits, thresholds, human fallback, log; it is the only layer that knows what the AI is allowed to do, and it is yours, in your repository, not at the model vendor’s. Models are interchangeable behind it: a general one by API, an Arabic one for dialect and voice, a document-reading one, chosen per function, language, cost and hosting location; switching model is a tuning, not a rewrite.
Data makes quality: chunked and indexed documents, the log of requests and answers, the evaluation set; the model does not know your company, your documents do, which is why search in documents answers better than any generic assistant. Operations reads every week the cost per request, latency, the score on the evaluation set and the share handed to a human, with an alert when one drifts. Where documents live and where the model runs follows the hosting guide: the most capable models are called in Europe, documents stay where your contracts require, and only the necessary data crosses.
«A chatbot answers everything; an AI function has a known input, a constrained output and a threshold below which a human takes over.»
A worked example
An example on volume assumptions, with mechanics that are not assumptions: a distribution portal, three AI functions, one month.
2,000 requests a day: catalogue and product-sheet search by retailers, reading of purchase orders photographed by pre-sellers, sorting of incoming WhatsApp messages; that is our volume assumption, measured in the pilot. Sixty real cases in the evaluation set, written with the manager in the first week: twenty catalogue questions with the right answer, twenty purchase orders with the expected fields, twenty messages with their category; they are replayed at every change of instruction or model, and a delivery whose score drops is refused.
Input cost divided by ten on requests whose prefix is cached, according to the vendors’ public price lists, to be checked on your invoice; what does not depend on the price list is that an architecture resending the whole catalogue with every question pays for that catalogue two thousand times a day, while one retrieving the three relevant sheets pays for three sheets. One hundred per cent of requests logged, with cost, latency, score and source, and zero answer displayed without passing the schema and the rules: that is mechanics, not an assumption. The assumptions to check at home: how many requests, what share of dialect voice notes, what confidence threshold your manager accepts before taking over; the project’s first week answers them.
Six AI functions that sell, and how each is built
Six functions, and none is “a chatbot”: each has a precise input, a constrained output and a threshold below which a human takes over.
Search in documents returns an answer in Arabic or French with its source, product sheet, procedure, contract; it is built from chunked and indexed documents, retrieval of the relevant passages, an answer constrained to cite, and “I don’t know” when nothing is found. Reading invoices and documents turns a photo of an invoice, purchase order or ID into filled fields; a reading model, then a strict schema, consistency rules, totals and dates, a score per field and human validation below the threshold; it is the function that replaces the most re-entry, and the guide on integrating existing software says where the fields go next. Sorting messages classifies every WhatsApp or email message as order, complaint, question or urgent; closed categories, labelled examples, a confidence threshold, a human queue for the uncertain.
Recommendation proposes the product, the customer to call back, the next action; business rules first, the model second, and never an automatic action on an account or a payment. Generation drafts a quote, an answer, a file summary in seconds, from the company’s data and versioned templates, with mandatory review before sending. Voice transcription turns a voice note in dialectal Arabic into usable text, through a multi-dialect recognition model that keeps French words, then the text is handled as a written request; that is what lets the pre-seller of the field app dictate an order. The first two rows pay back fastest in Algerian companies, because they replace re-entry; the other four come after, one at a time.
Six AI failures inside an app
Six failures we see on the apps we take over, and what the architecture does against each.
The AI that makes things up: the model confidently answers something false and a customer reads it; answer constrained to cite a retrieved source, output schema, business rules, “I don’t know” allowed, human fallback. The exploding bill: every request resends the whole context and the bill triples in a month; shared prefix cached, documents retrieved rather than all sent, token limit, smaller model where the score holds, and the vendor paid in foreign currency as planned in the guide on paying for cloud. Dialectal Arabic misunderstood: the retailer’s voice note becomes meaningless text; multi-dialect model, test on real voice notes from your customers, fallback below the threshold.
Data sent anywhere: customers’ invoices and IDs go to a vendor with no contract and no known location; model hosting location decided per function, contract and keys in the company’s name, minimal data sent, log. No evaluation set: an instruction change improves one case and breaks ten unseen; sixty real cases replayed at every change, release refused if the score drops. AI with no fallback: the customer is stuck in a loop and nobody takes over; confidence threshold, “talk to someone” button, handover with context, measured takeover time. The first three show immediately, the last three three months later, and all are handled in orchestration and the evaluation set, not by switching model.
«The evaluation set plays for an AI function the role automated tests play for the rest of the code.»
Seen elsewhere: Jais 3, vendor price lists, DORA, and what transposes
Three sources say the essentials. The Jais 3 announcement says open models now cover Modern Standard Arabic, dialects down to North Africa and voice, and that they deploy on one’s own servers; what transposes is that a dialectal Arabic function is tested on your voice notes and messages, not on a leaderboard, and that an open model can run where your contracts require the data to stay. Vendor price lists say that input caching and batched processing divide the cost; what transposes is the architecture that benefits from it, stable prefix, retrieved documents, token limit, and what does not is a price quoted today for a contract signed in three months.
DORA says AI speeds up writing code and weakens delivery when the method does not keep up; what transposes to AI in the product is the evaluation set, which plays for an AI function the role automated tests play for the rest of the code. What these sources do not say: which two functions replace the most re-entry at your company, what confidence threshold your manager accepts, and where your customers’ documents must live; the project’s first week answers that.
The rules of an AI function that holds
Six rules, written in the first week and reread at every instruction change. One function at a time, with a known input, a constrained output and a fallback threshold written before the code. The evaluation set before the code: sixty real cases with the right answer, replayed at every change, release refused if the score drops. Nothing is displayed without schema and rules: an amount is a number, a category is one of the planned categories, an answer cites its source or says “I don’t know”. Orchestration is yours: instructions, limits, log in your repository; the model is an interchangeable supplier. Cost per request is an indicator read every week, with cache, retrieval and model size as levers. Never an automatic action on an account or a payment: the AI proposes, a rule or a human decides.
A seventh rule concerns the quote: “app with AI” is not a requirement, it is a sentence; the requirement reads “reading of photographed purchase orders with extraction of fields X, Y, Z, score per field, human validation below 0.9, score measured on sixty real cases, cost per request displayed, documents hosted at such location, human fallback in under ten minutes”, and it is checked at acceptance on the evaluation set, as the guide on the specification recommends. A quote that prices “AI” in one word has priced a chatbot.
Six apps, and the AI function built first
Six apps we often build, and for each the first AI function chosen in the first week.
- The B2B distribution portal, described in the dedicated guide. Reading photographed purchase orders, then sorting retailers’ messages.
- The pre-sellers’ field app. Transcription of dialect voice notes to dictate an order, then recommendation of the product to offer, rules first.
- The clinic or practice. Reading prescriptions and scanned results into the file, then search in procedures; systematic human validation on health data.
- The real-estate agency. Reading the documents of a rental file, then generation of the inventory and receipts reviewed before sending.
- The SaaS sold to companies, described in the multi-tenant SaaS guide. Search in each customer’s documents, index separated per tenant, shared model, cost per request re-billed per plan.
- The agent on WhatsApp. Sorting messages and search in documents behind the company’s number, with the handover to a human described in the dedicated guide.
The 2027 calendar
The calendar is that of two or three AI functions in twelve weeks, the first without code and two of pilot with human fallback.
Week 0 to 1 writes the functions and limits: the two or three functions chosen, what the AI does, what it never does, the fallback threshold, the documents’ location; signed. Week 1 to 2 writes the evaluation set with the manager: sixty real cases with the expected right answer; it is the acceptance test for everything after. Weeks 2 to 5 build the orchestration and the first function, the one that replaces the most re-entry: versioned instructions, retrieval, schema, rules, fallback, log, and the score measured from the first delivery. Weeks 5 to 7 add the second and third functions on the same layer, with their schemas and evaluation cases, and the model chosen per function and per language.
Weeks 7 to 9 are the pilot with real users and the human fallback active: the share handed to a human, the cost per request and the latency are read every day. Weeks 9 to 11 tune the cost without touching quality: prefix cache, better chunked documents, smaller model where the score holds, every tuning measured before and after on the evaluation set. Week 11 to 12 installs weekly supervision, volume, cost, quality, drift, and decides the next function. Every two-week batch is demoed and accepted as the delivery guide describes, with the evaluation set as the acceptance scenario.
What makes AI fail inside an app
The AI functions we take over almost always failed for one of these reasons.
- A chatbot instead of a function. A window that answers everything; nobody knows what it is allowed to say.
- No evaluation set. Quality is an impression; every instruction change is a bet.
- The whole context on every request. The bill triples, and latency with it.
- Arabic tested on a demo. A retailer’s voice note from Tiaret has nothing to do with the demo’s.
- Customers’ documents sent without a contract. Nobody knows where they are, or who can read them.
- The automatic action. The AI validated an order, changed an account, sent a payment; a rule or a human was needed.
- Orchestration at the vendor’s. Instructions and limits live in a supplier’s console; switching model becomes a rewrite.
Frequently asked questions
The questions we receive from founders settled in France, managers in Algeria and teams comparing quotes.
- Which AI function should go into my app first?
- The one that replaces the most re-entry: reading photographed invoices, purchase orders and documents, or search in your documents. Both have a precise input, a constrained output and a fallback threshold that are easy to write; recommendation and generation come after, one at a time.
- Does the AI understand Algerian Arabic?
- Recent open models, such as the Jais 3 family announced in October 2026, cover Modern Standard Arabic, dialects down to North Africa and voice, keeping French words; but the only proof is a test on real voice notes and messages from your customers, with a confidence threshold and a human fallback below it.
- How much does an AI request cost?
- It is measured, and it is held: vendors bill per million tokens, a cached prefix is billed a fraction of the full price, and batched processing around half according to their public price lists; the architecture, stable prefix, retrieved documents rather than everything sent, smaller model where the score holds, weighs more than the choice of vendor. Cost per request is displayed and read every week.
- What happens when the AI is wrong?
- It is not displayed: the output is constrained to a schema, checked against business rules and scored; below the threshold, the request goes to a human with the context, and the takeover time is measured. Every corrected error becomes a case in the evaluation set, and a delivery whose score drops is refused.
- Where do my customers’ documents go?
- Where your contracts require: the model’s hosting location is decided per function, documents stay in your database, only the necessary data is sent, and the vendor contract and the keys are in your company’s name. Open models can run on your own servers when nothing may leave.
- How long to put AI into the app?
- Twelve weeks for two or three functions, the first without code to write the functions, the limits and the evaluation set with the manager, two of pilot with human fallback, and two of cost tuning; every two-week batch is demoed and accepted on the evaluation set.