How we work
There is a kind of agency that takes every brief, routes it to whoever is free, and returns something that satisfies the document. We are not that, and the difference shows up in who you deal with, what we agree to do, and what you own at the end.
Six things you can hold us to, which is the point of publishing them.
- You deal with the people doing the work
- There is no account layer between you and the practice. The person who reads your system is the person you argue with about it, and they stay on the engagement to the end. That is only possible because we take on few engagements, which is a constraint we accept rather than a scarcity tactic.
- We write the specification, not you
- Requiring a founder to produce a fifty-page brief before anyone will think about the problem transfers the hard part to the client. We work the other way round: a conversation, our own reading of the system, and a written specification you correct rather than compose. What comes out is a blueprint — complete enough to build from, and complete enough that you could hand it to someone else and they would build the same thing.
- We say when something isn’t needed
- If a channel will not produce customers for you, we say so, even where running it would be billable. If the feature you asked for solves a symptom, we say which cause it is standing in front of. And if the honest answer is that you do not need us at all, that is the answer you get — it costs us one engagement and is the only reason our recommendations are worth reading.
- Everything transfers, from day one
- Source, infrastructure, accounts and domains are in your name from the first commit, not migrated at the end. Documentation is written for the engineer who arrives after us. Every engagement closes with a handover session and a system your team can run — including the case where the next thing they run is a different supplier.
- We turn work down
- Not out of theatre — because depth and volume are genuinely in conflict, and because taking a project we are wrong for damages the client more than it helps us. If your product can be described as simple, we are probably not the right fit, and we will say so quickly rather than expensively.
- One firm across the whole problem
- Architecture, engineering, interface, marketing, search, process and the legal reading of a deal sit under one entity, licensed for all of it. Not because breadth is impressive, but because the seams between four suppliers are where the accountability disappears.
Access
Intake
Candour
Continuity
Selection
Range
From a first conversation to being rid of us.
- 01
A conversation
Thirty to sixty minutes with the owner or the executive who holds the problem. No brief required. By the end of it we can usually name the class of problem, and sometimes the problem.
- 02
A written diagnosis
We restate the problem in writing, including what we are not sure about. If our reading is wrong, this is the cheap place to find out.
- 03
A scoped proposal
What we would do, in what order, what it costs, and what it depends on from your side. Where the honest answer is a seventy-two hour audit before anything larger, that is what we propose.
- 04
The work, in stages
Delivered so that value lands before the last stage does. You can stop at a stage boundary without holding something half-built.
- 05
Handover
Documentation, access, a working session with your team, and a defined period where we answer questions. The engagement ends with you independent of us.
Invariant
The engagement ends with you independent of us. That is the deliverable.
A large agency solves for throughput: a repeatable intake, a documented brief, an interchangeable delivery team. It is a rational design, and it produces work that satisfies the document rather than the problem — because by the time the document exists, the thinking that mattered has already been done, badly, by whoever wrote it.
We solve for depth instead, and pay for it in volume. Fewer clients, senior people on the actual work, and an obligation to say the inconvenient thing. It does not scale, and that is not an oversight.
- Do we need to prepare a brief or a specification first?
- No. Bring the problem in whatever form it currently exists — a frustration, a number that stopped moving, a system nobody trusts. Writing the specification is the first part of the work and it is ours. You receive a blueprint that can go straight into production, whether we build it or somebody else does.
- Who owns the specification you produce?
- You do, unconditionally. It is written to be built from by any competent team, which is deliberate: a specification that only its author can execute is a lock-in mechanism, not a document.
- Who will we actually be working with?
- The practitioners. There is no account manager and no delivery pod you get handed to after signing. It is the direct consequence of running a small number of engagements at once.
- What happens to the code and the accounts at the end?
- They were yours throughout. Repositories, infrastructure, domains and third-party accounts are created in your name at the start, so there is nothing to hand back — only to hand over, with documentation and a session for your team.
- Will you tell us if we don’t need something?
- Yes, including when it is something we sell. Directness is the whole basis on which advice from a supplier can be trusted, and we would rather lose a line item than the standing.
- Do you work with clients outside the UAE?
- Yes. The practice is UAE-licensed and most engagements are UAE, GCC or the corridor between the Gulf and the CIS. We work in English, Russian, Spanish and Arabic.
Bring the problem in whatever shape it is in.
No brief required. A conversation is enough to establish whether there is something here for us to do — and we will tell you if there is not.