Product development is the practice. Web and marketing exist because products need surfaces to launch on and audiences to reach — they are not separate business lines, and we do not pitch them as such.
End-to-end software product work: discovery through launch and the iteration that follows. This is for applications with real users, real data, and a roadmap that continues after v1 — not one-off builds that get handed over and forgotten.
It is the work we do on our own platforms, which means we have carried the consequences of these decisions ourselves.
Marketing sites, web applications, and commerce builds. Built to be fast, accessible, and maintainable by whoever inherits them — including your own team, if that is the plan.
The area where we have unusual depth is multi-language and multi-market builds. MaatraCare runs 75+ separate localised entry points; Gulf Careers Academy runs eight languages including right-to-left Arabic and Urdu. Getting that right involves script direction, font stacks that cover Devanagari through Amharic, per-locale content models, and URL structure that search engines can index by region. It is a materially different problem from translating a brochure site, and most agencies quote it as if it were the same thing.
Getting the product in front of the people it is for. Content, search, and paid campaigns — reported honestly, including the channels that did not work.
This one works differently from the other two practices, and it is worth being straight about how. Campaign delivery runs through specialist agency partners we work with regularly. We scope the brief, set what success means, oversee the work, and stay accountable for the result. You get one point of contact and one line of reporting, not a second vendor to manage.
Where this fits best is products with a specific audience rather than a broad one. Our own platforms serve diaspora and migrant communities — families supporting parents overseas, workers evaluating a contract in a language that is not English. Those audiences cluster in community groups, regional platforms, and languages most campaign tooling handles badly. Scoping a brief for that is a different job from scoping a mass-market campaign, and it is the part we do ourselves.
We will not promise a traffic multiple or a lead volume before we have seen your baseline. Anyone who does is guessing.
Available on request, usually alongside a build engagement rather than on their own.
A second opinion on a system you already have, or one someone else is proposing to build. Cloud architecture, data model, and the decisions that will be expensive to reverse later.
Assessing a codebase, team, or product before an acquisition or investment — what is actually there, what it will cost to maintain, and what has been deferred.
Every engagement moves through these four stages. Scope changes; the order does not.
What the product needs to do, who it is for, and what success looks like. Written down before anyone writes code.
Interface and architecture together. Data model, integrations, and hosting decided alongside the screens.
Working software in short cycles. You see it running, not in a status deck.
Launch, monitor, fix, extend. Handover documentation if you are taking it in-house.
Send the scope, timeline, and constraints. We'll tell you whether we're the right team for it.