Customer Portals and Dashboards: What Matters in Development

A customer portal long ago stopped being just a "profile page." Today it is a workspace for a client, partner or employee through which money, documents and personal data flow. A mistake in portal architecture costs more than a mistake on a landing page: here you don't break conversion, you break trust, and sometimes the law. Below is what we at OneDev look at first when designing a customer portal or corporate dashboard.

Roles and permissions: the foundation, not an afterthought

The most common mistake is to start with screens and bolt on the role model at the end. The result is a system where "the admin can do everything" and everyone else gets access granted manually and chaotically. Six months later no one remembers why the accountant has access to integration settings.

The right approach is to describe roles through permissions in advance, not through rigid "job titles." A role is a set of permissions for actions and objects. Then you assemble a new position from ready-made building blocks instead of rewriting code.

• RBAC (role-based access) covers 90% of B2B portals: operator, manager, accountant, owner.
• ABAC / scoping is needed when access depends on the data: "a manager sees only their branch," "a partner sees only their own clients."
• Multi-account and delegation: one person works across several organizations, an owner hands rights to a deputy.

Portal UX: speed and predictability over beauty

A portal is used every day and for long sessions; it is not a showcase for a first impression. What matters here is not the "wow," but that a person completes a task in the fewest clicks and isn't afraid to press a button.

What we focus on in practice:

• Clear navigation and state. The user should always see where they are, what is loading, what was saved and what wasn't.
• Empty states and onboarding. A new client shouldn't face a blank screen with no hint about the first step.
• Human-readable errors. Not "Error 500," but what happened and what to do. Especially in payments and document uploads.
• List performance. Thousands of rows means pagination, server-side filtering and caching, not "load everything and filter on the frontend."
• Mobile and language. In Uzbekistan a portal is often opened from a phone, and the interface needs at least two or three languages (Uzbek, Russian, English). Localization is built in from the start, not patched on later.

Integrations: a portal rarely lives on its own

A portal is almost always a node connected to other systems. For the Uzbekistan market a typical set of integrations looks like this:

• Payments: Payme, Click, Uzum, bank acquiring. It's important to process webhooks correctly and reconcile statuses, rather than trusting a single response from the frontend.
• Document flow and taxes: Didox, e-invoices (EHF), exports for accounting.
• Identity: OneID, SMS providers (Eskiz, Play Mobile), and where needed verification by national ID.
• Internal systems: 1C, CRM, ERP, warehouse and logistics services.

The main rule of integrations is isolation. An external service may slow down, change its response format or go down temporarily. The portal must not fall with it. That means queues, retries, timeouts and idempotency of payment operations, so a duplicate webhook doesn't charge money twice.

Security: personal data and money in one place

A portal concentrates sensitive things: contacts, documents, payment data, sometimes third-party data. A basic but mandatory set of measures:

• Authentication. Robust sessions, brute-force protection, optional two-factor for roles with access to money and settings.
• Authorization on every request. Permission checks must live on the backend for each action, not "we hid the button on the frontend." A hidden button is not protection.
• Data isolation between tenants. In multi-account portals the most dangerous class of bugs is when one client sees another's data via a direct link or ID tampering. This is verified at the database query level.
• Encryption and secret storage. Tokens and keys belong in secure storage, not in code or git. Traffic over HTTPS only.
• Data minimization. Don't collect or store what you don't need; what isn't stored cannot leak.

Audit and observability: seeing what happens

When money and documents move through a portal, sooner or later the question arises: "who did this and when?" Without an action log there is no answer, and a dispute with a client or employee turns into one person's word against another's.

• Audit log: who changed what, when and from which device. Especially for payments, access rights and changes to bank details.
• Immutability of records: logs cannot be edited from within the portal itself, otherwise they lose evidentiary value.
• Monitoring and alerts: errors, spikes in payment failures, integration outages — better to learn from the system than from an angry client.
• Product metrics: what is actually used, where people get stuck. This is the basis for evolving the portal, not guesswork.

Audit is also a support convenience: when a client writes "my payment didn't go through," the log shows exactly what broke, without guesses or long back-and-forth.