Updated November 2026: We rebuilt this guide around two demo apps you can sign into (an IT helpdesk and an HR employee portal), added a section on AI assistants inside internal tools, and added a new FAQ. The customer examples now come straight from our published case studies.
An internal tool is an app your own employees use to do their jobs. Think of a ticket queue for the support team, a time-off request screen for HR, an approval form for purchasing, or a report that pulls live numbers out of your ERP. They exist because the software you bought doesn’t match how your business runs.
For a small IT team, the fastest route to internal tools development is usually a low-code platform that builds over the databases you already run. You don’t copy data into another system, and with the right platform, people sign in the same way they do everywhere else. Your developers spend their time on the screens and rules that are specific to your business.
Most IT teams I talk to have the same list. Sales wants a report the ERP can’t produce. HR tracks vacation in a spreadsheet and answers the same policy questions by email. The support team works tickets out of a shared inbox. Each request is small on its own, but together they fill up the backlog.
Below, I’ll cover when to build or buy and the steps we recommend. Then I’ll walk through two demo apps you can sign into yourself, each with an AI assistant built in.
What are internal tools?
Internal tools are software built for your own team rather than your customers. They handle work that happens inside the business, such as orders, approvals, and reports, and they often replace spreadsheets that too many people depend on.
Some are small, like a form that sends a request to the right manager. Others are bigger, like a custom CRM or a portal that ties into your ERP. Common examples include:
- Approval workflows for expenses, purchase orders, time off, and new-hire paperwork.
- Custom CRM systems that track customers and sales activity the way your sales team works.
- Inventory management apps that show stock levels from the systems you already have.
- Dashboards that put live numbers in front of managers instead of a weekly spreadsheet.
- Helpdesk and ticket tracking for IT or customer support.
- Employee portals for time off, onboarding checklists, and HR policies.
Here’s a great example. Renzi Foodservice budgets in a way that’s unlike other companies in foodservice distribution. That meant they couldn’t buy an off-the-shelf budgeting tool, and their BI software only gave them read-only access to the data, so budgeting stayed manual.
With two employees working part-time, Renzi built custom budgeting and reporting apps over their ERP in a few months. They put the apps in a company-wide employee portal, so people stopped asking IT for reports and opened the portal instead.
Signs you need an internal tool
Bad or missing internal tools cost your people time every week. Once you start looking, they’re easy to spot. Watch for:
- People copying and pasting data from one system into another.
- Reports that take days because someone has to build them in Excel.
- Approvals that sit in email threads.
- Employees using apps IT didn’t approve, including AI tools, because nothing approved does the job.
Showplace Wood Products ran into this. Their order data lived in their ERP, but getting it to the shop floor was a manual job. “The data we needed was in our system, we just didn’t have a good way to get it out,” said Andrew Gilbert, IT Director at Showplace.
So they built an app that pulls cutting dimensions straight from orders in the ERP. Before that, one employee spent half of their time writing up cutting instructions by hand. New hires also used to wait 4 to 6 months before they could start cutting. Now they start in 2 weeks.
Build, buy, or low-code?
There are a few ways to get an internal tool, and each one fits a different situation.
Buy off-the-shelf software
Packaged software is quick to set up and usually costs less up front. It works well when your process looks like everyone else’s. If your process is different, you end up working around the gaps or paying extra for customization. Many tools also charge per user, and you may not get a say in where they store your data.
Build from scratch
Hand-coding gets you exactly what you asked for, but it takes the longest and costs the most. After launch, your team owns every bug fix and update, and if the developer who wrote it leaves, someone else has to learn the code. It still makes sense for unusual integrations or a very complex project that won’t fit a platform.
Use a low-code platform
Low-code sits between the two. You get an app built around your process, with much less code to write and maintain. Low-code tools vary a lot, though. Some limit how far you can customize, and some run only in the vendor’s cloud. Our white paper on how to choose a low-code platform covers what to check before you buy.
m-Power, the platform we make, is a low-code development platform that runs over your existing databases, on your servers or in your cloud. It connects to any JDBC-compliant database, including SQL Server, Oracle, MySQL, PostgreSQL, and IBM Db2, so you don’t have to move or copy data to build an app. You can read more on how m-Power works.
How to build an internal tool, step by step
You don’t need a six-month roadmap to get started. Here’s the process we recommend.
1. Find the problem
You probably know some of the problems already, because people complain about them. For the rest, ask employees what takes too long. People get used to slow processes and may not think to mention them, so ask them to walk you through a normal week instead.
2. Map the workflow and who sees what
Before you build, write down each step: Where the data comes from, who approves what, and what happens when something goes wrong.
Decide who sees what at the same time. Should a manager see the whole team’s requests? Should a customer see other customers’ tickets? Settle those questions with the business now, because every screen depends on the answers.
3. Start from the data you already have
Most internal tools need data that already lives in your ERP, CRM, or another database. Build over those tables where you can. A copy of the data goes out of date, and a second set of permissions has to be kept in sync with the first.
4. Build a small version and show it
Don’t try to solve everything in version one. Build the smallest version that does something useful, put it in front of users, and adjust.
Henley Enterprises, a Valvoline Instant Oil Change franchisee with over 230 locations, works this way. “We use a sprint method so that we don’t do too much without showing it to the customer and incrementally making sure we’re on the right track,” said Robert Reeder, CIO and VP of Technology at Henley. “If we get to a certain point and realize we’re on the wrong path, it’s no big deal.”
5. Test it with the people who’ll use it
Watch people use it rather than asking whether they like it. Where do they hesitate? What do they skip? Those spots are where your design needs work.
6. Launch it and give it an owner
Treat the rollout like a product launch, even if it’s for a single department. Show people why it beats what they do now, and make it easy to report bugs. Then name an owner. An internal tool with nobody looking after it falls behind the business, and users go back to their spreadsheets.
Two internal tools you can sign into
We built both of these examples with m-Power, and both are live demos. Each sign-in page lets you pick a demo user, so you can see how the same app changes depending on who’s signed in.
Example 1: An IT helpdesk
The IT helpdesk demo is set up for a demo IT services company. The sign-in page offers three users. Dave Ramirez is a support technician. Sally Novak is the support manager, who sees the whole team, assignments, and the numbers. Tony Dominic from Frankie’s Deli is a customer who sees only his company’s tickets.
Sign in as Dave and you see his own queue. Across the top are counts of his open tickets, overdue tickets, tickets due today, and tickets closed this week. Below that is a table of his tickets with the customer, priority, due date, and status. From each row he can open or close the ticket, add a note, or ask the assistant about it. The menu also has ticket search, a helpdesk calendar, and a customer map.
All three users work from the same ticket and customer data. Dave sees his queue, Sally sees the whole team, and Tony sees his own company’s tickets. Tony’s view also turns part of the helpdesk into a customer portal, so one app serves your support team and your customers.
Example 2: An HR employee portal
The HR portal demo belongs to a made-up company called Meridian Software. You can sign in as one of four people. Alex Turner is a new hire with an onboarding checklist. Priya Patel is an employee. David Okafor is an engineering manager who approves or denies his team’s requests. Sarah Mitchell is the HR admin, who sees the employee directory and every vacation request.
Priya’s home page shows how many vacation days she has left, how many she’s used out of her yearly allowance, and her pending requests. Her request history shows the dates, status, and manager’s note for each one. She can edit or cancel a pending request, ask the assistant about it, or start a new one with the Request Time Off button.
The portal runs over four tables: Employees, vacation requests, company policies, and onboarding tasks. Row-level security filters each screen by the signed-in employee’s number, so Priya sees her own record and nobody else’s. If she tries to open the HR-only employee directory, she gets a “not authorized” message.
AI assistants inside internal tools
Employees want AI help with their work. If IT doesn’t offer an approved option, some of them will paste company data into whatever chatbot they can find. One fix is to put an assistant inside the internal tools they already use.
Both demos have one. In the helpdesk, sign in as Dave, open the support assistant, and ask, “Which of my open tickets are due first?” When we tried it, the assistant listed the tickets from Dave’s queue, sorted by due date. It answered from the same ticket data the app shows him.
The HR assistant calls the portal’s own applications as the signed-in employee, so it gets what that employee would see on screen. It can’t read the database tables on its own. It can fill in a vacation request, but the employee has to submit it. We explain how we set that up, step by step, in How to Build a Chatbot Over Your Own Data.
Before you add an assistant, decide which model runs it. If you connect a third-party model, the data you allow into prompts goes to that provider. If everything needs to stay internal, choose a self-hosted model. With m-Power‘s AI analytics, IT controls the data each assistant can query, which model it uses, and what data, if any, gets sent to that model.
Where m-Power fits
Apps you build with m-Power run on your existing sign-in (Active Directory, OAuth2, or SAML), with role-based access and row- and column-level permissions, and every action is logged. The app runs on your servers or in your cloud, and the data stays in your database. When you need something custom, you can open the code view and edit the app’s HTML, CSS, or Java directly.
Your team can build the apps, or our consultants can build them with you. Showplace built everything they needed with the staff they already had, and most of their applications took only a few hours of work.
Click through the helpdesk and HR portal demos, or see the rest on our live demos page. If you have an internal tool on your list this year, request a demo. We’ll build around your goals and answer your questions live.
Frequently asked questions
What are internal tools?
Internal tools are apps a company builds for its own employees rather than its customers. Common examples are helpdesks, approval workflows, employee portals, inventory trackers, custom CRMs, and dashboards. They usually work over data the company already keeps in its ERP, CRM, or other databases.
Should you build an internal tool or buy off-the-shelf software?
Buy when your process looks like everyone else’s, because packaged software is quick to set up. Build when it doesn’t, or when the app needs to work over your own database and security. Off-the-shelf tools often charge per user and limit how far you can customize them.
How long does it take to build an internal tool?
It depends on the size of the problem. At Showplace Wood Products, most of the applications took a few hours of work. Henley Enterprises went from identifying a problem for its marketing team to a working solution in two weeks. Bigger workflows with approvals and several user roles take longer.
Should you use low-code or custom code for internal tools?
Low-code fits most internal tools, such as forms, approvals, reports, and portals over your existing data. Custom code makes sense for unusual integrations or very complex logic. If you pick low-code, choose a platform that lets you edit the generated code, so an edge case doesn’t force a rewrite.
How do you keep internal tools secure?
Decide who sees what before you build. Sign users in through your existing directory, such as Active Directory, SAML, or OAuth2. Use roles and row-level rules so each person sees only their own records, and log who changed what. If you add an AI assistant, give it access through the same secured apps instead of direct access to your tables.