About
An engineering company, described without adjectives.
What follows is the same set of commitments that appear throughout this site, collected in one place. There is nothing here that is not also demonstrated on the page it came from.
What this is
Four practices and one operating model.
The practices are blockchain, AI, software and web. The operating model is the part that matters more, because it is what the practices are built to survive.
We operate what we build
A system handed over on launch day tends to be legacy inside two years. Running our own work is what prevents that, and knowing in advance that we will be running it changes how it gets built.
We work inside your day
Engineering teams in your time zone rather than across it, with at least four hours of working-day overlap. Asynchronous handoff is a poor substitute for being awake at the same time as the people asking the questions.
Decisions are written down
An architecture review ends in a recommendation carrying its costs, its risks and the dissenting view. What you keep afterwards is the reasoning, not just the conclusion — which is what makes the decision reviewable a year later.
The work is yours
The source, the infrastructure definitions, the runbook and the decision records. Leaving should be a commercial decision rather than a technical one.
The edges
What we turn down.
A company is described more precisely by the work it declines than by the work it advertises. Each of these is stated somewhere else on this site as part of an argument; here they are together.
A chain where a database would do
Distributed ledgers earn their cost when parties who do not trust each other need to agree on a record. When that condition is absent, the honest recommendation is the boring one, and we make it.
A model with no evaluation set
Anything that demonstrates well and cannot be measured is not ready, whatever the demonstration looked like. If there is no agreed way to tell whether it is working, there is no launch.
A rebuild when the problem is the content
Sites are often slow, unclear or unfindable for reasons no redesign fixes. Selling a rebuild into that produces an expensive version of the same problem.
A technology choice made on your behalf
We will argue for one, with the cost and the risk and what you would give up. The decision stays yours, because you are the ones who have to maintain the result.
Work we cannot staff properly
Taking on more than can be covered is how delivery dates start moving. Declining is cheaper for both sides than a schedule that slips twice before anyone says so.
How it runs
What an engagement actually looks like.
No account layer between you and the people doing the work.
An engineer on the first call
The conversation starts with someone who can talk about the constraint you are describing, not someone who will relay it onward.
A scope that names what is excluded
Anything that only lists inclusions is a scope that will be argued about later. What is out is written down as carefully as what is in.
Working software rather than status
Progress shown as something running. A report describing progress is not evidence of it.
A handover that assumes we leave
Runbook, decision records, reproducible environments and an access map, prepared whether or not anyone intends to use them.
Languages
English and Arabic, to the same standard.
Not a translated site with a flipped stylesheet. The layout mirrors, the typography changes, the fonts are loaded separately and the Arabic is written rather than converted. The page you are on is the demonstration, in whichever language you are reading it.
The rest is on the call.
Describe what you are building and the constraint around it. If it is work we should decline, that will be the answer rather than a proposal.