# Internal tools: build custom or buy Retool? A 2026 decision guide

*By Roberto Lazar, founder of Dock30 · Published 2026-07-09 · Updated 2026-07-09 · 7 min read*

Retool and its open-source rivals win for most simple internal tools. Custom pays off on complex UX, deep integrations, and cost at seat scale.

For most internal tools, the honest answer is to **buy Retool or use an open-source equivalent**, not build from scratch. An admin panel, a CRUD screen over your database, an approval queue: these are solved problems, and paying a few tens of euros a month to have one running this afternoon beats writing it yourself. Build custom when the tool is central to how the business runs, when the workflow will not fit inside a component library, or when the per-seat bill starts to rival the cost of owning the thing outright.

That is the whole decision in two sentences. The rest of this is where the line actually falls, with the 2026 numbers, and what the platforms do not tell you until you are already inside them. We build internal tools and dashboards for a living at Dock30, and we still tell people to use Retool more often than we tell them to hire us.

## Why buy is the right default

Low-code builders exist because internal tools are repetitive. Connect a data source, drop a table, wire a form, add role-based access. Retool, Appsmith, Budibase, and ToolJet all do that competently, and a developer who knows the tool can put a usable panel in front of an ops team in a day. When the requirement is genuinely a table with buttons on it, custom code is slower to write, slower to change, and yours to maintain forever. There is no craft prize for hand-rolling a CRUD screen.

So the starting position is buy. You move off it only when a specific reason forces the move, and there are exactly four reasons worth taking seriously.

## What the four platforms cost in 2026

Pricing is the first place teams get surprised, because the sticker rate is per seat and internal tools have a way of spreading. Retool separates builders (people who edit apps) from end users (people who only click through them), and both count. The open-source three let you self-host for free, which changes the calculation entirely.

| Platform | License | Self-host free? | Paid pricing (2026) |
|---|---|---|---|
| Retool | Proprietary | No (source-available, limited) | ~50 EUR/builder + ~15 EUR/end user monthly, annual Business |
| Appsmith | Apache 2.0 | Yes, community edition | Business from ~15 USD/month |
| Budibase | GPL v3 | Yes, up to 20 users | ~50 USD/creator + ~5 USD/end user monthly |
| ToolJet | AGPL v3 | Yes, no user cap | ~79 USD/builder monthly, end users included |

Retool's cloud pricing is the one people quote, at roughly 50 dollars per builder per month on annual billing and closer to 65 month-to-month, per the [Retool plan breakdown on Vendr](https://www.vendr.com/marketplace/retool). The free tier covers a small team fine. The bill only becomes a topic once you have real headcount inside the tool.

Among the open-source options, the license matters as much as the price. ToolJet is AGPL, Appsmith is Apache, Budibase is GPL, and all three run under Docker or Kubernetes on your own hardware, per this [open-source comparison from ToolJet](https://blog.tooljet.com/appsmith-vs-budibase-vs-tooljet/). If keeping data on infrastructure you control is a hard requirement, that is the branch to take, and it costs nothing but the server. Appsmith fits teams that write JavaScript for everything. Budibase is the quickest for plain no-code CRUD. ToolJet is the one leaning hardest into AI app generation and high user-to-builder ratios.

## When a custom internal tool wins

Four situations tip the decision the other way. Not three, not a neat rhythm: four, and they often show up together.

The first is complex UX. Low-code builders are generous inside their component model and unforgiving outside it. A drag-and-drop scheduler, a canvas with linked nodes, a dense keyboard-driven data-entry screen that a warehouse team uses eight hours a day: the moment the interface stops looking like a form and a table, you spend more time fighting the builder than you would writing the screen. We have seen teams burn a month bending a platform into a shape it resists, then rebuild the same view in a fraction of the time as plain React.

The second is deep integration. If the tool has to pull from many systems and keep them consistent, the connector list on a low-code platform gets you the easy 80 percent and stalls on the hard 20. Custom sync logic, retries, reconciliation, and a data model that actually matches the business are where the real work lives, and that work does not fit neatly into a visual query editor.

The third is cost at seat scale. This is the one people underestimate. Retool on the Business plan runs roughly 22,000 dollars a year for a 100-person deployment, so across three years you are near 66,000 dollars, which sits inside the range of owning a custom tool outright, as [BearPlex lays out in its build-versus-buy breakdown](https://www.bearplex.com/compare/retool-vs-custom-internal-tools). A custom tool has real upfront cost and near-zero marginal cost per user after that. The platform is the reverse. Somewhere past **20 to 30 active seats** the lines cross, and the more the tool succeeds internally, the faster you reach the crossing.

The fourth is data control and lock-in. Around 37 percent of organizations name vendor lock-in as a top concern with low-code, and most hosted platforms export almost nothing, so outgrowing one means rebuilding rather than migrating, per [ToolJet's 2026 low-code statistics](https://blog.tooljet.com/low-code-statistics-market-ai-trends-2026/). For a throwaway admin panel that risk is fine. For the tool your operations team lives in every day, being unable to leave is a strategic problem, not a line item.

## The hybrid path most teams miss

Build-versus-buy is rarely all or nothing, and treating it that way is how money gets wasted. The pattern that works: buy for the edges, build for the core. Use Retool or Budibase for the internal admin screens nobody outside the company will ever see, the ones that change weekly and do not deserve a codebase. Build custom for the one tool that is central, the workflow the platform cannot express, or the interface a customer touches. A support team's refund console can happily live in Retool. The dashboard the whole business steers by usually should not.

The same split applies over time. Prototype in a low-code builder to prove the workflow with real users, then rebuild the parts that earned it once the shape is settled. You get the speed early and the ownership where it counts, and you avoid the two failure modes: over-building a form, and trapping a load-bearing tool inside a platform you will fight for years.

## Two tools we built, and why they were not low-code

We built an [operations dashboard for a McDonald's franchisee](/work/mcdonalds-dashboard) that pulls from 8+ systems across 3 restaurants into one screen. That is the deep-integration case in the flesh: the value is entirely in normalizing sources that were never meant to talk to each other, keeping them in sync on different cadences, and presenting the whole picture in one place. A low-code connector list does not get you there, and the same aggregation patterns that keep it fast are the ones we wrote up in our [real-time dashboard guide](/blog/realtime-dashboard-data-aggregation).

[Top Wheels Auto](/work/top-wheels-auto) is the other kind. They ran stock, orders, and client records on paper and memory, and no one ever saw the full picture at once. We moved the whole operation into one system built around their exact workflow: live stock, job history per client, reports in seconds, newsletters straight from the app. Could a no-code tool have approximated it? Partly. But the workflow was specific enough that fitting the tool to the business, rather than the business to the tool, was the entire point.

Both of those are [dashboards and internal tools work](/services/dashboards-tools), backed by the [backend and API engineering](/services/custom-development) that keeps the data honest. Neither would have been a good Retool project, and we would have said so if it were.

## How to actually decide

Run it as a short checklist before anyone writes code or signs a plan.

1. Is the tool basically a table with forms and buttons? If yes, buy or self-host a builder and stop reading.
2. Will it exceed roughly 20 to 30 active seats within a year or two? If yes, price the per-seat bill against a custom build over three years.
3. Does the interface need something the component library cannot do? If yes, that part is custom.
4. Does it have to hold many systems in sync, or keep data on your own infrastructure? If yes, lean custom.
5. Would being unable to migrate off the platform hurt the business? If yes, favor self-hosted or owned code.

Most tools fail the first question and end in Retool, which is exactly where they belong. A meaningful minority pass two or more of the rest, and those are the ones worth building properly.

When we build, we scope it fixed: projects start at EUR 350 with the exact price and delivery date in writing before work begins ([project pricing](/pricing/project)), plus 30 days of free support after launch, and every project we have shipped has landed on the agreed date. If you are staring at a build-or-buy call and want a second opinion from someone who has shipped a few dozen of these, book a [free 15-minute call](https://calendly.com/dock30/15min) or reach us through [contact](/contact). Half the time we tell people to just use Retool. That is a fine outcome too.

## Frequently asked questions

**Should I build or buy an internal tool?**

Buy, or use an open-source builder, for most simple internal tools: an admin panel, a CRUD screen over a database, a quick approval queue. Build custom when the tool is central to how the business runs, needs a workflow the component library cannot express, or connects many systems that have to stay in sync. The tie-breaker is usually how much the workflow deviates from a table with buttons on it.

**How much does Retool cost in 2026?**

Retool charges per seat and splits builders from end users. On annual billing the Business plan runs about 50 dollars per builder per month plus roughly 15 dollars per end user, and the month-to-month builder rate is closer to 65 dollars. There is a free tier for small teams, so the cost only becomes a real question once you pass a handful of active users.

**Is a custom internal tool cheaper than Retool?**

Not at first. A custom tool has real upfront cost, while Retool starts near zero. The math flips at seat scale: a 100-person Business deployment is roughly 22,000 dollars a year, so three years lands near 66,000 dollars, which is inside the price of owning a comparable tool outright. Below about 20 or 30 seats, Retool almost always wins on cost.

**What is the best open-source alternative to Retool?**

Appsmith, Budibase, and ToolJet are the three that come up most. Appsmith suits teams that think in JavaScript, Budibase is the fastest for no-code CRUD apps, and ToolJet leans into AI generation and higher user-to-builder ratios. All three self-host for free, which is the main reason to reach for them over Retool: your data and the app both stay on your infrastructure.

**Can you get locked into a low-code platform?**

Yes, and it is the most common regret. Most hosted low-code platforms export almost nothing, so outgrowing one means rebuilding rather than migrating. Self-hosted open-source tools reduce that risk because you keep the deployment, and a custom codebase removes it entirely. If the tool is going to matter for years, weigh the exit before the entrance.

---

Written by Roberto Lazar, founder of Dock30. Book a call: https://dock30.com/contact