Building Internal Tools in 2026: Retool vs Appsmith vs Just Writing Code

Every engineering team eventually faces the internal tools question. Someone needs a dashboard to manage customer accounts. Someone else needs a way to process refunds without running SQL directly against production. The ops team wants a form that triggers a deployment pipeline. And before you know it, you are staring at a buy-vs-build decision that will shape your team’s productivity for years.

In 2026, the internal tools market has matured considerably. Retool (now at v3.x) and Appsmith (v1.40+) are the dominant low-code platforms, but they have been joined by a growing ecosystem of alternatives — Tooljet, Budibase, Airplane (acquired by Airtable in late 2025), and others. Meanwhile, the “just write code” camp has its own arsenal: Next.js 15 with server components, shadcn/ui, Tailwind CSS v4, and frameworks like Refine and AdminJS that split the difference between low-code and custom.

Having built internal tools both ways — shipping Retool apps at a 200-person fintech and hand-coding admin panels at startups — I want to lay out an honest comparison. Not the vendor marketing version, and not the “real engineers write their own tools” version. The actual tradeoffs, costs, and decision points that matter.

The Case for Low-Code Platforms

What Retool and Appsmith Actually Do Well

Low-code platforms solve a specific problem extremely well: they eliminate the boilerplate of connecting a UI to a data source and rendering CRUD operations. If your internal tool is fundamentally “query a database, display results in a table, let users edit rows, and trigger some actions,” these platforms can get you from zero to functional in hours instead of days.

Retool’s core strength is its query layer. You connect a PostgreSQL database (or MySQL, MongoDB, REST API, GraphQL endpoint, or about 50 other integrations) and write queries directly in the builder. The queries can reference UI components — a search input, a date picker, a dropdown — and the platform handles the data binding automatically.

-- A typical Retool SQL query referencing UI components
SELECT 
  u.id, u.email, u.name, u.plan, u.created_at,
  COUNT(o.id) as order_count,
  SUM(o.total) as lifetime_value
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.email ILIKE {{'%' + searchInput.value + '%'}}
  AND u.created_at >= {{dateRangePicker.value.start}}
  AND u.created_at <= {{dateRangePicker.value.end}}
  AND ({{planFilter.value}} = 'all' OR u.plan = {{planFilter.value}})
GROUP BY u.id
ORDER BY {{sortColumn.value}} {{sortDirection.value}}
LIMIT 50 OFFSET {{(table1.pageNumber - 1) * 50}}

This is genuinely useful. Writing the equivalent in a custom app means building a query builder, parameterizing inputs, handling pagination, managing loading states, and connecting it all to UI components. In Retool, it takes about 15 minutes.

Appsmith (open source, self-hostable) offers a similar experience with a more developer-friendly approach. Its JavaScript-first design means you write JS expressions everywhere instead of the template syntax Retool uses. Since Appsmith v1.30, its Git integration has improved significantly — you can version-control your apps, branch, and merge, which was a major pain point in earlier versions.

Where Low-Code Platforms Fall Short

The problems start when your requirements exceed the platform's assumptions. Every low-code platform makes assumptions about what internal tools look like, and when your tool does not fit those assumptions, you fight the platform instead of building on it.

Complex UI interactions: Drag-and-drop builders work great for forms and tables. They fall apart for custom visualizations, multi-step wizards with conditional branching, or anything that requires precise control over layout and interaction. Retool's custom component API (v2, released mid-2025) helps, but building a custom React component, bundling it, uploading it to Retool, and wiring it up to the query layer is often more work than just building the whole page in React.

Performance at scale: Retool and Appsmith both struggle with large datasets. A table displaying 10,000 rows with client-side filtering will lag noticeably. Both platforms render in the browser, so you are subject to browser memory limits and JavaScript execution performance. For a custom app, you would implement server-side pagination and filtering from the start.

Testing: This is the elephant in the room. Neither Retool nor Appsmith has a meaningful testing story. You cannot write unit tests for your Retool queries. You cannot write integration tests for your Appsmith workflows. If a query change breaks a downstream component, you find out by clicking through the app manually. For a team that takes software quality seriously, this is a serious gap.

Vendor lock-in: Your Retool apps are not portable. If you decide to move off the platform — because of pricing changes, feature gaps, or acquisition — you are rewriting from scratch. Appsmith mitigates this somewhat by being open source (you can self-host), but your apps are still tightly coupled to the Appsmith runtime.

The Case for Writing Code

The Modern Custom Internal Tool Stack

Building internal tools from scratch in 2026 is significantly faster than it was five years ago. The modern stack for an internal admin panel looks something like this:

// A typical 2026 internal tool stack
{
  "framework": "Next.js 15.2 (App Router + Server Components)",
  "ui": "shadcn/ui (built on Radix primitives) + Tailwind CSS v4",
  "data-table": "@tanstack/react-table v8.x",
  "forms": "react-hook-form v7.x + zod validation",
  "auth": "Auth.js v5 (formerly NextAuth) with corporate SSO",
  "database": "Prisma v6 ORM or Drizzle ORM v0.36",
  "deployment": "Vercel / Docker / Kubernetes"
}

With this stack, an experienced developer can build a functional CRUD admin panel — with authentication, table views, search, filtering, pagination, and edit forms — in about two to three days. That is slower than Retool, but not by as much as people assume.

The shadcn/ui component library deserves special mention. Unlike traditional UI libraries that ship as npm packages, shadcn/ui copies component source code directly into your project. This means you own the code, can modify anything, and have zero dependency on a third party. Combined with Tailwind v4's improved performance and the new CSS-first configuration approach, building good-looking internal UIs is genuinely fast.

// Example: A user management table with shadcn/ui and TanStack Table
// This is about 80 lines of actual code — comparable effort to Retool

"use client";

import { columns } from "./columns";
import { DataTable } from "@/components/ui/data-table";
import { useQuery } from "@tanstack/react-query";
import { Input } from "@/components/ui/input";
import { useState } from "react";
import { useDebounce } from "@/hooks/use-debounce";

export default function UsersPage() {
  const [search, setSearch] = useState("");
  const debouncedSearch = useDebounce(search, 300);
  const [page, setPage] = useState(0);

  const { data, isLoading } = useQuery({
    queryKey: ["users", debouncedSearch, page],
    queryFn: () =>
      fetch(`/api/users?search=${debouncedSearch}&page=${page}&limit=50`)
        .then((r) => r.json()),
  });

  return (
    <div className="space-y-4">
      <Input
        placeholder="Search users by email..."
        value={search}
        onChange={(e) => setSearch(e.target.value)}
      />
      <DataTable
        columns={columns}
        data={data?.users ?? []}
        pageCount={data?.pageCount ?? 0}
        page={page}
        onPageChange={setPage}
        isLoading={isLoading}
      />
    </div>
  );
}

The Refine Framework: A Middle Ground

Refine (v4.x) occupies an interesting middle ground. It is an open-source React framework specifically designed for data-intensive applications — admin panels, dashboards, and internal tools. It provides the data-fetching layer, routing, authentication, and access control out of the box, but you write actual React components for the UI.

// Refine resource definition — similar DX to low-code, 
// but you own all the code
import { Refine } from "@refinedev/core";
import { dataProvider } from "@refinedev/supabase";

function App() {
  return (
    <Refine
      dataProvider={dataProvider(supabaseClient)}
      resources={[
        {
          name: "users",
          list: "/users",
          show: "/users/:id",
          edit: "/users/:id/edit",
          create: "/users/new",
        },
        {
          name: "orders",
          list: "/orders",
          show: "/orders/:id",
        },
      ]}
    />
  );
}

Refine gives you about 60-70% of the speed advantage of Retool while keeping you in the custom code world. It supports multiple UI frameworks (Ant Design, Material UI, Chakra, Mantine) and multiple data backends (REST, GraphQL, Supabase, Appwrite, Strapi). The tradeoff is that it has a learning curve, and its documentation, while improving, still has gaps in advanced use cases.

The Real Cost Comparison

Vendor marketing and blog posts routinely misrepresent costs on both sides. Here is an honest breakdown.

Retool Costs (2026 Pricing)

For a team of 30 users on the Business tier, that is $18,000/year. Enterprise pricing for the same team is typically $30,000-45,000/year. These numbers add up fast, and they scale linearly with headcount. Every new hire who needs access to an internal tool adds to the bill.

Appsmith Costs

Appsmith's free tier is genuinely free and fully featured. The catch is that self-hosting means you own the infrastructure — a VM running Docker ($20-50/month on most cloud providers) plus the operational overhead of keeping it updated and backed up. For a small team, this is a good deal. For a larger team, the Business tier at $40/user/month is more expensive than Retool's Team tier but cheaper than Retool Business.

Custom-Built Costs

The cost of building custom internal tools is almost entirely developer time. Here is a realistic estimate for a CRUD admin panel with authentication:

For a tool with 5 resources (users, orders, products, refunds, reports), a senior developer needs roughly 8-10 working days. At a fully-loaded cost of $800/day for a senior engineer (including salary, benefits, overhead), that is $6,400-8,000 upfront.

But you also need to account for ongoing maintenance: bug fixes, new feature requests, dependency updates, security patches. Budget 10-20% of the initial build effort per quarter for maintenance. That adds roughly $2,500-6,400/year.

Total first-year cost for a custom-built tool: roughly $9,000-14,500. Ongoing annual cost: $2,500-6,400.

Compare that to Retool Business for 30 users at $18,000/year, every year, scaling with headcount. The math favors custom-built tools if you have the engineering capacity — but only if you actually maintain them.

The Decision Framework

After building internal tools both ways across multiple companies, here is the framework I use to decide.

Choose Retool/Appsmith When:

• Your tool is primarily CRUD + tables + forms. This is the sweet spot for low-code platforms. If 80% of your tool is "display data from a database and let users edit it," low-code will be faster and cheaper.
• You do not have available engineering bandwidth. If your engineers are fully allocated to product work and you need an internal tool next week, low-code is the right call. The opportunity cost of pulling an engineer off product work is real.
• The tool's users are non-technical. Low-code platforms are easier for non-engineers to modify. If your ops team wants to add a column to a table or change a filter, they can do it in Retool without filing an engineering ticket.
• You need integrations with many data sources. If your tool pulls from PostgreSQL, a REST API, a Google Sheet, and Salesforce, Retool's pre-built connectors save significant integration work.
• You are a small team (under 15 tool users) and can use the Team tier. At $10/user/month, Retool is hard to beat on cost for small teams.

Choose Custom Code When:

• Your tool has complex UI requirements. Custom visualizations, drag-and-drop interfaces, real-time collaboration features, multi-step workflows with complex conditional logic — these fight the low-code paradigm.
• You need automated testing. If this tool is mission-critical (processing payments, managing inventory, handling compliance), you need automated tests. Low-code platforms do not support this.
• You have more than 30 tool users. At this scale, low-code licensing costs exceed the cost of custom development and maintenance. And the user count only goes up.
• You are already maintaining a component library. If your team has an internal design system with React components, building another internal tool is incremental work, not greenfield.
• Data sensitivity prevents using cloud-hosted tools. Self-hosted Appsmith partially addresses this, but some compliance environments require full code ownership and audit trails that low-code platforms cannot provide.
• The tool will grow in complexity over time. Internal tools have a way of accumulating features. What starts as a simple user lookup becomes a full customer support portal. If you expect this growth, starting with custom code avoids a painful migration later.

The Hybrid Approach

Increasingly, the smartest teams use both. They use Retool or Appsmith for quick, disposable tools — the one-off data migration UI, the temporary monitoring dashboard, the ad-hoc reporting tool — and custom code for their core internal tools that will be used daily for years.

This hybrid approach works because it matches the tool's lifespan to the investment. A tool that will be used for three months does not need automated tests, a CI/CD pipeline, and a component library. A tool that will be used for three years does.

Implementation Recommendations for 2026

If You Go Low-Code

1. Start with Appsmith Community Edition if you can self-host. It is free, open source, and avoids vendor lock-in. Retool is more polished, but the cost difference adds up.
2. Use version control from day one. Appsmith supports Git natively. Retool added source control in their Business tier. Use it. Low-code apps without version control are a maintenance nightmare.
3. Set up a staging environment for your low-code apps. Both platforms support multiple environments (staging/production). Use them to avoid testing directly against production data.
4. Document your queries and workflows. Low-code apps become black boxes fast. Add comments to every query explaining what it does and why.
5. Plan your exit. Document the business logic embedded in your low-code apps. If you ever need to migrate, this documentation will save you weeks.

If You Go Custom

1. Use Next.js 15 with the App Router. Server Components eliminate most of the API layer — you can query your database directly in your page components. This cuts development time by roughly 30% compared to a traditional React + API approach.
2. Start with shadcn/ui. Copy in the components you need (table, form, dialog, dropdown-menu, sheet), customize them to your brand, and build from there. Do not build a component library from scratch.
3. Use Drizzle ORM or Prisma v6. Drizzle is lighter weight and has better TypeScript inference. Prisma is more mature with better documentation. Either works. Do not write raw SQL for CRUD operations.
4. Implement role-based access control early. Use Auth.js v5 with your corporate IdP (Okta, Google Workspace, Azure AD). Add role-based middleware from the start — retrofitting permissions is painful.
5. Write tests for business logic, not UI. You do not need 100% test coverage for an internal tool. But test the critical paths: does the refund workflow actually refund the right amount? Does the user deactivation flow revoke all active sessions?

What About AI-Assisted Development?

One factor that has changed the equation in 2026 is AI-assisted coding. Tools like GitHub Copilot, Cursor, and Claude Code can generate CRUD boilerplate, form validation, and data table configurations in minutes. This compresses the development time for custom tools significantly.

A senior developer using Cursor or Claude Code can realistically scaffold a complete admin panel — including database schema, API routes, table views, form components, and authentication — in a single day. That is approaching low-code speed with none of the low-code limitations.

This does not eliminate the maintenance burden, but it does shift the cost calculation. If the initial build takes one day instead of ten, the break-even point against low-code licensing comes much sooner.

The Verdict

There is no universal right answer, but there is a right answer for your specific situation. The decision matrix is straightforward:

• Small team, simple CRUD, no engineering bandwidth: Retool or Appsmith. Ship it this week.
• Growing team, core workflow tool, long lifespan: Custom code with Next.js + shadcn/ui. Invest the time now.
• Any team, temporary or experimental tool: Low-code. Do not over-engineer something that might not exist in six months.
• Compliance-heavy environment: Custom code, self-hosted. You need the audit trail and code ownership.

The biggest mistake I see teams make is treating this as a religious debate — "we are a Retool shop" or "we build everything custom." The right approach is pragmatic: use the tool that matches the job's requirements, expected lifespan, and your team's current capacity. Build the important stuff. Buy the rest.