Stack Guide
What to build internal tools with in 2026
Internal tools have no marketing budget, no design review, and no patience. They are judged on one thing: how fast an ops person can finish a task without pinging an engineer. That makes the build-versus-buy call the whole decision, and this guide draws the line in a specific place.
About 6 min read. Recommendations verified August 2026.
The recommended internal tools stack
The build path, for tools that encode real domain logic and will outlive the quarter. Skip to the alternatives if yours is a CRUD wrapper over three tables.
| Layer | Pick | Why |
|---|---|---|
| Framework | Next.js 16 | Server components query the database directly, so a simple admin screen needs no API layer at all. Fewer moving parts, less to secure. |
| UI components | shadcn/ui | Components are copied into your repo rather than installed, so an internal tool never breaks because a design system published a major version. |
| Tables | TanStack Table | Sorting, filtering, pagination, and column visibility are 90% of an internal tool. Headless means you style it once and reuse it everywhere. |
| Forms | React Hook Form plus Zod | One schema validates the browser form and the server action. Internal users type strange things into every field, so validate on both sides. |
| Data access | Drizzle on a read replica | Point reporting queries at a replica so an ops export cannot slow down customer traffic. Route writes to the primary explicitly. |
| Authentication | Company SSO | Never a shared password. SSO through your existing identity provider means offboarding an employee revokes tool access automatically. |
| Authorization | Server-side role checks | Hiding a button is not a permission. Every mutation re-checks the role on the server, because internal tools are where privilege creep happens. |
| Audit log | An append-only table | Actor, action, target, before, after, timestamp. The first support escalation about "who changed this" pays for the whole feature. |
| Network access | Cloudflare Access | An identity-aware proxy in front of the app so unauthenticated traffic never reaches your code. Cheaper and safer than a VPN. |
| Monitoring | Sentry | Internal users rarely file bug reports. They work around problems silently, so errors have to reach you without anyone reporting them. |
The verdict
Buy if the tool is a form over a table. Build with Next.js, shadcn/ui, and Drizzle if it encodes real domain rules, is someone's primary daily interface, or handles data you cannot hand to a third-party vendor.
Where the build-versus-buy line actually sits
Use this test. If the tool is fewer than ten screens, is essentially create-read-update-delete over a database, serves under about twenty people, and nobody will be upset when it is ugly, buy it. Low-code builders do that job in an afternoon and you should not spend two engineer-weeks reproducing it. If the tool encodes rules that live nowhere else, is the primary interface for someone's entire working day, or needs an interaction pattern a drag-and-drop builder cannot express, build it.
The pricing gap is the other half of the argument. Retool is the most polished option and prices accordingly: around $650 a month for ten users on its Business tier, and its split between builder seats and end-user seats means the bill grows with adoption. Appsmith is open source and self-hostable, with a free tier for small teams and Business around $150 a month for the same ten users. ToolJet and Budibase sit in the same open-source bracket. At three or four internal tools and fifty users, those numbers get large enough that a custom app stops looking expensive.
Whichever side you land on, three engineering decisions are non-negotiable. Authenticate through company SSO so that offboarding an employee removes their access without anybody remembering to do it. Re-check authorization on the server for every single mutation, because internal tools accumulate privileged operations faster than any other kind of software. And write an append-only audit log from day one, since the question "who changed this record and when" always arrives eventually, usually during an incident.
On data access, read from a replica and write to the primary. An ops person exporting a year of orders should never be able to degrade customer-facing latency, and that separation costs almost nothing to set up at the start and is annoying to retrofit. See Prisma vs Drizzle for the query layer and MySQL vs Postgres if the engine is still open.
Credible alternatives and when they win
Retool
Wins when the tool is needed this week and engineering time is the scarcest resource. The most polished builder, the widest set of connectors, and non-engineers can maintain simple apps. Expect around $650 a month at ten users on Business, growing with viewer seats.
Appsmith, ToolJet, or Budibase
Win when you want the low-code speed without the per-seat bill or the data leaving your network. All three are open source and self-hostable; Appsmith Business runs about $150 a month for ten users. You take on hosting and upgrades in exchange.
Django admin or Rails admin
Wins outright if your application already runs on Django or Rails. A generated, permissioned CRUD interface over your real models, for essentially zero effort, sharing the app's validation rules. Nothing custom competes with free and already-integrated.
A CLI or SQL runbook
Wins when the only users are engineers. A reviewed script in the repository with a dry-run flag beats a web UI nobody maintains, and it leaves a far better audit trail through version control. Not an option once non-engineers need it.
Decision factors that change the answer
- Lifespan. A tool for one migration should be a script. A tool the support team will use every day for three years deserves real engineering and real tests.
- Number of tools. One admin panel is cheap to build. Five means you want a platform, and that is exactly where low-code builders earn their subscription.
- Data sensitivity. If health, financial, or regulated personal data would flow through a vendor's cloud, that either forces self-hosting or forces you to build.
- Who maintains it. Tools built by an engineer who leaves become nobody's job. A low-code app a non-engineer can edit survives turnover better than a beautiful custom one.
- Write scope. Read-only dashboards are low risk and a great fit for a builder. Tools that issue refunds or delete accounts need real authorization and a real audit trail.
Internal tools stack questions, answered
Should I build internal tools or use Retool?
Buy when the tool is fewer than ten screens, is basically CRUD over a database, serves under about twenty people, and nobody minds that it is ugly. Build when it encodes domain rules that exist nowhere else, when it is someone's primary interface all day, or when the data cannot legally sit in a vendor's cloud.
What is the cheapest Retool alternative?
Appsmith, ToolJet, and Budibase are all open source and self-hostable, and all three run in production at real companies. Appsmith Business is roughly $150 a month at ten users against about $650 for Retool Business, and self-hosting the community edition costs only the server. You take on upgrades and uptime in return.
How do I secure an internal admin panel?
Four layers. Put an identity-aware proxy such as Cloudflare Access in front so unauthenticated requests never reach your code. Authenticate through company SSO so offboarding revokes access automatically. Re-check the user's role on the server for every mutation, not just in the UI. And log every privileged action to an append-only audit table.
Can internal tools share the production database?
Yes, and they usually should - a separate copy goes stale and lies to you. Read from a replica so a large ops export cannot degrade customer latency, send writes to the primary through the same validation your application uses, and never let a tool run arbitrary SQL against production without review.
Where to go next
Pick a query layer in ORMs, an engine in databases, and a sign-in provider in auth tools. If the tool needs its own service rather than living inside your app, the backend API guide covers it, and the SQL cheatsheet is the reference you will actually keep open.