If your business runs on emailed PDFs and repeat phone calls, a portal looks like the obvious fix. Before you pay anyone to build one, do one thing first: check whether you already own it.
That is the most useful sentence in this guide. ERP, CRM and accounting platforms very often ship a customer or partner portal already, either as a standard feature or as a paid add-on. Odoo, for example, publishes documentation for built-in portal access that you grant per contact from the Contacts app, giving that person their own dashboard of documents on a view-only basis [1]. If the system you already run can show your customers the records they keep asking you for, switching it on is a configuration job. It costs a fraction of a build.
Hardly anyone checks. Buyers describe the screens they want, collect quotes for a new system, and find out afterwards that they were already paying for something close enough.
So this guide starts there, then covers what a portal actually needs, the security questions that decide whether it is safe to put customer data behind it, the UAE rules that apply, and what each route costs.
What people actually mean by portal
The word covers four different things, and quotes go wrong when buyer and developer have different ones in mind.
A marketing website. Public, no login, built to be found. Our website development cost guide covers that band, from around AED 3,500 [2].
A portal behind a login. A known group of people, customers, partners or staff, sign in and see their own data. Orders, invoices, documents, tickets, application status. That is the subject of this article.
A full custom application, where the login is one door into a system that also runs workflow and connects to other systems. Our custom software development cost guide prices that band [3].
A customer-facing module of a system you already own. The cheapest answer, and the one most often missed.
One line settles a lot of arguments. A login that gates a static page is not a portal. If customers can sign in but still have to email you to get anything done, you have built a gated website.
Why a portal costs more than a website
A website presents the same content to everyone. A portal has to know who you are and show you only your own data.
Every expensive part follows from that one difference. User accounts and password recovery. Roles and permissions. A check on every single request that the signed-in person is entitled to the record they just asked for. Secure document storage. Session handling. An audit trail. And an entire second interface for your own staff.
The admin side is half the build
This is the part competitor proposals skip, so read it before you write a brief.
Buyers scope the customer view in careful detail. Then they forget that somebody on their own team has to run it. Who uploads the documents? Who answers the messages that arrive through it? Who approves an application, creates an account, disables one when a client leaves, resets access when somebody is locked out, and checks who opened which record last Tuesday?
Those screens are a second application. They need their own permission model, because a junior staff member should not be able to do everything a manager can. In our own delivery experience the admin side is often close to half the engineering work [4]. That is our observation from building these systems, not an industry statistic, and we say it plainly because a brief that leaves it out will produce an estimate you cannot rely on.
There is a simple test. For every customer-facing screen you describe, write down which member of your team creates or changes the thing shown on it, and where they do that. If the answer is a spreadsheet or a developer running a database query, you have found a missing screen.
What every portal needs, whether the brief mentions it or not
- Authentication and account recovery. Sign-up, sign-in and forgotten password. Recovery is not simply emailing a reset link, because a weak recovery flow is the easiest way into an account.
- Roles and permissions. The moment you have more than one type of user, different people must see different things.
- An audit trail. Who saw what, who changed what, and when.
- Secure document storage. Files retrievable only by the person entitled to them, not merely unlinked from your public site. Our document management guide covers the wider filing question.
- Notifications. Email, SMS or WhatsApp when something changes. Without them nobody logs in and you are back to phoning people.
- The admin side, as above.
Security: the part you cannot see and cannot skip
One customer seeing another customer's records
This is the failure people fear, and they are right to.
Picture a customer signed into your portal looking at their own invoice. The address in their browser ends with an invoice number. They change that number to a different one and press enter. If your portal shows them somebody else's invoice, you have the most common serious flaw in web applications.
OWASP ranks Broken Access Control as the number one category in its current Top 10, the 2025 edition [5]. The example OWASP itself gives is exactly the one above: an attacker modifies an account parameter in the address to send whatever account number they want. The named class of bug is an insecure direct object reference, where an internal identifier is exposed to the user and never checked against that user's permissions [6].
What prevents it is not a better login screen. It is a check on the server, on every request, that the signed-in user is entitled to the specific record being requested. OWASP's guidance is to enforce access control server side and to deny by default, so that anything not explicitly permitted is refused [5]. Nothing that arrives from the browser can be trusted, because anything in the browser can be edited.
Ask your developer how to test it, then test it. Two customer accounts, note the identifiers, try to reach the first account's records while signed in as the second. Do it for file downloads too, which are the most commonly missed.
Logins, passwords and second factors
NIST publishes the reference guidance here, and a lot of common practice contradicts it [7].
Passwords must be salted and put through a suitable one-way key derivation function before storage, with a salt of at least 32 bits and, for PBKDF2, at least 10,000 iterations [7]. If your database is stolen, that is what stands between the thief and your customers' passwords.
NIST also recommends against two habits most portals still have. Verifiers should not require memorised secrets to be changed arbitrarily, such as every 90 days, and should not impose composition rules forcing particular mixes of character types [7]. Both push people towards weaker and more predictable passwords. Force a change where there is evidence of compromise, keep an eight character minimum for user-chosen passwords, and check new ones against lists of commonly used or previously breached values.
On second factors, NIST sets Authentication Assurance Level 2 as the minimum whenever a system exposes self-asserted personal data online, and that level requires proof of possession and control of two distinct factors, such as a password plus a one-time code [7]. A portal holding invoices, contracts or identity documents is exactly that kind of system.
Passkeys are worth adding to the conversation. They are built on WebAuthn, the W3C standard defining an API for creating and using strong, attested, scoped, public key credentials for strongly authenticating users [8]. Because the credential is cryptographically bound to the real site, a convincing fake copy of your portal cannot capture it the way a fake page captures a typed password.
Sessions deserve a line too. OWASP guidance calls for session identifiers with at least 64 bits of entropy, cookies marked Secure, HttpOnly and SameSite, both an idle and an absolute timeout enforced on the server, and a logout that destroys the session server side rather than only clearing a cookie [9].
The audit trail, and why it is not debug logging
These get confused constantly, and the confusion costs money later.
Debug logging exists so a developer can work out why something broke. An audit trail exists so the business can answer a question months later, when nothing is broken at all: who opened this customer's file, and when?
OWASP treats them as separate concerns and recommends keeping them apart, because they serve different purposes [10]. For accountability it recommends recording the date and time in an international format, the identity of the authenticated user, the type of event and a description. The events it specifically calls out include user administration actions such as adding or removing users and changing privileges, any use of administrative privileges or access by application administrators, and the addition, modification, deletion and export of data [10].
This matters enough that Security Logging and Alerting Failures is its own category in OWASP's current Top 10 [11]. Without it, internal misuse of a portal is invisible until somebody complains, and by then you cannot reconstruct what happened.
Our own view, and we flag it as ours rather than a stated rule, is that the audit trail is also the practical mechanism a business uses to answer a customer asking what you hold about them and who has touched it.
The UAE parts
Data protection. The Personal Data Protection Law, Federal Decree-Law No. 45 of 2021, has been in force since 2 January 2022 and applies to the processing of personal data in full or in part through electronic systems, inside or outside the country [12]. A portal storing customer records is squarely within that. Businesses must secure personal data, keep it confidential, and obtain the data owner's consent before processing, with limited exceptions for public interest or legal requirement. The law also sets requirements for cross-border transfer, which is why hosting region is a decision rather than a default, and a national regulator, the UAE Data Office, is designated under it [12].
On individual rights, the official government summary confirms a right to request correction of inaccurate data and a right to request that processing be restricted or stopped [12]. Other rights are described in various secondary summaries, so confirm the full list against the current law text with a qualified adviser rather than relying on a blog. Our PDPL compliance guide covers the wider obligations.
UAE Pass. The official government page describes UAE Pass as the national digital identity and signature solution, and confirms it is required not only for government services but also for services provided by the semi-government and private sectors, naming banking, money exchange and telecommunications [13]. So it is a real option for a private portal serving UAE residents, not a government-only tool.
The official developer documentation sets out the onboarding path: a private entity needs a valid UAE trade licence to begin, then submits an integration request through the UAE Pass developer portal specifying entity type, provides trade licence documentation, and completes questionnaires for each feature it wants along with a workflow diagram of the user journey and interface mockups for evaluation [14]. No fee, no eligibility test beyond the trade licence, and no approval timeline are published, so treat anyone quoting you any of the three as guessing.
What it costs
Three routes, three very different numbers.
| Route | What it involves | From (AED) |
|---|---|---|
| Switch on a module you already own | Configuration, roles, record visibility, any connection needed | 1,500 |
| Custom portal, focused first version | One workflow, a small number of roles, no heavy integrations | 15,000 |
| Custom portal, fuller system | Several roles, integrations, notifications, custom admin side | 60,000 |
Route one is the commercial heart of this article. If your ERP, CRM or accounting package already has a portal module, the work is configuration and connection rather than construction, which puts it in the band from our system and API integration guide: from around AED 1,500 for a standard integration between two systems that both publish an API, and from around AED 4,000 for a complex one with heavy data mapping [15]. Our ERP implementation and CRM implementation guides cover what those systems include.
Route two is a subscription tool. Microsoft publishes Power Pages pricing of USD 200 per website billed yearly, covering 100 authenticated users per site per month, and USD 75 per website billed yearly for 500 anonymous users per site per month [16]. Zoho documents a separate Customer Portal add-on for Creator apps [17] and Salesforce sells Experience Cloud as a dedicated portal product [18], but neither publishes pricing clearly enough for us to quote a figure, so check both directly with the vendor.
Route three is a custom build. Our own custom software guide already names customer and partner portals as one of the categories it covers, so a portal is priced on that same band rather than as a separate product: from around AED 15,000 for a focused first version, rising to around AED 60,000 for a fuller system [3]. We are deliberately not inventing a separate portal price.
Compare that with our published website figure of from around AED 3,500 [2] and the reason for the gap is the one from earlier: the website shows everyone the same thing, the portal has to know who you are.
Final pricing depends on scope.
Real client stories
The portal they were already paying for. A trading company asked us to quote a customer portal so clients could pull their own invoices and delivery notes instead of phoning. Their accounting and operations platform already included a portal module nobody had switched on. We configured it, set up which contact saw which documents, and connected one report that was not exposed by default. No build, and a bill closer to an integration than a system.
The brief with no back office. A services business sent a detailed specification for a client portal. Every screen described what the customer would see. Nothing described how documents got in, who approved a request, or how an account was closed. Adding the staff side roughly doubled the honest estimate. We now start portal scoping from the admin screens and work outwards, because the customer side is the half everyone can already picture.
The identifier in the address bar. A business inherited a portal from a previous developer and asked us to look at it before adding features. Changing a number in the address of a document link returned another customer's file, and no log recorded that it had happened. Fixing the permission checks and adding an audit trail came before any new feature. It is the first thing we now check on any system we take over.
How SKIMBOX approaches portals
We ask what you already own before we quote anything, because switching on a module you are already paying for is often the right answer and it is a much smaller invoice. When a build is genuinely the right route, we scope the admin side in the same detail as the customer side, put access control checks and an audit trail in the first version rather than a later phase, offer a paid discovery that leaves you with documentation you own, and commit code to a repository in your name.
Switching on and configuring a portal module in a system you already run starts from around AED 1,500. A focused custom first version starts from around AED 15,000, with a fuller system around AED 60,000. Final pricing depends on scope.
See our web development services and product engineering services, or contact us to talk through which of the three routes fits your situation.
For related reading, see our guides on custom software development cost in Dubai, system and API integration, and booking and appointment systems in the UAE.
References
[1] Odoo - Official documentation, Portal access. odoo.com/documentation/19.0/applications/general/users/portal.html
[2] SKIMBOX - Website development cost in Dubai. skimbox.co/resources/blogs/website-development-cost-dubai
[3] SKIMBOX - Custom software development cost in Dubai. skimbox.co/resources/blogs/custom-software-development-cost-dubai
[4] SKIMBOX - Internal delivery experience building portals for UAE businesses, 2026. skimbox.co
[5] OWASP - Top 10:2025, A01 Broken Access Control. owasp.org/Top10/2025/0x00_2025-Introduction
[6] OWASP - Insecure Direct Object Reference. owasp.org/www-community/attacks/insecure_direct_object_reference
[7] NIST - Special Publication 800-63B, Digital Identity Guidelines. pages.nist.gov/800-63-3/sp800-63b.html
[8] W3C - Web Authentication (WebAuthn) Level 3. w3.org/TR/webauthn-3/
[9] OWASP - Session Management Cheat Sheet. cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
[10] OWASP - Logging Cheat Sheet. cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
[11] OWASP - Top 10:2025, A09 Security Logging and Alerting Failures. owasp.org/Top10/2025/0x00_2025-Introduction
[12] U.AE Official UAE Government Portal - Data protection laws, Federal Decree-Law No. 45 of 2021. u.ae/en/about-the-uae/digital-uae/data/data-protection-laws
[13] U.AE Official UAE Government Portal - The UAE Pass. u.ae/en/about-the-uae/digital-uae/digital-transformation/platforms-and-apps/the-uae-pass-app
[14] UAE Pass - Official developer documentation, onboarding process for service providers. docs.uaepass.ae/getting-onboarded-with-uae-pass/onboarding-process-for-uae-pass-service-providers/initiation-phase
[15] SKIMBOX - System and API integration in Dubai. skimbox.co/resources/blogs/system-api-integration-dubai
[16] Microsoft - Power Pages pricing. microsoft.com/en-us/power-platform/products/power-pages/pricing/
[17] Zoho - Creator pricing, Customer Portal add-on. zoho.com/creator/pricing.html
[18] Salesforce - Experience Cloud pricing. salesforce.com/products/experience-cloud/pricing/
