Guides / How to build

How to Build an Internal Tool: Admin Panels, Approvals and Spreadsheet Replacements

How to build an internal tool with AI: pick the painful workflow, model the data, add roles and approvals, move off the spreadsheet, and get the team using it.

Mythex Team · 2026-09-29 · 6 min read

To build an internal tool, pick one workflow that is currently painful — usually a shared spreadsheet, an email thread or a chat channel doing a database's job — and turn it into a small app with a proper form, a list with statuses, the right permissions for each role, and a history of who changed what. An AI app builder can produce a working first version in an afternoon. What makes it succeed is keeping the scope to one workflow and building it with the people who will use it every day.

What counts as an internal tool

Internal tools are the unglamorous software that runs a business. Common types:

For more starting points, see internal tool ideas for teams.

Should you build it at all?

Keep the spreadsheet if one person maintains it, the data is small, and a mistake costs little. Build a tool when you notice these signs:

• People overwrite each other's changes, or nobody knows which copy is current
• You need some people to see or edit only part of the data
• You have written a page of instructions on how to use the sheet
• Status changes need to notify someone, and they keep getting missed
• You need an audit trail — who approved this, and when

There is also a middle option. Low-code internal tool platforms (Retool, Airtable interfaces, Softr and others) give you building blocks on top of your data. They are a good fit when your data already lives in a supported database or spreadsheet and you want drag-and-drop screens. An AI-built app suits you better when the workflow is specific, you want it to look and behave exactly as your team needs, or you want to own the code. For the general question, see build vs. buy software for a small business.

Design the workflow before the screens

Write the workflow as a short story before prompting. For an expense approval tool:

1. An employee submits an expense: amount, category, date, description, receipt photo.
2. Their manager gets notified and approves or rejects with a comment.
3. Expenses over a limit also need finance approval.
4. Finance marks approved expenses as paid in a weekly batch.
5. Everyone can see the status of their own expenses; finance sees all.

From that story you get:

• Data: expenses, users, roles, approvals (who, decision, comment, date), attachments.
• Statuses: submitted → manager approved → finance approved → paid, or rejected.
• Roles: employee, manager, finance, admin.
• Rules: the amount threshold, who can move an item to each status.
• Screens: submit form, "my expenses", "waiting for my approval", finance's all-expenses table, a detail page with history.

Describe the workflow in those terms and the AI can build the right thing on the first try.

Permissions and history

Internal tools often hold sensitive data — salaries, customer details, money. Two rules:

1. Check roles on the server for every action. A manager should not be able to approve their own expense by calling the approve endpoint directly.
2. Record history. Store each status change and edit with who made it and when. It resolves most "who changed this?" arguments and is invaluable when something goes wrong.

Decide how people log in. Sign-in with your company's Google or Microsoft accounts is convenient for teams already using them; email and password works everywhere. Either way, restrict sign-up so only your team can get in.

A first prompt that works

Build an internal expense approval tool for a 25-person company. Employees submit an expense with amount, currency, category (travel, meals, software, equipment, other), date, description and a receipt photo upload. Their manager sees a "Waiting for my approval" list and can approve or reject with a comment. Expenses over $500 then also need approval from someone with the Finance role. Finance sees a table of all expenses with filters by status, person and month, and can mark approved expenses as paid. Every status change is recorded with who did it and when, shown as a timeline on the expense page. Roles: employee, manager, finance, admin — checked on the server for every action. Save everything in a database and seed realistic sample data. Plain, dense, fast interface — this is a work tool, not a marketing site.

Build steps

1. The main table and form for the core record, with realistic seed data so search and filters obviously work.
2. Statuses and transitions, including who may move an item to each state.
3. Roles and login, restricted to your team.
4. History log on each record.
5. Notifications — an email or a chat message when something needs someone's action.
6. Import existing data from the spreadsheet. How to turn a spreadsheet into an app covers cleaning and importing.
7. Pilot with two or three real users for a week before rolling out to everyone.
8. Switch off the old process on a set date. Two systems running side by side means neither is trusted.

Getting people to actually use it

Plenty of internal tools work perfectly and still fail, because people keep using the old way.

• Build with the users. Watch someone do the task today before you design the new version.
• Make it faster than the old way. If submitting takes longer than sending a message, people will keep sending messages.
• Dense beats pretty. Operators prefer tables with good filters and keyboard-friendly forms over large cards and whitespace.
• Put the next action first. "Waiting for me" should be the first thing people see.

Common mistakes

• Rebuilding the whole spreadsheet. Move the one painful workflow; leave the rest in the sheet for now.
• No owner. Someone must be responsible for changes and fixes after launch.
• Permissions as an afterthought. Adding roles to a finished tool is harder than starting with them.
• Skipping the audit trail, then needing it the first time money goes missing.
• Publishing to a public URL without login. Anything internal must require sign-in.

Keeping it running after launch

A process changes every few months — a new approval step, a new category, a new team. Plan for that from the start:

• Keep settings in tables, not code. Categories, thresholds and approver assignments that live in the database can be changed by an admin without a rebuild.
• Collect requests in one place. A simple "suggest a change" link in the tool beats requests scattered across chats.
• Export regularly. A CSV export of the main tables means the data is never trapped, and makes month-end reporting easy.
• Test after each change. Walk through submit, approve and reject again after any change to the workflow, because permission bugs tend to appear there.

Running costs

An internal tool built with AI costs hosting, a database, file storage if people upload documents, and possibly an email or messaging service for notifications. There are usually no per-seat licences for a tool you own, which matters when many occasional users need access. The ongoing cost is someone's time to maintain it.

Building it with Mythex

Internal tools are a good fit for Mythex. You describe the workflow, the agent builds it in a live preview, adds a Postgres database for the records and file storage for uploads such as receipts. The docs' internal tool use case and admin panel use case have starter prompts. Colleagues can help build it in your workspace with no per-seat fees.

Two things to know. The logins for your team using the tool are part of the app you build, with an approach you choose — they are separate from Mythex accounts. And Mythex doesn't include built-in Salesforce, HubSpot or Slack integrations for the app itself; those are connected through their APIs with your own keys. For a starting prompt, try the approval tracker or internal admin tool templates, and see how to build a dashboard if what you need is mostly charts.