Start with a 'who can do what' matrix, not with screens
Take a spreadsheet. Rows are actions that exist in the system. Columns are types of people. Cells are 'yes', 'no', or 'own only'. This takes an hour and replaces half your specification.
Write actions as verbs, as narrowly as possible. Not 'work with orders' but separately: view order list, view someone else's order, change status, cancel, view cost basis, export to Excel. The difference between 'view orders' and 'view all orders' is often the difference between a working dashboard and a data leak.
Mark cells with 'own only' separately. These cause the most bugs in development because they require a check on every request, not just a checkbox in settings.
- View data - own, own department, all
- Create and edit - own records or any
- Delete - almost always better replaced with 'archive'
- View money: purchase prices, margin, salaries
- Export data as a list - this is a separate permission, not the same as 'view'
- Manage people: invite, change role, revoke access
A role is not a job title and not a specific person
Common mistake: naming roles after employee names or exact job titles from your org chart. Six months later the team changes and you have 'Role for Irene' and 'Manager-2' in the system. A role describes a set of permissions, not a person.
For small and medium businesses, three or four roles cover 90% of cases: account owner, admin, employee, client. Owner is the only one who pays, deletes the account, and transfers rights. Admin does everything work-related but can't kick out the owner. Employee sees only their own area.
If during discussion you think you need seven roles, you probably need three roles and a couple of toggles inside them - for example, 'views purchase prices' as a separate checkbox. This is cheaper to build and clearer to maintain.
And answer the boring question in advance: what happens when someone leaves. You can't delete them - their order history and comments disappear with them. The right answer is deactivate: login blocked, data remains.
Where permissions break in practice
The most common hole is checking permissions only in the interface. The 'Delete' button is hidden, but the server still executes the delete request from anyone. Permissions must be checked on the server, on every request, and this is not optional.
Second - access via direct link. You can test this manually, without a developer: log in as an employee, open your own record, find the ID in the URL (for example, /orders/1043), change it to a neighbouring one and refresh. If someone else's record opens - permissions are broken. Repeat the same test with file links: a contract or passport scan should not open in incognito mode.
Third - exports and notifications. An employee can't see other people's deals in the list, but exports a CSV with the entire database or receives an email with totals for the whole company. These two channels are almost always forgotten in the permissions matrix.
What should be in the dashboard besides permissions themselves
A dashboard lives for years, and half the work with it is administering people, not business tasks. If these things are missing, you'll be calling your contractor for every new employee and paying for work you could do yourself.
Minimum set worth listing as separate items in the specification:
- Invitation by email or link, not 'developer will create user manually'
- Change role and revoke access in one click, without contacting support
- Action log: who and when changed status, price, deleted record
- Self-service password recovery
- Two-factor authentication at least for owner and admins
- Clear 'Access denied' screen instead of white page or error
When you don't need a user dashboard
If you have 10-15 clients and know each one by name, they don't need a dashboard. They need a link to a document, an email with status, or a Telegram bot that answers two questions. A dashboard for ten people is usually buying the feeling of 'we're professional' rather than solving a problem.
Same with employees. If your team has five people and everyone looks at one spreadsheet, access control won't improve anything. A dashboard with roles makes sense when you have dozens of people, when there's data that one person can see and another can't, and when the cost of an access mistake is money or reputation.
An honest contractor at this stage should ask how many users you have and what exactly they do daily. If they immediately propose a dashboard with six roles without asking a single question about your processes - they're selling volume.
What makes user dashboard development more expensive and how to check the estimate
Cost grows not from the number of screens but from the number of 'role × action' combinations. Each 'own only' cell is additional logic and an additional test. So two extra roles can cost more than a whole new section.
Ask for an itemised estimate: roles, permissions, authentication, invitations, action log, integrations - separate lines with estimates. If you get one line 'user dashboard - amount', that's not an estimate, it's a number: you can't compare contractors or remove anything to fit your budget.
And ask two questions before signing: where are permissions checked - on the server or only in the interface, and can I add employees and change their roles myself. The answers tell you more about the contractor than their portfolio.
At EFIMOV DEV we publish 'from' price ranges on our site for each area - websites, online stores, web services with dashboards, Telegram bots, support. We calculate exact estimates after a brief, because without talking about roles and permissions any number would be guesswork, and you'll discuss the project directly with whoever leads it.
Start with a 'who can do what' table - it will determine both the architecture and the price. And ask for an itemised estimate by roles and permissions: one line with a total gives you neither choice nor control.
Frequently asked
How many roles do you need at launch?
Usually three or four: account owner, admin, employee, client. If you want more, first check whether the difference can be described with one or two checkboxes inside an existing role - for example, 'views purchase prices'. This is cheaper to build and simpler to maintain.
Can you add roles and permissions later?
Yes, if permission checking was done on the server and in one place from the start. Then a new role is configuration. If permissions are spread across the interface and different parts of the code, adding a role becomes a rebuild, and that costs money. Ask your contractor about this before starting.
How do you check that permissions actually work?
Log in as a restricted employee and try to open someone else's record by substituting a different ID in the address bar. Then export a report and check whether other people's data ended up in the file. Then copy a link to an uploaded file and open it in incognito mode. Three tests - five minutes.
Is a spreadsheet enough instead of a dashboard?
Often yes, while you have a handful of users and all data can be shown to everyone. A dashboard becomes necessary when you have dozens of people, when some data can't be shown to some employees, or when clients should only see their own. Until then a spreadsheet or bot solves the problem more cheaply.