How to plan an admin dashboard or internal business application

Dashboards fail when they show everything and help with nothing. Before thinking about layouts, write down the questions people need answered and the actions they need to take. For example: “Which orders are late today?”, “Approve this week’s leave requests”, “Which customers have not paid?”.

Each question becomes a view, and each action becomes a button or a form. Anything that does not support a real question or action can wait.

Internal tools almost always have several kinds of user: administrators, managers, staff and sometimes customers or partners. For each role, decide:

• Which records they can see (all, their team’s, or only their own).
• Which actions they can take: create, edit, approve, delete, export.
• What must be logged so you can see who changed what, and when.

A simple table of roles against actions is enough. Getting this right early is far cheaper than adding permissions to a finished system.

Most of the technical effort in a dashboard goes into data, not screens. For each source (your database, a spreadsheet, a CRM, an ERP, a payment provider) note who owns it, how it can be accessed (an API, an export, a direct connection) and how current it needs to be. “Updated every night” and “live to the second” lead to very different designs and costs.

Also check data quality. Duplicates, missing fields and inconsistent formats are common, and a dashboard makes them visible very quickly.

• Overview: a handful of numbers and alerts that answer “is anything wrong today?”, each linking to the records behind it.
• Lists and tables: searchable, filterable and sortable, with pagination and bulk actions for repetitive work.
• Detail pages: everything about one record, with its history.
• Forms: create and edit with clear validation messages, so bad data is stopped at the door.
• Reports and exports: the summaries people currently build by hand in spreadsheets.
• Settings and user management: roles, invitations and configuration, kept to administrators.

Design matters as much here as on a public website. Clear empty states, sensible defaults and fast tables decide whether people adopt the tool or go back to spreadsheets.

Before commissioning a custom build, check whether an existing platform already does most of the job. For standard business processes such as accounting, inventory, sales and HR, an ERP such as Odoo can cover a lot out of the box, and custom modules can fill the gaps. A custom application makes more sense when the workflow is specific to your business, needs to match your product, or connects many systems in a particular way.

We do both: Odoo implementation and custom modules, and custom web applications and business dashboards. The right answer is often a mix.

Pick one workflow that matters, such as “orders from arrival to dispatch”, and build it completely: the list, the detail view, the forms, the permissions and the one report people need. A complete narrow tool is used and improved; a broad, half-finished one is abandoned.

Our MVP scoping checklist helps you separate what the first version needs from what can wait.

• The top five questions the dashboard must answer, and the actions people take after reading them.
• Every user role, with what it can see and do.
• Every data source, its owner, how it is accessed and how fresh it must be.
• The core screens for the first workflow.
• Security needs: sign-in method, password rules or single sign-on, audit logging and backups.
• What “done” means for the first release, and how you will measure whether people use it.