What we do

We start from the question the product answers, not from the first screen. We map the flows and specify the states nobody enjoys drawing — empty, error, loading, partial permissions — before anything gets coloured in.

What you receive

A design system you can build from: colour, spacing, radius and type-scale tokens; a component library where every component carries its full set of states; and layout rules at each breakpoint. Delivered in Figma and in code, using the same names in both, so nobody has to translate between “primary blue” and --primary.

Arabic-first

Right-to-left is not a mirror transform. Logical spacing, icon placement, arrow direction, how numerals sit inside an Arabic sentence, and typefaces whose letters join and therefore cannot be letter-spaced — these are design decisions made on day one, not in the last week. We design for both languages together and test both before handover.

Visual identity

Logo, colour, type, and a written usage system: where each colour is used, where it is not, and the minimum contrast it has to hold. You get the full source files. We keep nothing that would make you come back to us to change the colour of a button.

We write software another team can take over. That constraint changes the daily decisions: clear names, explicit boundaries between modules, and decisions recorded in the repository rather than in somebody’s head.

From the schema to the screen

Types start at the database schema and travel through the API to the component. Change a column and the build breaks where it should break — on your machine, not on a user’s a month later.

Testing and deployment

Unit tests for logic, integration tests for the paths that touch the database, and end-to-end tests for the journeys whose failure would stop the business. All of them run in CI on every pull request. Deployment comes from a pipeline rather than a laptop, and rolling back is one command.

How we choose

We pick boring and proven in the places that cannot afford surprises, and we choose for what your team can hire for and maintain rather than for what is fashionable this year. The specific choices, and the alternatives we rejected, are written down for you during discovery — they belong in your decision log, not on a marketing page.

Mobile

A website that behaves like an app when the browser is enough, a native app when you genuinely need what the device can do. We tell you which one is sufficient before we build — including when that is the cheaper answer.

Systems we did not write

Most software work is not a blank page. We take over systems built by someone else, and we do it as a matter of course rather than as an exception. That starts with an assessment: we read what exists, talk to whoever runs it, and tell you what is worth keeping, what is costing you every week, and what is simply not to our taste and can be left alone. You get that assessment as a written document whether or not you then ask us to change anything.

We will also say when the honest answer is that the system should be replaced rather than continued, and roughly what that would involve.

Arabic and English, built together

Building for both languages is not translating strings. It is a layout decision that touches every screen: the interface has to work read right-to-left and left-to-right, numerals and product names sit inside sentences running the other way, and typefaces that join their letters cannot be spaced like Latin ones. Retrofitting this at the end is where it becomes expensive.

We build both directions from the first design. This site is the demonstration — you are reading one of its two locales, and the other is not a translation layer bolted on afterwards.

Most bad technical decisions were not wrong on the day they were made. They were unwritten. A year later the people who made them have moved on, the system has no explanation, and the next team treats it as a puzzle rather than as a choice.

A decision log

We write each architectural decision on one page: what the problem was, which alternatives were considered, why this one was chosen, what we accepted losing in exchange, and what would make us revisit it. Those pages live in your repository and are yours.

Reviewing an existing system

We read the code, the pipeline and the database, and we talk to the people who operate it daily. You get a report that separates three things: what must be fixed now because it is a risk, what costs you time every week, and what is simply not to our taste and can be ignored. That last category is the important one.

Choosing technology

We help you choose what your team can hire for and maintain, rather than what is fashionable this year. Sometimes the recommendation is to buy something off the shelf and build nothing. We say so when it is true.

Whether we are the right people

If the problem is organisational rather than technical, we will tell you early. The first discovery week is designed to surface exactly that, before you commit a build budget.

Excellent content is worth nothing on a site search engines cannot read. We start at the technical layer because it is the layer a developer owns rather than a writer, and it is the one usually neglected.

The technical foundation

A title and description per page, a canonical link, structured data, a sitemap with real modification dates, a robots file, and correct language alternates. Before any of that: pages rendered on the server or built ahead of time, because content that only appears after JavaScript runs may never be indexed at all.

Arabic and English

Search intent differs between the two languages, and keywords are not translations of each other. We build a distinct set for each and connect the two versions with correct alternate links so they do not compete for the same ranking.

Measurement

Cookieless analytics with no personal data — enough to know which page is working, without imposing a consent dialog on your visitors. Results are measured in qualified enquiries, not visits.

What we do not do

We do not buy links, publish bulk generated content, or promise a first position. Those borrow time and then cost more than they brought in.