Perspectives ·

Advice that stops at the slide changes nothing.

Why the people who recommend an AI system should be the people who build it.

A recommendation is a prediction. It says that if the business does this, a measure will move. An advisory engagement that ends at the deck ends before the prediction can be tested. The slides are delivered, the engagement closes, and the building passes to a team that was not in the room when the trade-offs were made.

What passes across that line is the conclusion. The reasoning stays behind. Every recommendation rests on assumptions that never reach the final slide: which records can be trusted, which approval can safely be automated, which exception is common enough to design for and which can wait. Those assumptions live with the people who made them. When another team builds, it inherits the answer without the working, and the first assumption to fail in production has no owner.

The evidence on how often AI work stalls between proposal and production is thinner than the commentary suggests. One study is worth reading with care.

A preliminary 2025 report from MIT's NANDA initiative found that only 5% of custom enterprise AI tools reach production. The report rests on 52 interviews, 153 survey responses and a review of public initiatives, and its authors describe the findings as directional. The sample is small. The direction is still hard to ignore.

Source · MIT NANDA, “The GenAI Divide: State of AI in Business 2025”, preliminary findings, Jul 2025

Write the recommendation so it can fail.

We hold ourselves to a different form of advice. A recommendation names the process it will change, the measure that will show it, and the threshold agreed before any code is written. It is then built as one working system on the client's own data and tested by the people who will rely on it. If the prediction is wrong, it fails early, cheaply, and in front of the people who made it. That is the purpose of the Prove stage. It is a test of the advice as much as of the software.

This is also why the counsel and the AI Software Factory sit in one firm. The engineer who finds that a vendor's invoices arrive as scanned Arabic PDFs, and not as the structured feed the diagram assumed, is speaking to the person who drew the diagram. The correction takes an afternoon rather than a change request.

Why the details decide it here.

In the businesses of the Gulf, the details a slide leaves out are often the details that decide whether a system works. Records arrive in Arabic and English, sometimes in one document. Obligations under the UAE's data-protection law shape where personal data may be processed and who may see it. The ERP and the CRM are already in place and carry years of local practice. None of this fits on a slide. All of it shapes the build.

We build what we recommend because it is the only reliable way to learn whether the recommendation was right.

Start here

Bring us the decision you are weighing.

A briefing is a conversation about one process and the systems around it. If there is a fit, we propose a diagnosis or a defined build.