Internal Tools for Growing Companies: Build, Low-Code or Buy?

An internal tool is software that only your own team uses to run the business: an approval screen, an order desk, a stock tracker, an admin panel. A growing company needs one when a spreadsheet or chat group has quietly become a critical system, and the right way to get it (buy, low-code or custom build) depends on how unusual the process is and how many people will use it.

This article is for founders, operations heads and managers of companies with roughly ten to two hundred people. It explains what counts as an internal tool, the signs that you need one, and an honest comparison of the three ways to get it, with costs.

#What counts as an internal tool

An internal tool is any piece of software built or configured for your own staff to do operational work. Customers never see it, which is why it is usually the last thing a company invests in and the first place a growing team starts to hurt.

Typical examples in a small or mid-size company:

• An approval tool for purchases, discounts, leave or refunds.
• An order or job desk that shows every open order and who is handling it.
• An admin panel for a website or app, where support staff look up customers and fix issues.
• A stock, asset or sample tracker.
• A time and task tracker for a team that bills by the hour.
• A reporting screen that pulls numbers from several systems.

Most internal tools start life as a spreadsheet, and that is healthy. A spreadsheet is a cheap way to discover what the process is. The trouble starts when the sheet becomes the system.

#Signs your company needs one

You need an internal tool when the cost of the workaround becomes visible: errors, delays, or a key person who cannot take leave. These are the signs I look for when a company describes its operations.

• A critical spreadsheet. One file runs a process, several people edit it, and everyone is slightly afraid of it.
• Copy and paste between systems. Someone retypes orders from email into accounting, or from the website into a sheet.
• Approvals happen in chat. A manager approves a purchase on WhatsApp, and three months later nobody can find the message.
• Only one person knows how. The process lives in an employee's head or a personal macro.
• The same question is asked daily. "Where is this order?" "Has this been paid?" "Who is on this job?"
• Mistakes repeat. The same kind of error (wrong price, duplicate entry, missed step) keeps coming back.
• New hires take weeks to learn the workaround. The process has no screens to guide them.

One or two of these are normal. Four or more usually means the workaround costs more each month than a tool would. For the spreadsheet-specific version of this list, see signs your business has outgrown spreadsheets.

#Three ways to get an internal tool

There are three routes: buy a ready product, assemble the tool on a low-code platform, or have it built. Each is right for a different kind of process.

#Buy when the process is ordinary

If thousands of companies do the same thing the same way, somebody has already built a good product for it. Payroll, accounting, email marketing and helpdesk are in this group. Buying is faster, and the vendor carries the maintenance.

Buy unless you can point to a concrete way your process differs. "We are different" is not enough. "We bill in five stages tied to site progress, and no product we tried handles that" is.

#Low-code when the screens are simple

Low-code platforms let someone assemble screens, forms and tables on top of a database or spreadsheet with little programming. They are a real option for simple tools, and worth trying before you commission anything.

Look at the pricing model first. As of November 2026, Retool's pricing (opens in a new tab) is per user per month, with a free plan for up to five users and paid plans that charge a higher rate for people who build apps and a lower rate for people who only use them. Google AppSheet (opens in a new tab) lists plans from USD 5 to USD 20 per user per month. Microsoft Power Apps Premium (opens in a new tab) is listed at USD 20 per user per month, paid yearly. These prices change, so check the current pages.

Low-code has three limits worth knowing before you commit:

• Per-user cost. A tool used by forty staff pays forty licences every month, for as long as it exists.
• Complex rules get awkward. Simple forms are quick. Multi-step workflows with exceptions, calculations and permissions often end up needing real code inside the platform anyway.
• Lock-in. An app built on a platform cannot be moved off it. If the price or the terms change, your choices are to pay or rebuild.

#Custom when the process is your own

A custom internal tool is a small web app built around your workflow. It makes sense when the process is specific to how you operate, when many people need access, when the tool must talk to several systems, or when it is important enough that you want to own it.

The trade is clear. You pay more at the start and take on maintenance, and in return the tool fits, extra users cost almost nothing, and the code and data are yours. I build my own tools for the same reason: the Worklancio app, which I use every day for time and invoices, and SitePatch Hub, a dashboard for looking after many WordPress sites from one screen.

#Comparing the cost honestly

Compare the options over about three years, because one is a monthly fee that never ends and the other is mostly a one-time cost. The example below uses round, made-up numbers to show the maths. It is not a quote or a vendor price.

The exact figures matter less than the shape. Licence costs scale with headcount, and a custom build barely does. The low-code line also leaves out the time of whoever builds and maintains the app, and the custom line leaves out changes you will ask for after launch. Add both before deciding.

For real planning ranges, my article on custom software development cost in India puts a small internal tool (one workflow, two roles, a handful of screens, Excel export) at roughly 80 to 160 hours, or about USD 800 to 2,400 at my hourly rate of USD 10 to 15. That is a planning estimate, and a real project gets a fixed written quote after scoping, as explained on the pricing page.

#What a good internal tool looks like

A good internal tool is boring in the best way: it does one job, it is fast, and nobody needs training to use it. When you review a proposal or a finished build, check for these qualities.

• It follows the real workflow. Screens match the steps staff actually take, in order.
• Every record has a status and an owner. At any moment you can see what is waiting and on whom.
• Roles limit what people see and change. Not everyone should approve, edit prices or delete.
• There is a history. Who changed what, and when, so disputes are settled by the log.
• Data gets out. Export to Excel or CSV for anything, so you are never trapped.
• It works on a phone if staff are on the move. Site, warehouse and field teams will not carry laptops.
• It connects to what you already use. Accounting, email or WhatsApp notifications where that removes retyping. This is API integration work, and it is often where the biggest time saving comes from.

Statuses deserve special care. An order that can be "pending", "approved", "shipped" or "cancelled" needs clear rules about which moves are allowed, or records end up in impossible states. I explain why in state machines for reliable web apps.

#Do it yourself or hire help

A capable operations person can build a simple internal tool on a low-code platform, and for a form, a list and a couple of filters, that is often the right move. You will learn a great deal about your own process by trying.

Bring in a developer when money or compliance depends on the tool being right, when the workflow has many steps and exceptions, when it has to exchange data with other systems, or when the low-code version has grown into something only one person understands. At that point you are already maintaining custom software, only without the benefits of owning it. The custom web application development page explains how I scope this kind of build.

#Where to start

Start with the workflow that causes the most pain, not the biggest one. Write down who does what, in which order, where the information lives today and what goes wrong. One page is enough.

Then follow this order. Check whether an off-the-shelf product already does it. If not, try a low-code prototype for a week and see where it strains. If the process is important, used by many people or full of your own rules, scope a small custom first version around that single workflow. My guide on how to plan a web app MVP walks through that scoping step.