Mobile and web products
Built for the person who has to use it forty times a day.
A product used by staff is judged on its worst screen, not its best one. We design around the busiest hour: the front desk at capacity, the driver at the door, the coach with a class waiting.
What usually goes wrong
Products get built for the demo and then meet reality: the network drops, the name has three spellings, the price came from another system and does not match, and the Arabic was added at the end so the layout breaks. Each of those is a decision made too late.
How we build them
Arabic is the starting point
Right-to-left is the default layout, not a mirrored afterthought. Latin numerals, correct plural forms, and terminology from the trade rather than from a dictionary.
Roles before screens
We model who does what first. A product with five kinds of user is five products sharing one ledger, and treating it as one is why staff screens end up unusable.
The real state, not the happy path
Empty, loading, partial, offline, failed, and conflicting. These are designed with the same care as the main flow, because they are what people actually hit.
Fast on the phone people own
Budgets on load and interaction, set at the start and measured on a mid-range device rather than on a laptop.
How an engagement runs
Three stages. Nothing reaches a designer before the roles and the records are agreed.
Roles, records and the busiest hour
Who does what, what each of them is allowed to see, and what the system looks like when everything arrives at once. Agreed in writing before a screen exists.
The first role, shipped
One kind of user gets a complete product rather than a prototype or a slice with placeholders in it. They use it in real work while the second role is being built.
The rest, then the handover
The remaining roles, the states nobody demonstrates, and a component library your next developer can read. The repository has been yours since the first commit.
What you get
- A domain model and a role map agreed before design starts.
- The product itself, in both languages, with no screen left as a placeholder.
- A component library and design tokens your next developer can pick up.
- Accessibility to a stated standard, including keyboard use and screen readers.
- The repository, the pipeline and the documentation, in your accounts.
What you own at the end
The repository, the design tokens, the component library, the pipeline and the store entries, all in your name. Nothing is published under a developer account of ours, because a product you cannot release without us is not a product you own.
What we will not do
We will not ship a language as a checkbox. If the budget only supports one language done well, we will say so and build one properly rather than two badly.
Questions buyers actually ask
The four that usually decide the shape of the first release.
Should this be an app or a website?
How do you keep the Arabic from reading as a translation?
Who maintains it after launch?
Can you take over a product somebody else started?
Usually paired with
A product is a front for something. The integration and the operations behind it are the part that decides whether it survives its second year.
AI agents
Systems that read what comes in, decide inside limits you set, act in your software, and hand the case to a person when they should.
AI agents in detailAutomation
The manual steps between systems: intake, matching, approvals, reconciliation, the report someone rebuilds every morning.
Automation in detailWhatsApp systems
Threads where a booking, a payment or a reschedule actually completes, writing to the same records as the app.
WhatsApp systems in detailIT delivery
Integration with what you already run, deployment into your environment, and operating the system after launch.
IT delivery in detail
Show us the screen your team hates.
The worst-used screen in your current system tells us more than a requirements document.
Our WhatsApp line is being connected. Email reaches us today.