Essay · Building and operating

I build AI, and I run a business that has to live with it

By Ahmadreza Samadi · 9 November 2026

I do two jobs that look at AI from opposite sides. At Appraiva, I build it. At Royal Abraj Group in Dubai, I run a business that has to live with what it does. Each job keeps the other honest.

The builder’s side: the model is the smaller part

At Appraiva, a US company in Cleveland, Ohio, I’m Co-Founder & Technical Lead, working remotely from Dubai. We build AI tools that help real estate investors and developers find distressed and off-market properties through imagery analysis and enriched property data.

Building taught me that the model is the smaller part of the product. An image can suggest a worn roof. Before that observation helps anyone, it has to be matched to the right property, set beside dated records and shown where a person can decide what to check next. Most of the engineering lives in those connections, not in the model.

So the builder’s question is practical: what does a person need around the model’s output before they can act on it?

The operator’s side: every answer lands on someone

At Royal Abraj Group, I’m Co-Founder & CEO. The group covers property brokerage and documents-clearing services, and I lead its digital strategy and technology: websites, CRM workflows, customer tools and internal operations.

Here I am the customer of AI, not its vendor. A wrong answer is not a bug report; it lands on a customer and then on our team. That changes what “good enough” means. A demo can be impressive and still be wrong for a business that has to stand behind every reply.

When we added RAIA, an AI assistant inside our customer app for invited customers, we built it around three walls:

Records before reasoning. When a question has a known answer, tested software answers it. The language model only helps with what the software cannot place.
No keys for the model. The model cannot change a record and never receives a customer’s private information. The app reads that information for the signed-in customer and builds the answer itself.
A person decides. RAIA does not judge eligibility, promise approvals or quote prices. When an answer needs judgment, it points to the team.

One lesson came from limits rather than models: count the paid model calls, not the conversation. Most answers never reach the model, so a cap on every message would block customers without saving anything.

RAIA uses a hosted language model; Royal Abraj built the assistant and its workflows. I am describing design choices here, not usage, accuracy or business results. The Royal Abraj case study has the same account.

Where the two sides meet: three questions

Building and operating push me to the same three questions before I choose a model:

Which decision should this improve? “Use AI for customer service” is not a decision. “Help a customer see their next step on their own request” is.
Where must a person check? Anything that changes a record, judges eligibility, quotes a price or commits money needs a named person and a visible route to them.
What does an accepted result really cost? Count the reviews, the retries, the answers people reject and the limits you set, not just the price of a model call. I call this cost per accepted result.

The builder in me wants the model to do more. The operator in me asks who answers for it when it is wrong. The useful product usually sits where both are satisfied. Start with the decision, then build the AI works through the first question in detail.

What I would tell another business owner

Start smaller than the demo. One decision, one place, a small group of users who know it is new.
Let ordinary software answer what has a known answer. It is cheaper, testable and does not improvise.
Keep the model away from the keys. Reading and suggesting is one risk; changing records is another.
Decide in advance who checks, and make the route to that person visible to the customer.
Measure what was accepted, not what was generated.

AI is worth it where it shortens the path to a decision that a person still owns. It must stop where a wrong answer becomes a commitment.

Why I write about it

Most writing about AI comes from people who sell it or people who study it. I write from the place where it is built and then has to work inside a real business, with real customers and a team that answers for it. That is the question I keep returning to at a-samadi.com: where does AI earn its place in a business, and where must it stop?

More: Appraiva case study · Royal Abraj Group case study · AI and business systems: lessons from Dubai