What is a web application, and how is it different from a website?

A website is read and a web application is worked in. The practical difference is the login: a website serves the same pages to everyone, and an application has to know who signed in, what that person may see, and whose records those are. That one requirement is where most of the cost sits, which is why the two are quoted so differently for what looks like similar work. One warning on vocabulary: "portal" here means something we build for your customers or partners, not a government submission portal, and the limits of automating those are a different subject on the Dubai page. The wider question of what belongs in software at all is the pillar’s.

Our customers are UAE residents. Can they sign in with UAE PASS?

Yes, and it is worth being precise about what that buys you. It answers who the person is; it answers nothing about what they may then see, which remains yours to model and is most of the build. Practically, it is an onboarding rather than a switch: a private entity applies with its trade licence, the onboarding team is assigned by the emirate the entity is registered in, and the request asks for a workflow diagram of the journey and mockups of it before the use case is evaluated. So the design work is a dependency of somebody else’s approval rather than a later phase. What that does to a launch date is set out on the website development page, which is where the schedule argument belongs.

Does it need an Arabic version, and is that a second project?

It is one project or it is written down as excluded, and the second is a legitimate answer. Arabic in an application is not a translation pass at the end: the layout mirrors, so the navigation, the tables, the forms and the empty states are all part of it, which is exactly why the cost guides on this subject name bilingual support as a driver while the service pages beside them stay quiet. Built as one component set it is a direction rather than a second front end. Built as a duplicate it is two products, and the Arabic one falls behind first. Ask any quote which of those it assumes.

Our staff sit across two licensed entities. Can access be split that way?

Yes, and it has to be decided before the schema rather than after. A group running a mainland company alongside a free zone entity is running two separate trading persons, not two departments, and a free zone entity generally reaches mainland customers through a branch, a dual-licence branch or a permit rather than directly. So which entity a record belongs to is a property of the record, and it decides who may act on it before any job title does. Modelled at the start, adding a third entity is configuration. Added afterwards, it means revisiting every screen and every query, which is the migration people postpone until an audit forces it.

How long does a first version take, and what do we see first?

You see the access model in the first three weeks, and it is a table rather than a screen. That is deliberate: it is the one artefact everything else is priced against, and it costs a meeting rather than a sprint to argue with. Screens follow, in both scripts together where the engagement funds the second. A first version that does one job properly for one audience is a better place to arrive than five jobs done thinly, because the first grows by extension and the second grows by rewrite.

Do we own the code, and what happens if we stop working with you?

You do, and the accounts matter as much as the repository. Hosting, the domain, the identity registration and the cloud account are the ones that quietly end up in a supplier’s name, and they are the ones that make leaving expensive. We open them under your entity at the start rather than transferring them at the end. The written access model goes with them, because an application whose permission rules exist only in somebody’s head is not really handed over, whoever holds the source code.

How much does a web application cost in the UAE?

It is driven by three things, and none of them is the number of screens. How many distinct kinds of person sign in, because each one is a separate set of permissions to model and test; whether the second script is in scope; and whether anything it has to talk to is a system somebody else controls. A portal for one audience in one language is a different order of work from an application several audiences use across two entities in two scripts. We will put the drivers on the table with the number rather than a band, and if the honest answer is that you need an app instead, or no login at all, you will get that first.

Web application development · UAE

Web applications your customers and staff log into.

A website is read. An application is worked in, which is why the login is the expensive part: who the person is, what they may see, and whose records those are.

Tell us who signs in

What a web application is

What web application development is.

A web application is software people work inside, reached in a browser and entered by signing in. The login is not a feature of it, it is what the build is shaped around.

Built to be worked in.

A website is visited and a web application is worked in, often for hours a day by the same people. That inverts every design decision: the screen is a tool rather than a page, and the measure of it is how fast somebody who uses it daily gets through the task.

The login is most of the work.

Signing somebody in is a rail you integrate. Deciding what they may then see is a model you write, and it has three parts here: who the person is, what their role permits, and which entity’s records they are allowed to act on at all.

It grows without a rewrite.

A second user type, a second entity or a second language should be an addition rather than a rewrite. What decides that is whether the access model was written down first, because retrofitting one means touching every screen and every query at once.

What gets built

Six applications, by who signs in.

The same six briefs arrive under one name. Which one you are in is decided by who logs in, not by what the screens show.

A customer portal.

Your own customers, signing in to see the work you are doing for them: the order, the case, the job, the statement

Output

the questions that currently arrive by email answered before they are asked

Your customersTheir own records

A partner or supplier portal.

People outside the company, reaching part of a system they do not own, and never each other’s records

Output

a front door onto the system of record, where the platform behind it is a separate engagement

Outside the companyScoped hard

A staff app across your companies.

One application used by people employed by more than one licensed company, where the entity a record belongs to decides who may touch it

Output

an access model that survives the group restructuring

Entity-awareApprovals

An app strangers sign up to.

Nobody invites them and nobody provisions them, which makes onboarding, plans and billing part of the product rather than of an account manager’s week

Output

a different engagement from the ones above, and a separate page when it lands

Self-serveUnattended

A screen people keep open all day.

Installed to a home screen or a desktop, working through a lift and a basement, because the people using it are not sitting still

Output

one build rather than a website and a second thing to maintain

InstallableWorks offline

Replacing a system people log into.

The hard part is not the screens, it is moving the accounts, the roles and the history without anybody losing access on the morning of the switch

Output

a cutover where the same people can still get in

Accounts moveRoles move

Three things get called a web app

A login, a portal, or an application.

All three are quoted against the same brief. They differ on who signs in, and on what it costs to change your mind later.

	A website with a loginPages, behind a password	A portalOne audience, seeing their own records	An applicationSeveral audiences, doing the work in it
Who signs in	Everyone, into the same thing. The password is the whole check.	One audience, each seeing only what is theirs.	Several, and each one sees a different application.
What they can do	Read. Perhaps download something. Very little is written back.	Read their own, and update a defined set of it.	The work itself, including the parts that used to be a phone call.
A second entity	A second login, and usually a second copy of the site.	Awkward. The audience was modelled, the entity behind it was not.	A property of the record, so it was answered before the first screen.
Changing it later	Easy, until somebody needs to see less than everybody else.	A new rule per audience. Fine for two, painful by five.	A change to the model, applied once and enforced everywhere.
When it is right	Documents for members who all get the same thing.	One clear audience, one clear job, and no plan to add a second.	When the work happens in it, and more than one kind of person does it.

Which one we recommend.

Most briefs that arrive asking for an application are describing a portal, and the honest answer is to build the portal properly rather than an application badly. The test is not ambition, it is the second audience: if you can name a second kind of person who will need a different view within two years, model it as an application now. If you cannot, a portal built well will serve for years. And if nobody has to sign in at all, what you want is a website, which is a different job with a different measure.

The UAE context

What a UAE login has to answer.

Webzenia has worked with Gulf clients since 2018. Four things decide the access model, and the first two are most of the build.

01of 04
Who, and then whatTwo questions, one rail answers one
UAE PASS proves who someone is, nothing more.
UAE PASS authenticates. Everything after that is yours to model, and its onboarding asks for a workflow diagram and mockups of the journey before the use case is evaluated, so the access design is an application document. A Jebel Ali freight firm on a JAFZA licence meets this at the first client login.
Our methodAuthentication and entitlement scoped as two pieces of work, in that order.
02of 04
Entity, not org chartAnd it is a property of the record
The company owning a record decides who may touch it.
A group runs a mainland company alongside free zone entities, and a free zone entity generally reaches mainland customers through a branch or a permit under Dubai’s Executive Council Resolution No. 11 of 2025. They are separate trading persons, and a Business Bay brokerage on a DET mainland licence finds that at its second entity.
Our methodEntity modelled as a first-class dimension of access, never as a reporting label.
03of 04
Both scripts, or say soQuoted together, not phased
Arabic is scope, not a later phase.
The cost guides on this subject name bilingual support as a direct driver while the service pages beside them stay silent. Either the Arabic build is in the number or the engagement says plainly that it is not. A Sharjah SAIF Zone manufacturer whose distributors work in Arabic cannot find that sentence in most quotes.
Our methodBoth scripts priced in the same line, or excluded in writing.
04of 04
The stack still differsHowever settled the field looks
Many agencies here still build on decade-old tools.
It is not a detail: the stack decides who can maintain the thing after you, and an application built on a framework nobody hires for is a rebuild with a delay on it. A Dubai Marina clinic that inherited a patient portal nobody local could open has already run that experiment.
Our methodThe stack chosen for who can maintain it, and named in the proposal.

What the engagement covers

Inside a web application build.

Six stages, and the first one is a document rather than a screen. Everything expensive later is a decision that was not taken in it.

The access model, first.

Every kind of person who signs in, from an owner to a partner or an auditor, against what each one sees and which entity’s records each may touch

Output

one table your own team can argue with, and arguing with a table costs a meeting rather than a rebuild

RolesEntities

Arabic and English, designed together.

The screens drawn in English and in Arabic in the same pass, including the empty state, the error and the form, because a layout that mirrors is a design decision rather than a translation

Output

a set engineering can build from, or a written exclusion

MirroredStates

The build, checked on the server.

The work people do daily, built so the check that decides what a person sees runs on the server and in the data rather than in the screen. An action somebody cannot take is refused there, not hidden

Output

an application where hiding a button is not the security model

Server-sideEnforced

Sign-in, wired.

Sign-in through the rail your users actually have, integrated against staging first and assessed before it goes anywhere near production

Output

a working sign-in, and a clear line between what it proves and what it does not

Staging firstAssessed

Permissions, tested by attack.

Every boundary pushed at: another entity’s record requested directly, a partner’s identifier substituted, an expired session reused, a role escalated in the request

Output

a pass or a fail, not a review of the code

Tried, not read

Handover of everything.

Code, repository, hosting, the identity registration and the access model itself, in your accounts and your entity’s name

Output

an application your next developer can pick up without asking us for anything

Your accountsDocumented

Our stack

Built with Next.js and PostgreSQL.

Five choices, each judged on what it decides about who can see what. Select one to see where the check actually happens.

Next.js

Why Next.js

The session and the decision about what a person may see belong on the server, and this is the framework where the server and the screen are the same codebase rather than two.

How we excel

We put every entitlement check on the server, so the browser is told what to draw rather than trusted to decide. A hidden button is a design choice; it has never been a security model.

Check runs on the serverOne codebase, not twoThe check

Server-side, in the frameworkEnforced

In the browser onlyAdvisory

A separate API nobody ownsSplit

Hidden menu itemsNot a model

How the build runs

From the access model to launch.

The first phase produces a table rather than a screen. It is one week of work, and it decides most of what the other twelve cost.

01Weeks 1 to 3Scoped

Modelling who signs in.

We name every kind of person who will sign in and write down what each may see, change and approve, with the entity a record belongs to treated as part of the answer rather than as a field on a report. The identity rail is chosen in the same phase, because its own onboarding wants the journey drawn before it will evaluate the use case, which makes the design a dependency rather than a later stage.

Rolesnamed, not assumed
Entitiespart of the model
Journeydrawn, because it is asked for

02Weeks 4 to 12Built

Building it in both languages.

The application is built with the entitlement check on the server and in the data rather than in the screen, and the Arabic layout is the same components rendered the other way rather than a second front end. Where the engagement does not fund the second script, that is written down in this phase rather than discovered in the last one. The identity rail is integrated against staging.

Checkserver and data layer
Arabica direction, not a fork
Sign-instaging before production

03Month 4 onwardRunning

Trying to break the permissions.

We sign in as each role and try to reach what that role should not: another entity’s record requested directly, a partner identifier substituted, a session reused after it should have expired. A pass is a pass and a fail is a defect, neither is a code review. Then the repository, the hosting, the identity registration and the access model itself move into your accounts.

Entitlementsattacked, not reviewed
Accountsin your entity’s name
Modelhanded over as a document

Every role and every entity written down first, so who sees what is a document rather than a habit.

The access model, in writing

Server-sideTested by attackYour accounts

Our commitment

Four promises about access.

An application fails at the access model and at the handover, rarely at the screens. These four are written into the scope for that reason.

The access model comes first.
Every role, every entity and every approval, in one table your team can argue with before anything is built. Retrofitting entitlement means touching every screen and every query at once, which is why it comes first.
We try to break the permissions.
We sign in as each role and try to reach what it should not: another entity’s record, a partner’s identifier, an expired session. Reading the code proves the code was read. Only the attempt proves the boundary holds.
The code and accounts are yours.
Repository, hosting, the identity registration and the written access model, opened in your entity’s name at the start rather than transferred at the end. The test is whether your next developer can pick it up without asking us anything.
We say when you need no login.
A good share of briefs that arrive asking for an application are a website, a report or a shared document with a process around it. Saying so costs us the project and saves you the one you would have switched off.

Common questions

Web applications, answered.

A website is read and a web application is worked in. The practical difference is the login: a website serves the same pages to everyone, and an application has to know who signed in, what that person may see, and whose records those are. That one requirement is where most of the cost sits, which is why the two are quoted so differently for what looks like similar work. One warning on vocabulary: "portal" here means something we build for your customers or partners, not a government submission portal, and the limits of automating those are a different subject on the Dubai page. The wider question of what belongs in software at all is the pillar’s.
FAQ · 01
Yes, and it is worth being precise about what that buys you. It answers who the person is; it answers nothing about what they may then see, which remains yours to model and is most of the build. Practically, it is an onboarding rather than a switch: a private entity applies with its trade licence, the onboarding team is assigned by the emirate the entity is registered in, and the request asks for a workflow diagram of the journey and mockups of it before the use case is evaluated. So the design work is a dependency of somebody else’s approval rather than a later phase. What that does to a launch date is set out on the website development page, which is where the schedule argument belongs.
FAQ · 02
It is one project or it is written down as excluded, and the second is a legitimate answer. Arabic in an application is not a translation pass at the end: the layout mirrors, so the navigation, the tables, the forms and the empty states are all part of it, which is exactly why the cost guides on this subject name bilingual support as a driver while the service pages beside them stay quiet. Built as one component set it is a direction rather than a second front end. Built as a duplicate it is two products, and the Arabic one falls behind first. Ask any quote which of those it assumes.
FAQ · 03
Yes, and it has to be decided before the schema rather than after. A group running a mainland company alongside a free zone entity is running two separate trading persons, not two departments, and a free zone entity generally reaches mainland customers through a branch, a dual-licence branch or a permit rather than directly. So which entity a record belongs to is a property of the record, and it decides who may act on it before any job title does. Modelled at the start, adding a third entity is configuration. Added afterwards, it means revisiting every screen and every query, which is the migration people postpone until an audit forces it.
FAQ · 04
You see the access model in the first three weeks, and it is a table rather than a screen. That is deliberate: it is the one artefact everything else is priced against, and it costs a meeting rather than a sprint to argue with. Screens follow, in both scripts together where the engagement funds the second. A first version that does one job properly for one audience is a better place to arrive than five jobs done thinly, because the first grows by extension and the second grows by rewrite.
FAQ · 05
You do, and the accounts matter as much as the repository. Hosting, the domain, the identity registration and the cloud account are the ones that quietly end up in a supplier’s name, and they are the ones that make leaving expensive. We open them under your entity at the start rather than transferring them at the end. The written access model goes with them, because an application whose permission rules exist only in somebody’s head is not really handed over, whoever holds the source code.
FAQ · 06
It is driven by three things, and none of them is the number of screens. How many distinct kinds of person sign in, because each one is a separate set of permissions to model and test; whether the second script is in scope; and whether anything it has to talk to is a system somebody else controls. A portal for one audience in one language is a different order of work from an application several audiences use across two entities in two scripts. We will put the drivers on the table with the number rather than a band, and if the honest answer is that you need an app instead, or no login at all, you will get that first.
FAQ · 07

Keep exploring

Explore AI and Automation Services

Part ofAI and Automation Services

AI Consulting

What your licence and data regime allow, ranked and costed.

Custom AI Development

Built where your own data beats a hosted model.

AI Chatbot Development

Answers from your documents, in the Arabic customers write.

AI Voice Agents

Agents that answer your published line, in Arabic and English.

AI Dialers

Outbound calling built inside the telemarketing rules.

WhatsApp Automation

Threads that finish in writing, in Arabic and English.

Business Process Automation

Rewrite the process for this market, then automate it.

Workflow Automation

Wire the two systems either side of the hand-off.

CRM Development

A CRM that knows which of your companies is selling.

Next step

Scope it around who logs in.

Tell us who has to sign in and what they should see. We will come back with the shape of the build, or a straight answer that it does not need a login at all.

Tell us what you need.

What web application development is.

Built to be worked in.

The login is most of the work.

It grows without a rewrite.

Six applications, by who signs in.

A customer portal.

A partner or supplier portal.

A staff app across your companies.

An app strangers sign up to.

A screen people keep open all day.

Replacing a system people log into.

A login, a portal, or an application.

What a UAE login has to answer.

UAE PASS proves who someone is, nothing more.

The company owning a record decides who may touch it.

Arabic is scope, not a later phase.

Many agencies here still build on decade-old tools.

Inside a web application build.

The access model, first.

Arabic and English, designed together.

The build, checked on the server.

Sign-in, wired.

Permissions, tested by attack.

Handover of everything.

Built with Next.js and PostgreSQL.

From the access model to launch.

Modelling who signs in.

Building it in both languages.

Trying to break the permissions.

Four promises about access.

Web applications, answered.

Explore AI and Automation Services

AI Consulting

Custom AI Development

AI Chatbot Development

AI Voice Agents

AI Dialers

WhatsApp Automation

Business Process Automation

Workflow Automation

CRM Development

Scope it around who logs in.