Admin panels and back offices
The control room behind a product or service: manage users, orders, content, refunds and settings without asking an engineer to run a database query.
Solutions · Internal toolsInternal tools and admin panels
Internal tools and admin panels
that replace the spreadsheet.
Operations teams run on shared spreadsheets, inboxes and copy-paste until the errors and delays become visible. BBR builds the internal software that takes over: admin panels, dashboards and workflow tools with proper permissions, an audit trail and connections to the systems you already use. Where a low-code platform would serve you better, we say so.
What we buildSoftware for the people
Software for the people
who run the business.
Internal tools have a small, known audience and a clear job. They do not need marketing polish. They need to be correct, fast to use all day, and safe about who can see and change what.
Workflow and approval tools
Requests, reviews, sign-offs and handoffs that currently live in email threads, turned into a tracked flow with statuses, owners, deadlines and notifications.
Dashboards and reporting
Figures from several systems on one screen, refreshed automatically, with drill-down to the underlying records and exports for whoever still wants a spreadsheet.
Operations tools
Inventory, scheduling, dispatch, job tracking, data entry and reconciliation, shaped around how your team works rather than how a generic product assumes it does.
When to replace the spreadsheet
Spreadsheets are fine, until they are not.
A spreadsheet is the right tool for a new process: free, flexible and understood by everyone. Keep it while the process is still changing. The signs that it has been outgrown are consistent:
- Several people edit at once and overwrite each other, or "the latest version" is a matter of debate
- No record of who changed what, which becomes a problem the first time a number is disputed
- Everyone can see everything, including data some of them should not
- Rules live in people’s heads: which column to fill, which status comes next, who to email afterwards
- Data is copied by hand to or from other systems, with the errors that brings
- One person understands the formulas, and the process stops when they are on leave
- It has become slow or fragile because of its size
Two or three of these together usually justify a proper tool. The next question is which kind.
Custom build vs low-code
A fair comparison.
Low-code internal-tool builders and database-style app platforms are good products, and for many internal tools they are the correct choice. We would rather tell you that than build something you did not need.
| Factor | Low-code platform | Custom build |
|---|---|---|
| Time to a first version | Days to a few weeks | Weeks to a few months |
| Upfront cost | Low | Higher |
| Ongoing cost | Subscription, commonly per user or per app; grows with headcount | Hosting plus maintenance; largely independent of user count |
| Simple forms and tables over existing data | Excellent | More than you need |
| Complex business logic, heavy validation, long workflows | Possible, but becomes hard to follow and test as it grows | Natural fit; logic is ordinary code with automated tests |
| Interface | The platform’s components and layout model | Whatever the task needs, including speed-focused data entry |
| Permissions and audit | Available; finer-grained control is often reserved for higher plans | Designed to your rules, down to the field and record |
| Integrations | Good for popular services and standard databases | Any system with an API, database or file export |
| Hosting and data location | Usually the vendor’s cloud; self-hosting on some platforms and plans | Your cloud account or your own network |
| External users (customers, partners) | Often limited or expensive | Straightforward |
| Who maintains it | A technically minded operations person can | A developer |
| Exit | Logic and screens are tied to the platform; your data can be exported | You own the code; any team working in the same stack can continue |
Decision rules
- Choose low-code when the tool is mostly viewing and editing records, has a modest number of internal users, someone on staff can own it, and the vendor’s hosting is acceptable.
- Choose custom when the logic is the hard part, the user count makes per-seat pricing expensive, outsiders need access, data must stay on your infrastructure, or the tool is central enough that you want no dependency on a platform’s pricing and roadmap.
- Consider both: a custom back end and API holding the rules and data, with a low-code front end for the simple screens. Or low-code now to learn what the tool should be, custom later if it earns it.
Typical architecture
Plain technology, careful access control.
Internal tools rarely have scaling problems. Their engineering challenges are correctness, permissions and integration. The architecture reflects that.
| Concern | Typical approach |
|---|---|
| Application | A web app in React / Next.js with TypeScript, over a Node.js API. One well-structured codebase, not microservices |
| Data | PostgreSQL as the single source of truth, with constraints in the database so that bad data is rejected whichever screen or script sends it |
| Sign-in | Single sign-on through your identity provider (OpenID Connect or SAML), or email login with multi-factor authentication for smaller teams |
| Roles and permissions | Role-based access checked on the server for every request, not only hidden in the interface. Record-level rules where needed, such as "managers see their own region" |
| Audit log | An append-only record of who changed what and when, with before and after values, viewable by administrators |
| Integrations | API clients and webhooks for your other systems, run through a job queue with retries and failure alerts so one outage does not lose data |
| Imports and exports | CSV or Excel import with validation and a preview step; export everywhere, because people will always want a spreadsheet |
| Environments | Staging and production, deployed with Docker to your cloud or VPS account, with automated backups and a tested restore |
| Security basics | Encrypted connections, secrets outside the repository, least-privilege database access, optional IP or VPN restriction |
Two details matter more than they appear to. Permission checks belong on the server, because a hidden button is not a security control. And the audit log should be designed in from the start, because adding it later means it has no history for the period you will be asked about.
The processMap it, then
Map it, then
build the worst part first.
Internal tools succeed when the people who use them every day shape them. We involve those people from the first week.
How we work in detail ↗Map the current process
We go through the real spreadsheets, emails and systems with the people who use them, and write down the steps, roles, rules and exceptions. Exceptions are where most of the effort hides.
Decide buy, low-code or build
An honest recommendation. If a build makes sense: a written scope with acceptance criteria, a fixed quote for phase one, and a list of later phases.
Prototype with real users
A clickable prototype reviewed by the staff who will use the tool. Data-entry screens are tested for speed, since a tool that is slower than the spreadsheet will be quietly abandoned.
Build in increments
Working software on staging early, the riskiest integration tackled first, and regular demos. Changes to scope are priced before they are made.
Migrate, run in parallel, hand over
Existing data imported and checked, a short period alongside the old process, then cutover. Source code, documentation and an operations guide are handed over. Support is scoped separately.
Pricing factors
What moves the cost of an internal tool.
BBR quotes a fixed price per phase against a written scope. The main drivers are:
- Number of distinct workflows. Each has its own screens, states and rules.
- Roles and permission complexity. Three roles with simple rules is cheap. Record-level visibility with delegation and temporary access is not.
- Integrations. How many systems, and how good their APIs are. An undocumented legacy system is the largest single uncertainty in most quotes.
- Data migration. How much history to bring across, and how clean it is.
- Reporting. A few fixed reports, or a flexible report builder. The second is far more work.
- Hosting and security requirements. On-premises deployment, SSO, network restrictions and formal review processes add effort.
- Offline or mobile use. Warehouse and field tools that must work without a connection are a step up in complexity.
What keeps cost down: a standard component library instead of bespoke visual design, managed services for authentication and storage, and starting with a single workflow. The effort-times-rate method in our guide to estimating build cost applies here too. For the wider service this work sits under, see custom software development.
FitWhen BBR is the right team,
Good fit Not a fit
When BBR is the right team,
and when it is not.
An independent studio working remotely in English suits many internal-tool projects, but not all of them.
We are likely a strong match if
- You have a defined process with real volume and visible costs from errors or delay
- The rules are too specific for generic software, or low-code has been tried and outgrown
- The tool must connect to systems you already run
- You want to own the code and host it under your own accounts
- A process owner on your side can give time to discovery and testing
We will probably point you elsewhere if
- A low-code platform or an off-the-shelf product would do the job; we will say so
- You need a full ERP implementation or configuration of a specific enterprise suite
- You require a vendor holding a particular compliance certification; BBR does not claim any
- You need staff on-site
- The process itself is still undecided; agree on it first, then automate
QuestionsFrequently asked
Frequently asked
questions.
Should we use a low-code platform instead of custom development?
If the tool is mainly forms and tables over an existing database, has a small number of users, and someone on your team can maintain it, a low-code internal-tool builder is usually faster and cheaper, and we would recommend it. Custom development is the better choice when logic is complex, many people use the tool, per-user fees add up, customers or partners also need access, or you need full control over hosting and data. The comparison table on this page goes through the factors.
How long does it take to build an internal tool?
It depends on the number of workflows, roles and integrations. A focused first phase covering one workflow is typically a matter of weeks rather than months. We scope in phases so that the first usable version arrives early and later phases are informed by real use.
Can the tool connect to our existing systems and databases?
Yes, where those systems offer an API, webhooks, database access or file exports. Integration is usually the part with the most unknowns, so we examine each system during discovery and test the riskiest connection first. See API integration for how we approach it.
Do you support single sign-on?
Yes. Internal tools can authenticate through your identity provider, such as Google Workspace or Microsoft Entra ID, using standard protocols (OpenID Connect or SAML). Staff sign in with their work account, and removing someone from the directory removes their access.
Who owns the tool and where is it hosted?
You own the code and deliverables under the project contract. The tool is deployed to your own cloud or VPS account, or inside your network if required, so your data stays under your control. BBR does not claim any compliance certification; if your industry requires specific controls, tell us at the start so they can be designed in and verified by your own auditors.
Can you add an admin panel to a product we already have?
Yes. BBR can join or take over existing codebases. Building a back office onto an existing application and database is a common project: support lookups, content management, refunds, user management and reporting, with access separated from the customer-facing app.
Your next moveHave a process held together by spreadsheets?
Have a process held together by spreadsheets?
Show us how it runs.
Describe the workflow, who touches it and which systems hold the data. We will reply with a view on low-code versus custom and, if a build makes sense, a phased scope and range.
Discuss your internal tool ↗