Wanting to be trusted and being checkable are different things. The first is a tone of voice. The second is a product decision, and it costs something.
The gold market taught me this first
Buying gold as an investment in Iran means trusting a shop, a price you cannot verify, and a buyback promise nobody wrote down. When we defined Mokaab, that was the finding: the trust gap — not the technology — is the market. It sounds like a slogan. It was meant as a specification. If the gap is the market, then every feature has to be judged by whether it closes the gap or decorates it.
So the buyback obligation was designed in from day one, not bolted on — through the buy, sell, hold, pricing, invoicing, delivery and account journeys. That is a small sentence with a large consequence. A buyback promise nobody wrote down is a mood. A buyback obligation that exists in the product is a thing the company cannot quietly withdraw when the market turns. The first version costs nothing to say. The second changes what you are allowed to do later. That is what I mean by designed.
Mokaab never launched. The parent group's priorities moved to physical operations before the platform shipped. I want that on the record before I claim anything from it, because a principle that only appears in the wins is not a principle. What survived was the architecture and the market model, folded into Shalize's operating system.
What it looked like when it actually ran
Shalize was a physical gold and silver business running on WhatsApp messages, memory and trust, with volume climbing faster than the process could hold it. Note the word "trust" in that description. There was plenty of it. It was just entirely undesigned — held in individual relationships, in one person's recollection of what was promised, in a message thread nobody could find twice.
What we rebuilt was unglamorous: enquiry, order, invoicing, payment verification, fulfilment, follow-up and buyback, each with one owner, one definition and one place to live, with a CRM underneath. None of that is a trust feature in the way a marketing team would use the phrase. All of it is a trust feature in the only way that matters — the promise made at enquiry is the same promise that exists at fulfilment, and someone can go and look.
The mechanism worth naming: CRM adoption was the real launch, not the website. Sales had to stop working from memory. That is the actual cost of designing trust, and it is why tone of voice is the easier choice. Tone of voice asks nobody to change their behaviour. Payment verification asks a specific person to do a specific thing they did not do yesterday.
Daily volume moved from 0.5 to 10 kg per day. There were 4,000+ verified purchasing customers, and repeat purchase became the channel — which is what happens when the thing compounding is trust rather than advertising. Trust compounds; ads do not.
Charity is the same problem with the money reversed
Charitable giving fails on both ends: donors cannot verify need, and social workers cannot prove outcome. Trust collapses in the middle. The instinctive fix is reassurance. We built an object instead. The Mehrabani Card carries the verified need, the beneficiary's story, the donation and the outcome, in one place. Soha sits underneath it as the verified-needs data layer.
The mechanism is that the card is a single artefact that survives the whole journey. A donor who wants to know what happened does not have to trust a summary; the impact-reporting loop closes back on the same object they gave against. And because it was built for national-scale distribution, the operational workflow had to be one social workers actually use — otherwise the verification layer is decorative and you are back to reassurance with extra steps.
Where it did not work, and why
CompanyHouse is the counter-example I keep. Registering a company in Iran requires an expert because the process is deliberately opaque: the expertise is the product, and the bottleneck. We modelled the specialists' tacit knowledge into a guided, question-based workflow that generated the filings. It ran for a year. It closed.
The lesson I took was that productising expert knowledge is a knowledge-extraction problem long before it is a software problem. There is a trust lesson underneath it. In a legal filing, the artefact the user needs to trust is the output — the document that either survives the registrar or does not. We could model the questions the specialists ask. Until you can also model the exceptions they know, you do not have a product; you have a service with a login screen. And an expert system that is right most of the time is not trustworthy where being wrong once is the whole cost.
WritingChex hit a version of the same wall from the other side. An IELTS candidate outside a major city has no examiner, no feedback, and no way to know why their writing scores what it scores. That product only works if the feedback is believable. I was honest with the team about where the model could not be trusted, which I still think was right, and the MVP validated with real submissions and first paying customers — the first proof that people would pay for machine feedback. It wound down in 2025 anyway. Being honest about a limit does not remove the limit.
The site is the same argument
Every figure on this site says where it came from and whether it was audited. Most of them were not. The Toman figures are company-reported gross transaction values — not audited, not revenue, not net margin — and no USD equivalent is given, because the exchange rate over the period was not stable enough for an honest conversion.
Saying so costs nothing and is the only reason to believe the rest. Which is the principle in its cheapest possible form: trust is what is left after you remove everything a reader cannot check.