When the work has outgrown a spreadsheet and no product on the market fits the way you actually operate, you build. We design and build web applications — customer portals, operations dashboards, booking and approval systems, internal tools — in Arabic and English, connected to the systems you already run, with the source code yours.
A website publishes; a web application does work. The difference is not how it looks but what it holds: users who log in, records that change, permissions that decide who sees what, and rules that have to hold even when two people act at once. A brochure site can be rebuilt in a fortnight if it goes wrong. An application carries your operating data, so how it is built decides what it costs you for years.
The usual trigger is not ambition, it is friction. A process runs across four spreadsheets and a WhatsApp group; the same figure is typed into three systems and disagrees in all of them; a customer asks for a status update and someone has to go and ask three people. At that point the cost of the workaround is already being paid every month — building simply makes it visible.
Build is not always the right answer, and we will say so. If a packaged product covers eighty per cent of what you need and the remaining twenty is preference rather than principle, buying it and configuring it wins. Where custom genuinely pays is the part that is specific to you — the pricing logic, the approval chain, the way your industry is regulated — and the honest shape of many projects is a bought system with a custom layer where the difference actually lives.
Building for this market adds two requirements that are easy to postpone and expensive to retrofit. The interface has to work right-to-left as a first-class layout — not a mirrored afterthought — because most internal users will run it in Arabic; and the data model has to handle Hijri dates, Arabic names with their many spellings, and national ID formats from the start. Retrofitting RTL into a mature application is one of the more painful pieces of work we get asked to do.
A place your customers, dealers or suppliers log in to see their own orders, documents, balances and requests — so the questions your team answers by phone answer themselves. Roles and permissions designed so nobody sees another account’s data.
One screen that pulls from the systems where the numbers actually live, with the definitions agreed once so finance and operations stop arguing about whose figure is right. Exports and scheduled reports in Arabic and English.
Requests, quotations, approvals and hand-offs with the rules enforced by the system rather than by memory — who can approve what, at which value, in which order — and a full audit trail of who did what and when.
Appointments, resources, capacity and staff calendars, with reminders over the channels people here actually read. Built around the awkward cases — double-booking, reschedules, no-shows and cancellation rules — because those are the ones that cost money.
Connections to your ERP or accounting system, payment gateways, carriers, SMS and WhatsApp, and any government or partner interface you depend on — built to survive the other side being slow or down, and documented so the next developer is not guessing.
Deployment on infrastructure that suits your data-residency position, backups that have been restored at least once in a drill, monitoring that pages a human, and an agreed response time — because an application without an owner degrades quietly.
We sit with the people who do the work today and map the process as it actually runs, including the workarounds. Then we agree what the first release must do to be worth using — and what is deliberately out.
A clickable version of the main screens in Arabic and English, put in front of real users before anything is built. Changing a screen at this stage costs an afternoon; changing it after launch costs a release.
We ship one working slice at a time to an environment you can open, so you are reacting to software rather than to status reports. Automated tests on the rules that matter, and a review at the end of each slice.
Data migrated and reconciled, users trained in their own language, permissions checked role by role, and a fallback plan for the first week. We usually run the old process alongside for a short overlap rather than switching everything overnight.
Monitoring, backups, security updates and an agreed support window — plus a standing rhythm for the changes that will come, because every application that gets used generates requests. What we do not do is disappear at handover.
A website mostly shows the same content to everyone and changes when someone edits it. A web application gives each user their own state: they log in, the data they see belongs to them, their actions change records, and rules decide what they are allowed to do. That difference drives everything else — an application needs a data model, roles and permissions, an audit trail, backups you have actually tested, and a plan for what happens when two people edit the same record. It is why the two are quoted and maintained differently, and why an application built like a website tends to fail in its second year rather than its first.
Yes. The code, the database schema and the deployment configuration are yours, in your own repository from the first commit rather than handed over as a zip file at the end. That matters more than it sounds: it means you can have the work audited by someone else, take it to another team, or hire in-house without renegotiating anything. We document the architecture, the environment variables and the deployment steps as part of delivery. Third-party licences — a paid library, a mapping service, a font — stay under their own terms, and we list them explicitly so there are no surprises.
Start from where it is used and what it needs from the device. Work done at a desk or on a laptop, by staff, partners or corporate customers, belongs on the web: one codebase, instant updates, no app-store review between you and a fix. Go native when you need the camera, background location, offline use in the field, or push notifications people genuinely act on — a delivery driver, a field technician, a consumer app you want on the home screen. A very common answer is both: the full system on the web, and a focused mobile app for the one job that happens away from a desk. We would rather scope that honestly than sell two builds.
Usually, and the first question is what the other side offers: a documented API, a database we can read, a file drop, or nothing but a screen. Each of those has a different cost and a different reliability, so we check before promising. Two things then decide whether the integration lasts. First, which system owns each piece of data — if two systems can both edit a customer record, they will eventually disagree, so one has to be the source of truth. Second, what happens when the other side is slow or down: queues and retries rather than a form that fails in the user’s face. We also plan for the integration that is not available yet, so a missing connection does not block the whole build.
Every application needs an owner, and you choose whether that is us or your team. If it is us, we agree a support arrangement in writing: response times by severity, a monitoring setup that alerts a person rather than a dashboard nobody watches, security and dependency updates, backups verified by an actual restore, and a monthly window for small changes. If it is your team, we hand over documentation, a walkthrough of the architecture and the deployment, and stay available for a defined transition period. What we advise against is the third option people drift into by default — nobody owns it, updates stop, and the first real problem arrives as an outage.
Book a short call and we will come back with a clear plan and a realistic budget — in Arabic or English.
Talk to us
