Abu Albazeez AI

Abu Albazeez AI did not start with a long feature list. It started with a Facebook post about Fable UI and a message from someone in Iraq.

That message turned into a four-hour Google Meet. We talked through several business ideas, our different skill sets, and the thing he had already built: a custom GPT called Abu Albazeez with an Iraqi marketing point of view, an existing community, and people ready to use it if the product became useful enough.

I am a product engineer. I have hands-on experience building and scaling SaaS applications, and I can take a SaaS MVP from product shape through the first working release. He brought marketing expertise, a community, and a real understanding of the Iraqi market. That combination gave us a more useful starting point than either of us would have had alone.

How it started

The custom GPT was not valuable because it was a custom GPT. Its advantage came from the dataset, the system prompt, and web-search tools working together around Iraqi marketing knowledge. The model had a point of view grounded in a market that general-purpose answers often flatten.

The question was whether we could turn that advantage into a product that could be tested with real users. We did not need a large platform to answer it. We needed a small prototype with one falsifiable job.

The prototype question

The prototype took four days. It had basic authentication, a retrieval-augmented generation (RAG) system, and a chat interface.

Its only goal was to answer one question: could the RAG system give answers with the same or better quality than the custom GPT when the model was grounded in the right Iraqi-market material?

That constraint mattered. I was not trying to prove that every feature of a SaaS product was ready. I was trying to prove that the product's core advantage survived outside the original custom GPT.

We launched the prototype to a small, controlled group from the community. The first users were people with marketing experience who already used AI tools in their work or daily routines. Their feedback was specific enough to be useful: the RAG system worked, the answers were grounded in the dataset, and the product could work with more than one person's private context.

Users could upload their own documents and images. They could build a workspace that was aware of both their business or brand and the Iraqi market. The prototype did not prove everything, but it proved the part worth building next.

From prototype to MVP

I started the MVP immediately after that validation. The main change was moving from a convincing demo to a product that could handle ordinary failure and user expectations.

I added more complete authentication and verification flows, rate limits, security measures, error handling, entitlements, subscriptions, and additional usage controls. A central AI gateway coordinated provider calls, access, and cost-sensitive execution. I also worked on more efficient RAG, private projects, and memory so a user could return to a piece of work without pasting its entire background into every conversation.

The product model became clear during this work. Abu Albazeez AI is an Arabic-first, bilingual AI adviser for Iraqi business and marketing work. A project is a private, user-owned context container for conversations, uploaded material, citations, and selected memory. It is not an organization tenant, and it does not imply team membership or delegated access.

The interface had to carry that model in both Arabic and English. RTL behavior, mixed-language text, mobile layout, attachment states, citations, and usage feedback were not polish to add later. They were part of making the adviser usable by the people it was built for.

When the launch got real

We launched the MVP again in a small WhatsApp group with 180 members. By the third day, 140 users were using the free trial, and we had our first paid user.

At that stage, I was watching the server and the product together. One small but revealing issue was the automatic scroll when a conversation became long. The behavior was technically convenient and practically annoying, so I fixed it. Those details matter in a chat product because users notice when the interface takes control away from them.

The product felt stable in that controlled environment. The public launch on TikTok exposed a different class of problem: the edges of account access.

SMS OTP could take ten minutes to arrive, if it arrived at all. Verification emails were not reliably reaching the primary inbox. Some people could not complete signup. That turned launch work into customer support work, then into an operational decision: I added Google OAuth and disabled mobile/email sign-in for that launch because Google was the most reliable path under the observed conditions.

That was a response to real delivery friction, not a timeless claim that the product can only use one sign-in method. It also reminded me that an AI product can have a good answer and still lose the user before the first question is sent.

The launch snapshot

The following is an owner-provided dashboard snapshot dated August 19, 2026. The dashboard uses a selected UTC range for the range-based figures. These numbers are included as launch evidence supplied for this case study; they are not a repository verification or an independent audit.

• Guest sessions: 1,337, tracked since Aug 16, 2026.
• Signups: 978 in the selected UTC range.
• Activated users: 834, defined as users whose first successful chat result is in the selected range.
• Returned users: 245, defined as an in-range successful result after an earlier successful UTC-day result.
• Current paid: 4 paid plans with active or grace access in the current period.
• New paid: 4 first provider-authoritative paid transitions in the selected range.
• MRR: IQD 136,000, with a plan mix of 25% Growth and 75% Starter.
• Technical success rate: 99%, calculated as successful terminal chat AI executions divided by all terminal chat AI executions. This is an execution metric, not uptime, answer quality, or a business-success claim. The dashboard comparison is unavailable.
• Provider spend: USD $50.0241 in the selected UTC range.

The snapshot is useful because it shows the product has left the prototype stage and reached real users, paid access, and operational cost. It is still an early snapshot. Four paid plans are not proof of product-market fit, and provider spend is not a complete unit-economics model.

What the product is now

The product's visible surface is chat, but the useful product is the context around it:

• private projects that keep a user's business or brand context together
• scoped RAG over user-owned documents and images
• citations and provenance so an answer can be inspected against its source
• selected project memory and personalization rather than invisible, unlimited remembering
• subscriptions, entitlements, rate limits, and recovery states around AI usage
• Arabic-first bilingual interaction with RTL and mobile behavior treated as core UX

The system narrows source material to the authenticated user and selected project before relevance ranking. That means the most similar text from the wrong project is not allowed to become a convenient answer. The retrieval boundary is part of the product promise.

The same principle applies to memory. Keeping selected context makes follow-up work easier, but it also keeps the behavior explainable and reviewable. The adviser should help a user continue the work without pretending to own the user's judgment.

Evidence from the product

These captures come from the authenticated product surface. I intentionally cropped away account identity, private conversation rows, draft text, and source contents. They show the product's public-facing shape without exposing private workspace data.

The screenshots show the relationship between the surfaces: a clear entry point, a familiar question composer, and a project that gives the conversation a durable home. They are evidence of the interface, not proof of traction or a substitute for user research.

Tradeoffs and boundaries

The launch made the tradeoffs visible:

• A reliable sign-in path can narrow choice. Google OAuth reduced signup friction under the conditions we saw, but depending on one reliable provider is its own operational risk. The right response is to measure the failure, make the launch path work, and keep the decision reversible.
• RAG quality depends on the material. A dataset can be incomplete, stale, or too narrow. Retrieval can improve an answer's grounding without making the answer true. Citations support inspection; they do not replace a human check.
• Safety can reduce recall. Authorizing by user and project before ranking may exclude a similar document elsewhere. That is a better trade than returning a highly relevant answer from the wrong private scope.
• Projects are not collaboration. The current project model keeps context private and user-owned. Team membership, delegated access, and organization administration require an explicit authorization model.

The product also does not replace a company's primary records, CRM, project-management system, finance ledger, or approval process. It gives a person a controlled place to ask questions of their own work and inspect the trail behind an answer.

The durable lesson

The most important part of this project was not adding more chat features. It was choosing a small question, testing it with the people who would actually use the answer, and then treating every launch failure as product evidence.

The four-day prototype showed that Iraqi-market context could make retrieval useful. The controlled launch showed that users wanted their own documents and images inside that context. The MVP work turned that signal into boundaries around authentication, usage, private projects, memory, citations, and payment. The public launch showed that delivery details can matter as much as model quality.

The durable model I am taking forward is simple: start with one falsifiable product question, ground the answer in the user's real context, make the trail inspectable, and let the evidence change the system.

That is what Abu Albazeez AI is today: an Arabic-first, bilingual adviser for Iraqi business and marketing work, built around private context and a clear limit on what the product can claim. The model can help make the next decision clearer. The person still owns the decision.