The admin panel, the dashboard, the thing your team runs from a spreadsheet at 11pm.
Internal tools do not need a marketing site, a signup flow or a pricing page. They need to replace the macro that broke in March and nobody dares touch, and the manual export three people redo every Monday.
What this is
An internal tool is software built for your own employees, not for customers, and that changes almost every decision. There is no public signup: login goes through the company's existing SSO or a fixed list of accounts, because the goal is one fewer password to manage, not a registration funnel. There is no billing and no multi-tenancy to defend, because everyone using it already works here. What is left is the unglamorous part: CRUD screens, filters that match how the team actually searches, bulk actions, and an export button for the person who still has to hand a number to finance.
The thing it usually replaces is a spreadsheet that has quietly become load-bearing. A formula that used to work references a row someone deleted eighteen months ago and now returns a wrong number nobody notices, because the one person who understands the macro is on holiday. There is no version history, so nobody can say when it started being wrong. The ROI case for replacing it is blunt: multiply the hours a task takes by however many people run it every week, and compare that to the cost of an interface that does it in two clicks.
Most internal tools are a good interface on top of data that already lives somewhere else: an ERP, a CRM, a database the company already runs. The tool's job is to read from or write to that system of record cleanly, not to become a second, quietly diverging copy of the truth. Permissions follow the org chart rather than a billing tier: a role here is a job title, not a subscription plan, which is the whole reason this is a smaller build than a SaaS product with the same number of screens.
What you get
A working interface that replaces the spreadsheet or manual process
A real application, not a marginally better spreadsheet template.
CRUD screens with the filters and bulk actions the team actually uses
Built after watching the current process, not guessed from a generic admin panel.
Export to CSV or Excel
For the people who still have to hand a number to finance or a regulator.
Permissions matched to job roles
Not a public-facing role system repurposed for a team of a dozen.
An audit trail of who changed what
So "who approved this" has an answer that does not depend on someone's memory.
Integration with the systems of record it reads from or writes to
ERP, CRM or an existing database, treated as the source of truth rather than duplicated.
Login through the company's existing SSO
Google Workspace, Microsoft Entra, or whatever you already run, no separate password to issue and reset.
Source and deployment, handed over
Running on infrastructure you control.
When this fits, and when it does not
A good fit
- A spreadsheet, a macro or a shared document has become load-bearing, and the one person who understands it is a risk.
- A task takes a person real hours every week that a proper interface would do in minutes.
- The tool is used only by your own employees, and the value is hours saved, not revenue from a new customer.
- It needs to read from or write to a system you already run, ERP, CRM or a database, and the existing interface to that system is wrong for this job.
- Several people currently email each other screenshots of the same live view of something.
Not a good fit
- The whole thing is one form and one table for four people. A shared sheet, or a Retool or Budibase screen your own team assembles in an afternoon, gets you there this week for the price of a licence. Come back when the process has outgrown that.
- You want us to own it as a running service, add a field whenever somebody asks, and be reachable in your team chat. We hand over source and deployment on your own infrastructure. Ongoing feature work is a support agreement agreed up front, not an assumption.
- Nobody can say who decides what the tool should do. Internal tools fail on that more often than on anything technical, and we would rather say so now than build four versions of the same screen.
- The tool will be sold to, or used by, customers outside your company. That needs multi-tenancy and billing, which is SaaS product development.
How it runs
- 01
Watch the current process
The spreadsheet, the export, the macro, once, before designing anything, so the tool fits how people actually work.
- 02
Identify the system of record
And decide whether the tool reads it, writes to it, or both, before building a screen that assumes the wrong one.
- 03
Build the core screens first
Filters and bulk actions second, so there is something the team can react to and correct early.
- 04
Wire permissions to real roles
The ones that already exist in the company, not a generic system built for strangers.
- 05
Hand over
Deployed on your infrastructure, with login tied to accounts you already manage.
Questions we get
Who logs in, and how?
Your employees, through the SSO or identity provider you already use. We do not build a separate account system for a team that size to manage a second password for.
Can it read from our ERP or CRM directly?
Usually, yes, that is the common case. We treat that system as the source of truth and build the interface on top of it rather than duplicating its data into a second store that can drift out of sync.
How is this different from a SaaS product?
Single tenant, no billing, and the buyer is the same as the user: your own team. That removes most of the operational surface a SaaS product needs, which is why an internal tool is usually a smaller and faster build for the same number of screens.
Do we need to spec every screen before you start?
No. We watch the current process first and build the screens that replace it, then add filters and bulk actions as the team actually asks for them, rather than guessing every edge case up front.
Still running something in a spreadsheet at 11pm?
Describe the process, or send the spreadsheet. An engineer looks at what the spreadsheet is actually doing and tells you which half of it is worth turning into software.