Build internal tools: how to choose between Retool, a no-code builder and your own code

What is an internal tool?

Most internal tools start as a spreadsheet that became too important. A sheet tracks orders or approvals, several people edit it at once, a formula breaks, and nobody can tell who changed what. An internal tool is the next step: software your own staff use to run the business, which customers never see. The common kinds:

• Admin panels: look up a customer or an order and correct a record, without anyone touching the database directly.
• Queues and approvals: refunds, discounts, purchase requests or time off, waiting in one place for the person who signs off.
• Boards: dispatch, scheduling or job tracking, where the team sees what’s next and who has it.
• Dashboards: the numbers a manager checks each morning, pulled from the systems that hold them.
• Back-office forms: intake, inspections or quality checks that write to one place instead of five.

Most internal tools read and change data that lives somewhere else: a database, an accounting system, a CRM or a spreadsheet. That’s why where your data lives decides most of what follows.

How do you build custom internal tools?

The order of the work matters more than the builder you pick. Six steps, in this order:

1. Write down the job: the task, who does it, how often, and what goes wrong with the way it’s done now.
2. Find where the data lives: a database, a spreadsheet, Microsoft 365 or another product’s API. That narrows the choice to builders that can connect to it.
3. Decide who can see and change what: set the roles before any screen exists, since a tool that edits records needs limits on who edits which ones.
4. Pick the base: a no-code builder, a low-code builder or your own code, by the tests in the sections below.
5. Build the smallest useful version: one task, end to end, used by real staff on real records.
6. Name an owner: the person who decides what changes, and who notices when a connected system changes underneath the tool.

The first three steps cost nothing but time, and they decide most of the outcome.

What is Retool, and how is it priced?

Retool is a builder made for this work. It describes itself as a way to build, deploy and manage internal tools, connected to any database or API. Its pricing page, read in November 2026, sets out the model:

• Two kinds of seat: plans charge per builder, someone who creates or edits an app or workflow in that billing cycle, and per internal user, an employee who uses the apps for daily work.
• Four plans: Free, Team, Business and Enterprise. The Free plan is limited to five users.
• What sits on the higher plans: external users and embedded apps, audit logs and rich permissions start on Business. Single sign-on, Git source control and self-hosting are listed on Enterprise.

So the cost of a Retool tool grows with two things: how many people use it, and which plan its security needs put you on. Price it for the headcount you expect in three years, on the plan that has the permissions and logs you need.

What are the Retool alternatives?

The alternatives to Retool fall into three groups: open-source builders you can host yourself, builders tied to a platform you may already use, and no-code builders for spreadsheet data. From each maker’s own pages, read November 2026:

Check the licence if you plan to change a builder’s own code, since GPL and AGPL terms come with conditions that Apache 2.0 doesn’t carry. For most teams using a builder as it ships, the bigger differences are where it’s hosted and how its fees grow with users.

When is a no-code internal tools builder enough?

A no-code builder is made for people who don’t write code, and it tends to be enough when:

• The data already lives in a sheet or a base: Google Sheets, Excel or Airtable, with nothing else writing to it.
• The actions are simple: add, edit, approve, assign and filter.
• A small group uses it: per-user fees stay small while the team does.
• The person who knows the work can build it: an operations lead can change a form the same day, without waiting for a developer.
• A mistake is easy to undo: a wrong status for an afternoon costs little. A no-code tool is easy to change, which also makes it easy to break.

Glide and Softr are made for this, and Airtable’s Interface Designer does the same inside a base, adding dashboards and forms with permissions on who sees which records. The no-code vs low-code vs custom code guide goes further into where each approach stops.

When should you write the tool in code?

Write code when the tool stops being a window onto other systems and becomes a system itself:

• It keeps its own records: once the tool is where the data is kept, the design of its database matters, and so does what happens to those records when the tool changes.
• Its rules branch: pricing logic, scheduling limits or approval chains full of exceptions are easier to test in code than in a builder’s settings.
• It has to live inside other systems: a tool that works in your team chat, an inbox or another product has no screen for a builder to draw.
• The fees outgrow it: once most of the company uses it, a builder priced per user can cost more each year than running your own code.
• You need control a plan doesn’t give: where it’s hosted, who sees the logs, and how people sign in.

Code isn’t free to run either. It needs fixes, security updates and someone who understands it, and the custom software cost page lays out the market’s figures for the build and for the years of upkeep after it.

What makes an internal tool bigger or smaller to build?

Two tools with the same screens can differ a lot in the work behind them. The size comes from:

• The systems it touches: each connection needs its own sign-in, its own error handling and its own tests.
• Roles and permissions: a tool everyone sees the same way is simpler than one where each role sees different records.
• The state of the data: clean records in one database, or records merged from three tools that disagree.
• Where it’s used: office screens only, or phones in a warehouse or a truck.
• What a failure costs: a dashboard that’s wrong for an hour, or an approval that releases a payment.

What goes wrong with internal tools?

The failures are rarely about the builder. They’re about who looks after a tool and who can reach it:

• No owner: the person who built the tool leaves, and nobody knows how it works or what it connects to.
• Permissions added late: everyone could edit everything until the day something went wrong.
• Shadow tools: staff build their own on personal accounts, and company data ends up outside company systems.
• The builder’s ceiling: the tool grows past what the builder does well, and each new request takes a workaround.
• No record of changes: a number changes and nobody can say who changed it, or when. Audit logs exist for this, and on Retool they start on the Business plan.

What should you do first?

Start small, with one task, and keep the order:

1. List the three tasks that take the most staff time, and pick one.
2. Find where its data lives, and what else writes to it.
3. Write the roles: who sees it, who changes it, who approves.
4. Try a builder on a copy of the data, for that one task only.
5. Price the builder for the users you expect in three years, on the plan with the permissions and logs you need.
6. Write code where the builder stops, and name an owner either way.

When the next question is a login for your customers rather than your staff, the client portal software guide covers what changes once people outside the business sign in.

Our client portals and internal tools work builds staff tools in code, each one made for one business in its own repository, and when a builder would do the job, we say so on the call.

One staff tool we built lives in a team chat: the dispatch assistant Alvy’s staff use there, part of AlvyOne, the operations system we built and run with Alvy. Dispatchers ask it to find a job or answer a status question, and it can edit or cancel a job or assign a driver in the dispatch system, asking the dispatcher to confirm before a risky change. Alvy is owned by our co-founder Noah Alvarez, and DSI is an Alvy company.

To talk through the tool you have in mind, book a 15-minute call.