What counts as an internal tool
An internal tool is any software your staff use to run the company that customers never see: an admin panel for orders, an approval flow for purchases, a dashboard for managers, a job board for the field team, a tool that pulls data from three places into one view.
In most companies, the first internal tools are spreadsheets and shared inboxes. Then someone builds a form, then a small app in a low-code platform, then another. A few years later, nobody knows how many there are.
The three ways to get internal tools
There are three realistic routes, and most companies use all three at some point.
- Low-code builders such as Retool, Airtable interfaces, Glide or Power Apps. Fast to start, good for simple CRUD screens and dashboards on top of existing data.
- SaaS tools for a specific job, like a scheduling app or an approvals tool. Good when your need is standard.
- Custom-built tools, written in a normal stack by a developer or studio. Slower to start, but no limits on logic, permissions or integrations, and fully owned.
When low-code is enough
Low-code is the right choice when the tool is small, used by one team, sits on top of data that already lives somewhere else, and the logic is simple. A support dashboard, an admin panel for a database, an internal request form: build those in a day and move on.
It becomes the wrong choice when the tool starts holding its own critical data, when several roles need different permissions and flows, when the logic grows beyond simple rules, or when field staff need to use it offline on a phone. Low-code platforms also charge per user, so a tool used by the whole company can become surprisingly expensive.
The internal tool sprawl problem
The danger with internal tools isn't any one of them. It's the sprawl. Each new tool solves one team's problem and creates a new place where data lives. The sales tool has its version of the customer, the operations tool has another, the finance export has a third.
Soon you have twenty tiny apps, built by different people on different platforms, and an ops manager whose real job is keeping them in sync. When that person leaves, the knowledge of how the tools connect leaves with them.
One system with many screens
The alternative is to think of internal tools as screens on one system, not separate apps. There's one database for customers, jobs, people, stock and money. Each role gets the screens it needs: the office sees the planning board, the field sees today's jobs on the phone, finance sees invoices and payments, the owner sees the dashboard.
Adding a new internal tool then means adding a screen and a few rules, not a new platform. Permissions, audit logs and integrations are handled once. And because everything shares the same data, you can put an AI layer on top that answers questions across the whole company.
What to build first
- The hand-off that causes the most mistakes: usually office to field or sales to finance.
- The report someone rebuilds manually every week.
- The approval that lives in email and gets lost.
- The spreadsheet only one person understands.
- The mobile view field staff are missing today.
Build vs buy for internal tools, honestly
If an off-the-shelf tool fits your process without workarounds, buy it. If a low-code screen gets the job done for one team, build it in low-code. Custom is worth it when the tool sits at the centre of your operation, touches several roles, needs real permissions and integrations, or keeps outgrowing the platform it's on.
Ownership matters too. With a custom system you own the source code and data, host it in your own account, and can hand it to any competent team. With a platform, you rent it on their terms.
Questions to ask before building any internal tool
Before anyone opens a builder or writes code, answer a few questions on paper. Who uses it, and on which device? Where does the data come from, and where does it need to go next? Which records does this tool own, and which does it only read? Who is allowed to see and change what? What happens when the person who built it leaves?
If a tool only reads data owned elsewhere and serves one team, keep it light. If it owns critical records or sits between several roles, treat it as part of your core system and build it that way from the start. Most internal tool pain comes from treating the second kind like the first.
How we approach it
We don't build internal tools one by one. We reverse-engineer how work moves through your company, then build one system where every role gets its own screens, on phone and desktop. A Core system (€18,000) covers up to five roles with all your existing data migrated. Maxxed (€48,000) adds unlimited roles, the AI layer, integrations and automations. The first working version lands within 24 hours of kickoff. If your company runs on a growing list of small apps and one person who understands them, apply and send us the list.