Web application development in Saudi Arabia
Software that does the work — not a website that describes it.
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.
Same screen. Different people.
Sees everything, and can change the rules themselves.
- Approve at any valueallow
- Edit any recordallow
- Export the full ledgerallow
- Change who can approveallow
Runs the day. Can act; cannot rewrite the rules.
- Approve up to a set limitallow
- Edit records in their branchallow
- Export the full ledgerdeny
- Change who can approvedeny
Their own account — and nothing else’s.
- See their own ordersallow
- Raise a requestallow
- See another accountdeny
- Approve anythingdeny
A website publishes. An application works.
A website publishes. A web application does work. What changes between them is not the look — it is what the thing holds.
- Shows everyone the same content
- Gives every user their own state
- Changes when someone edits it
- Changes when a user acts on a record
- No login, no roles
- Logins, roles, permissions, an audit trail
- Rebuild it in a fortnight if it goes wrong
- Carries your operating data for years
- One person at a time is fine
- Must hold when two people act at once
Which 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.
What is a web application — and when do you need one?
- What it holds
- 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.
- When you actually need one
- 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.
- When not to build
- 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.
- What this market adds
- 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.
One source of truth, each.
An application is rarely alone. What decides whether an integration lasts is which system owns each piece of data — and what it does when the other side is slow or down.
Owns the process it was built for — and nothing it is not the source of truth for.
ERP / accounting
Owns the ledgerWhen it is downQueue and retryPayment gateway
Owns what actually settledWhen it is downReconcile, never assumeCarriers
Owns the shipmentWhen it is downRetry, then flag a humanSMS & WhatsApp
Owns delivery statusWhen it is downQueue; never block the userGovernment & partner portals
Owns the record held thereWhen it is downCache the last good readIdentity & single sign-on
Owns who the user isWhen it is downFail closed, never open
We also plan for the integration that is not available yet, so a missing connection does not block the whole build.
The things people log into.
Customer & partner portals
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.
Dashboards & reporting
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.
Workflow & approval systems
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.
Booking & scheduling
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.
Integrations & APIs
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.
Hosting, security & support
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.
Slice by slice. Never a big reveal.
- The process as it actually runs
Discovery
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.
- Clicked by real users first
Prototype
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.
- An environment you can open
Build in slices
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.
- A fallback plan for week one
Launch
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.
- An owner, in writing
Run & evolve
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.
One system, every branch.
An application is the one thing a multi-branch business can genuinely run from a single place — provided permissions are drawn per branch rather than per person, which is the part that gets skipped and then rebuilt.
- Jeddahجدة
- Riyadhالرياض
- Makkahمكة المكرمة
- Madinahالمدينة المنورة
- Dammamالدمام
- Khobarالخبر
Before you commission a build.
What is the difference between a website and a web application?
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.
Do we own the source code?
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.
Should we build a web app or a mobile app?
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.
Can it connect to the systems we already run?
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.
What happens after launch — who maintains it?
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.
- Jeddah
- Riyadh
- Makkah
- Madinah
- Dammam
- Khobar
Describe the workaround.
Tell us the process that currently runs across four spreadsheets and a WhatsApp group. We will come back with what the first release would have to do to be worth using, what it would connect to, and whether you should build it at all.
- Free, no-obligation proposal
- Reply within one business day
- A bilingual Arabic & English team
- 9+ years serving brands across Saudi Arabia
Request a free proposal
Tell us about your brand — we reply within one business day.