A strategy deck describes where you intend to go. An operating system decides what actually happens next, every day, whether or not anyone is thinking about the strategy. When the two disagree, the operating system wins. It always wins.
That is the whole principle. Most of what looks like a strategy problem is really nobody being able to say, out loud, what happens to an enquiry on a Tuesday afternoon.
What Shalize actually was
Shalize was a physical gold and silver business running on WhatsApp messages, memory and trust. That is not a criticism. It worked, right up until it did not. Volume was climbing faster than the process could hold it, which is the specific failure mode of businesses built on good people: the people are fine, the load is not.
The intervention was not a new strategy. It was a rebuild of the operating system end to end — enquiry, order, invoicing, payment verification, fulfilment, follow-up and buyback — with a CRM underneath it. Seven steps. Each one named. Each one with an owner. Each one with a definition of what "done" means, so that two people cannot both believe the payment was verified and both be waiting for the other.
Daily volume moved from 0.5 to 10 kg/day. 4,000+ verified purchasing customers. I want to be careful here: the money figures the group reports are company-reported gross transaction values, not audited, not revenue, not net margin. Every figure on this site says where it came from and whether it was audited, and most of them were not. Saying so costs nothing.
What I will claim without hedging is the mechanism. The volume did not move because we found a better argument. It moved because the process stopped losing things.
The real launch was not the website
The part people underestimate is who has to change. At Shalize, sales had to stop working from memory. That was the actual launch — CRM adoption, not a page going live. Someone who has spent years closing deals out of their own head experiences a system of record as an insult before they experience it as a memory that does not fail.
This is why People sits third in the five questions I align before building anything: who has to change their behaviour for this to work? Every product is a request that someone act differently — users, yes, but also the sales team, the fulfilment team, and the person who has to stop doing it the old way. A deck never has to answer that question. An operating system cannot avoid it.
The other thing an operating system forces you to be honest about is the market you are actually in. An Iranian gold market settles physically. That makes logistics and custody product problems, not back-office ones. You cannot design that away with a nicer app.
The one that did not work
Mokaab was the same idea, and it came first — 2024 to 2025, where Shalize is 2025 to 2026. It never launched.
I architected the full investment platform — buy, sell, hold, buyback, pricing, invoicing, delivery and account journeys — with the buyback obligation designed in from day one rather than bolted on. I still think that was right. The trust gap, not the technology, is the market: buying gold as an investment in Iran means trusting a shop, a price you cannot verify, and a buyback promise nobody wrote down.
It did not ship. The parent group's priorities moved to physical operations before the platform was ready. Here is the uncomfortable lesson, and it cuts against the principle rather than for it: a well-designed operating system does not protect you from someone else's decision about where the money goes. I had the system. I did not have the mandate. Anyone selling you operating discipline as a guarantee is selling you something.
What survived was the architecture and the market model, folded into Shalize's operating system. So the honest version is not "Mokaab failed." It is: Mokaab was the design work, Shalize was where it ran.
The same shape, in places that look nothing alike
Mehrabani is a charitable crowdfunding platform, not a gold business, and the structure is identical. Charitable giving fails on both ends — donors cannot verify need, social workers cannot prove outcome, and trust collapses in the middle. So I designed the Mehrabani Card as one object carrying the verified need, the beneficiary's story, the donation and the outcome, and built Soha underneath it as the verified-needs data layer. Then, the part that matters: the operational workflow social workers actually use. Not the one they should use.
Ketabno launched in roughly three months. Alongside it, HisTory ran as a product-led growth campaign built as one continuous motion — registration, profile completion and e-book purchase — rather than three campaigns that hand off badly. Invest Iran is the same discipline applied to an investment-promotion agency, which without a digital surface is a phone number: opportunity discovery, competitive-advantage assessment, expression of interest, organisational engagement, request management, aftercare. Named steps again.
CompanyHouse, in 2015, is where I first hit the limit of this. We modelled the registration specialists' tacit knowledge into a guided, question-based workflow that generated the filings, converting rules, decision points and exceptions into product logic. It ran for a year and closed. The lesson: productising expert knowledge is a knowledge-extraction problem long before it is a software problem. You can define every step in the system and still not have captured the exceptions the expert knows and never mentions, because to them they are not exceptions.
Why I am allowed to say this
I learned company building, governance and operational scaling at Aghigh by doing all three badly first, then moving the organisation from project execution toward sustainable product design. The working model I built there was unglamorous and it is the same list every time: brief intake, output definition, allocation, tracking, feedback, revision, delivery.
That is not a strategy. It is a system. It is also the only thing here that has survived contact with real markets.