How to build internal tools and admin panels for your business

What counts as an internal tool?

An internal tool is any app built for your own staff rather than your customers: the screens people use to approve, check, fix, look up and report. Customers never see them, but they decide how fast the business runs and how many mistakes reach customers.

Department	Typical internal tools
Finance	Purchase approvals, supplier onboarding, refund requests, payment run checks
Operations	Order or job console, dispatch board, exception queue for failed orders or bookings
Customer support	Customer lookup across systems, account changes, credit notes, case history
Sales	Quote builder, pricing approvals, contract status
People and HR	Onboarding checklists, equipment requests, leave approvals beyond what payroll handles
Product (SaaS)	Admin panel: tenant management, impersonation with consent, feature flags, usage reports
Compliance	Incident register, licence and insurance expiry tracking, audit evidence

If customers or partners need to log in too, that is a portal rather than an internal tool, and our customer portal guide covers it.

When has a spreadsheet or shared inbox become a system?

When the business would stop if it broke, or when people spend real time working around it. Most internal tools begin life as a spreadsheet, a shared mailbox, a Teams channel or a form. That is fine until the signs appear:

• More than one person edits it daily, and versions conflict.
• Someone’s job is copying data between it and another system.
• It holds personal, financial or health information with no record of who changed what.
• Approvals happen by email and nobody can find the one that matters.
• Only one person understands how it works.
• Errors reach customers or suppliers before anyone notices.

Three or more ticks usually means it is worth building something proper. Our guide to replacing Excel or Access with a web app covers that specific path, including getting rules out of formulas.

Low code builder, Power Apps or custom code?

Choose by who builds it, how many people use it, and how much business logic and risk it carries. All three are legitimate. They fail in different ways.

	Retool and similar builders	Microsoft Power Apps	Custom code (for example React with a TypeScript API)
Who builds	Developers or technical staff	Business users and Microsoft specialists	Developers
Best at	Admin screens over existing databases and APIs	Forms and workflows over Microsoft 365, SharePoint and Dataverse	Complex rules, many users, polished interfaces, strict security
Pricing at the time of writing	Listed at $10 per builder and $5 per internal user a month on Team, $50 and $15 on Business, billed annually	Premium AU$29.90 per user a month, paid yearly, ex GST	Build cost plus hosting; no per user licence
Audit logs	Business plan and above	Check what your Microsoft licensing and admin settings capture	Built to your requirements
Weak point	Per user costs and platform limits as usage grows	Complexity grows fast beyond simple apps	Higher upfront cost; needs a maintainer

A worked comparison over three years for 40 staff and 3 people building:

• Retool Business: 3 builders at $50 plus 40 users at $15 is $750 a month, $9,000 a year, or $27,000 over three years at the listed prices, before build time. Retool is a US company, so confirm whether you are billed in US dollars, which would make this higher in Australian dollars.
• Power Apps Premium: 43 licences at AU$29.90 is AU$1,285.70 a month, AU$15,428.40 a year, or about AU$46,285 over three years, before build time and assuming all 43 need Premium.
• Custom: a simple internal tool in Expeed’s published band of $15,000 to $40,000 (AUD, ex GST) to build, plus hosting and maintenance, with no per user fee.

Licence prices change and these are list prices, so check current pricing and your existing Microsoft agreement. The point is the shape: low code is cheaper to start, and per user fees grow with headcount. Our low code vs custom development guide and build vs buy guide go deeper on the trade off.

How do you connect to production data safely?

Give the tool exactly the access its users need, through a layer that enforces your business rules, and keep heavy reporting off the live database. Internal tools are dangerous precisely because they are trusted. A bulk update button wired to an admin connection can change every record in seconds.

Four patterns, safest first:

1. Through your own API. The tool calls the same API your product uses, so validation, permissions and logging already apply. This is the best default for anything that changes data.
2. Through a restricted database role. If the tool must query the database, connect with a role that can see only the tables and columns it needs. PostgreSQL’s row level security can limit rows further; note that superusers, roles with BYPASSRLS and usually table owners bypass it, so the tool must not use those.
3. Through a read replica for reporting. Dashboards and exports run against a copy that lags slightly behind, so they can’t slow or damage production.
4. Never with the admin password. No shared superuser credentials in a low code connector, a spreadsheet macro or a developer’s laptop.

Under APP 11, an organisation holding personal information must take reasonable steps, including technical and organisational measures, to protect it from unauthorised access, modification and disclosure. Internal tools that expose customer records to every staff member by default are hard to square with that.

How should roles, audit logs and approvals work?

Every action in an internal tool should be tied to a named person, allowed by their role and recorded. That is good security and it is what makes the tool trustworthy when something goes wrong.

• Roles. Define a small set (viewer, operator, approver, admin) and map people to them. Restricting administrative privileges is one of the mitigation strategies in ASD’s Essential Eight, and ASD Essentials, published on 15 October 2026 to evolve it, asks for access privileges to be reviewed periodically against current roles; give admin only to people who need it, and review it regularly.
• Single sign on. Staff log in with their work account (often Microsoft Entra ID or Google Workspace), so leavers lose access when their account is disabled. Check which plan includes SSO; on Retool, for example, it sits in the Enterprise plan at the time of writing.
• Audit logs. Record who did what, to which record, when, and the before and after values for sensitive fields. Make the log read only to everyone except a security role.
• Approvals. For refunds, credit notes, price overrides and bulk changes, require a second person above a threshold. Build the approval into the tool rather than relying on an email.
• Safe bulk actions. Preview what will change, require confirmation, and keep an undo or a reversal record.

Our Essential Eight and ASD Essentials guide covers how the other controls apply to software you build.

How can AI assistants help in internal tools?

AI is most useful inside internal tools for reading and drafting, and least safe when it changes records without a person checking. Good fits:

• summarising a customer’s history across orders, tickets and emails before a call;
• drafting replies, credit note reasons or incident summaries for a person to edit;
• classifying incoming requests and routing them to the right queue;
• answering staff questions over internal policies and procedures, with citations.

Keep a person approving anything that touches money, customer records or external messages, log what the AI suggested and what the person did, and check where the model provider processes your data. Our AI integration service covers how we add these features to existing systems.

Who maintains it after launch?

Name an owner before you build, and give them time, access and documentation. Internal tools rot quietly. The API changes, a field is renamed, the person who built the Power App moves on, and staff drift back to spreadsheets.

A maintenance plan covers:

• an owner and a backup person, with admin access to the platform or the code;
• a test environment, so changes aren’t made live;
• documentation of data sources, roles and any automated jobs;
• a small monthly budget for fixes and improvements, rather than waiting for a crisis;
• an annual review of who has access and whether the tool still matches how the team works.

What do internal tools cost?

Published Australian ranges put a simple custom internal tool at $15,000 to $40,000 and a mid complexity system at $40,000 to $150,000 (AUD, ex GST). Those are Expeed’s 2026 bands, not quotes. A single workflow tool such as an approvals queue sits at the lower end. A console used by several teams, with roles, audit logs, approvals and integrations, moves into the middle band. A platform that replaces several existing tools is a larger project, best delivered in phases.

Low code tools can reduce build cost, but add per user licences every month, so compare total cost over three years as in the worked example above.

How AWLabs approaches internal tools

We often build internal tools as a React front end over a TypeScript or Python API, with single sign on, roles and audit logs from the start, and we’ll say so when Power Apps or Retool is the better fit for your team. Where the tool sits on top of a product database, it uses the product’s own API or a restricted role, never an admin connection.

It starts with a Development Consult, a 15 minute call or a Zoom with Andy. The paid Discovery Audit then maps users, roles and data sources, and its fee is credited in full against the build. The Schedule of Work offers three fixed price options: The Minimum, The Recommended and The Complete. Senior engineers lead every build. See custom app development.