Internal tools are the software nobody outside the business ever sees: the screen the ops team uses to approve refunds, the dashboard the owner looks at on Monday, the form that turns a phone order into a job. They’re also the software most likely to be a spreadsheet, a shared inbox, or a WhatsApp group, because they never get budget. When they do get budget, the question is whether to buy a SaaS product that roughly fits, build on a low-code platform, or have something written. The honest answer is usually a mix, and the useful skill is knowing which category each tool belongs in.
Quick answer: Buy SaaS for processes that are the same in every business (payroll, ticketing, scheduling). Use a low-code platform for admin screens over data you already have, where the users are staff and the logic is simple. Build custom when the tool encodes how your business works, faces customers, or has to integrate deeply with several systems. And watch the per-seat pricing and the exit path on the low-code option, because both get expensive around the time the tool becomes important.
What are the three options?
Buying means a SaaS product built for the process: a help desk, a rota tool, an expenses system. It’s fastest and cheapest for anything that’s a commodity, and the cost is that you adapt your process to the product.
Low-code platforms (Retool, Airtable and its interfaces, Softr, Glide, Microsoft’s Power Apps, and a long tail of others) let a technical-ish person assemble screens over a database or an API without writing much code. They’re good at admin panels, approval flows, and dashboards, and they’re quick: a working internal tool in days. The cost is per user per month, plus the platform’s limits on what you can express, plus the fact that the tool lives inside someone else’s product.
Building means a developer writes an application, hosted where you choose, that does exactly what the process needs. It costs the most up front, it’s the only option for some requirements, and it’s the one you own outright. Our post on custom software vs off-the-shelf goes through the general decision; the internal-tools version has a few specifics.
When is low-code the right answer?
When the users are staff, the data already exists somewhere with an API or a database connection, and the logic is mostly “show these records, let people edit these fields, send a notification when this changes.” An admin panel over the production database for customer service. A dashboard that pulls from three systems. An approval flow for purchase requests. For those, low-code is faster than a developer and good enough for years.
It’s also the right answer for experiments. If you’re not sure the process is stable, building it in a low-code tool for a few months teaches you what the real requirements are, and if it turns out to need a custom build, you have a working specification.
Where it goes wrong is scale and importance. Per-seat pricing that was fine for four people is a line item at forty. A tool that started as a convenience becomes the way orders are processed, and then the platform’s outage is your outage and its pricing change is your problem. The logic grows past what the platform expresses cleanly, and someone starts writing custom code inside the low-code tool, which is the worst of both options. And getting out is harder than getting in; the data usually exports, the screens and logic usually don’t.
When should you build?
When the tool is the business. If the way you schedule jobs, price work, allocate stock, or manage a customer’s project is what makes you better than competitors, that logic is an asset, and it belongs in something you own, can change freely, and can take to any host. The quoting tool for a job shop is the classic example; so is the B2B ordering portal once trade customers depend on it.
When customers touch it. Low-code platforms are priced and designed for staff users; customer-facing portals need proper authentication, a design that matches the brand, and terms that let a thousand people log in without a thousand seats.
When integration is the point. A tool that has to read from the accounting system, write to the warehouse system, and update the CRM, with rules about what happens when one of them is down, is a small application with an integration layer, and low-code tools handle the happy path and struggle with the failures.
And when you’ve hit the ceiling on a low-code tool and are writing custom code inside it. At that point you’re paying platform fees for the privilege of maintaining code in a less convenient place.
What about building it with AI?
A fourth option in 2026 is having an AI tool generate the internal application, and for staff-facing tools with low stakes it can work: the audience is forgiving, the data is yours, and the speed is real. The caveats are the ones we’ve written about at length: the generated tool needs the same production readiness work as anything else once people rely on it, and an internal tool with access to the production database is a security question whether or not a human wrote it. Treat it as a fast way to build the custom option, with a developer reviewing before it touches real data, rather than as a way to skip the decision.
How do you decide, in practice?
Write down the process in a paragraph and answer four questions. Is this process the same in every business like ours? Buy. Are the users all staff, and is the logic simple? Low-code. Does it face customers, encode our advantage, or integrate with more than two systems? Build. Are we unsure the process is stable? Low-code now, decide again in six months.
Then, whichever you choose, put the data somewhere you control. A tool built on a low-code platform that reads from your own database can be replaced; one whose data lives only inside the platform can’t, easily. This is the single decision that keeps the options open.
Cost-wise, a low-code tool for a small team runs from tens to a few hundred dollars a month. A custom internal tool starts around the lower figures in our post on custom web application cost, and the crossover, where owning it costs less than renting it, tends to arrive somewhere between twenty and fifty users or when the tool becomes the way the business operates.
We build the third category, and we’ll tell you when you’re in the first two. That conversation is how most of our custom software projects start, and a fair number end with a recommendation to use Airtable for now.
Frequently asked questions
Can we start on low-code and move to custom later?
Yes, if the data lives in a database or system you control rather than only inside the platform. The screens and logic will be rebuilt; the data and, more importantly, the understanding of the process carry over. Plan for it from the start by keeping the platform as a front end over your own data.
Which low-code platform should we use?
For screens over an existing database or API, Retool or a similar developer-oriented tool. For a team that wants to own the data and the tool without a developer, Airtable with its interfaces. For businesses already on Microsoft 365, Power Apps is often the path of least resistance. Pick by who will maintain it.
Is a spreadsheet an internal tool?
It’s the most common one, and it’s fine until several people edit it, it becomes the record of truth for something important, or its formulas encode logic nobody else understands. Our post on replacing spreadsheet workflows covers the signs.
How do we keep a low-code tool from becoming a security problem?
Give it the least access it needs: a database user that can read the tables it shows and write only the ones it edits, rather than the admin connection. Use the platform’s single sign-on so leavers lose access when their company login is removed. Review who has access quarterly.
What does a custom internal tool cost to run?
Hosting for a small internal application is usually tens of dollars a month. The real ongoing cost is maintenance: updates, small changes, and someone to call. Budget a modest monthly retainer or a few days a quarter, and compare that with the per-seat total of the low-code option.
Should the tool be a web app or something else?
A web app, nearly always. Staff use it on whatever device they have, there’s nothing to install, and it’s the easiest thing to secure and update. Native mobile apps for internal use are rarely worth the extra cost unless the job is done away from a desk, and even then a mobile-friendly web app usually covers it.