Skip to content
Ayoub
Back to services

AI Tools and Chatbots

An assistant that answers from your own material, not from guesswork.

A chatbot or an AI feature built on your own documents and data. It answers in your customers’ languages, says when it does not know, and hands hard cases to a person.

What this actually is

The most useful AI work is narrow. One assistant that answers questions about your product. One tool that reads documents and pulls out the fields you need. One helper inside an app you already run.

The model is the easy part. The work is in what you feed it and what you do with the answer. Your material has to be collected, cleaned and made searchable, so replies come from your content and not from invention. The system needs a clear limit, and a way to say it does not know. Someone has to see the conversations, correct them, and pass the hard ones to a person. Cost per request matters, because it repeats all day.

I build these with the Vercel AI SDK and Claude, connected to your data. Arabic and English are handled from the start, not added later.

What you get

  • A written scope: what the assistant answers, and what it refuses
  • Your content collected, cleaned and made searchable for the model
  • The assistant on your site, inside your app, or on WhatsApp
  • An admin view of real conversations, where you correct the answers
  • Handover to a person when the assistant reaches its limit
  • Usage and cost visible, so the spend does not surprise you

Things in this category

  • A support chatbot that answers from your own help pages
  • An assistant that reads invoices and returns structured fields
  • A search box that answers in sentences instead of links
  • An internal assistant over your team's own documents
  • A drafting tool that writes first versions in your own wording
How this one gets built

The same six stages, said in the language of this kind of product.

You tell me the idea

A single conversation, usually about thirty minutes.

We talk until I can describe your idea back to you correctly.

We start with a conversation, in English, French or Arabic. You describe the idea in your own words. I ask questions about who it is for, what they do today, and what you want to happen. I write down what I heard and send it back for you to correct.

What you have at the endA written idea brief: the goal, the user, the assumptions, and what success means.

You see the market gaps

Usually a few days to a week.

I find out what already exists and where it leaves people stuck.

I go through the products your users already use, free and paid. I read what people complain about in reviews, forums and support threads. I look at how competitors charge. Then I write down the gaps that are real, and the ones that are not worth chasing.

What you have at the endA market and competitor report, with the gaps ranked and the evidence linked.

You see the real screens

Usually a week or two.

We decide what the product is, and you see it before it is built.

I turn the gaps into a product you can actually see. First the shape: what it does, who logs in, what each screen is for. Then clickable screens you can open on your phone. You use them, tell me what feels wrong, and I change it before any code exists.

What you have at the endA clickable prototype of the main screens, plus the agreed feature list.

You approve the plan

Usually a few days.

The build gets broken into phases, each with its own scope and price.

A big build in one piece is where projects go wrong. So I split it into phases. Each phase has its own scope, its own price and its own working result. You approve one phase before it starts. You are never asked to commit to the whole thing at once.

What you have at the endA phase plan: scope, price and result for each phase, in writing.

You watch it being built

The longest stage. Weeks to months, depending on scope.

The product gets built in order, and you see it working every week.

I build phase by phase, starting with the part that carries the most risk. Every week there is a real link you can open and use. Nothing is hidden until the end. When something takes longer than I said, you hear it from me first.

What you have at the endA working product on a live link, updated every week, with the code in a repository you own.

You launch, and I stay

Launch takes days. Staying afterwards is ongoing.

The product goes live, and I stay until it is genuinely right.

Going live is a stage, not a finish line. I move it to your domain and accounts, watch the first real users, and fix what they hit. Then I hand over what you need to run it. If you want me to keep going, I stay.

What you have at the endThe live product on your domain, with accounts, code and a short handover guide.

See all six stages in full
What I build

Is this what you need?

If you are not sure which of these your idea is, that is a normal question and a good reason to talk.