DEV Community

Cover image for Open Source Retool Alternative: A Code-First, AI-Native Approach
Tomasz Karwatka
Tomasz Karwatka

Posted on

Open Source Retool Alternative: A Code-First, AI-Native Approach

If you build internal tools in Retool, the last twelve months probably felt different. Pricing changed. Self-hosting quietly moved behind the Enterprise wall. AI features arrived, but if you tried to push them past a demo, you noticed they only generate apps from Retool's own components.

This post is not a "Retool is dead" rant. Retool is still good at what it has always been good at — drag-and-drop CRUD UIs over your databases. But there's a category of teams for whom the trade-offs no longer make sense, and the open-source landscape has matured enough that staying in a closed platform is now an active choice, not a default.

I'll walk through:

  • What actually changed in Retool in 2025/2026
  • The current open-source alternatives and where each one fits
  • A code-first, AI-native approach (Open Mercato — disclosure: I work on it)
  • When Retool is still the right call

What actually changed in Retool

A short factual recap so we're on the same page:

  • Self-hosting is now Enterprise-only (since Feb 2026). The docs were updated quietly without an official announcement, which is what set off the Reddit threads.
  • Team → Business is a 5.4× jump ($12 → $65 per standard user/month). Audit logging, SSO and Git all live in Business or higher.
  • AI features will be consumption-based. Currently bundled, but Retool's own pricing pages flag prompt credits as future metered cost.
  • Apps cannot be exported. This is a design choice, not an oversight — Retool builds UI from proprietary components.

None of this is unusual for a maturing SaaS. It's textbook PLG-to-Enterprise conversion. But it has consequences if you're the engineering lead deciding where the next 50 internal tools live.

Where teams hit the wall

Three painful situations come up repeatedly in G2, Reddit and HN reviews:

  1. The JavaScript-only ceiling. Custom components, complex business logic, anything you'd normally drop into a real backend — you end up shoehorning it.
  2. Compliance and self-hosting. HIPAA (no BAA), SOC2, EU data residency. Self-hosting now requires Enterprise.
  3. Incoherent AI story. Half the team uses Cursor, half uses Claude Code, seniors get good output, juniors generate chaos. Retool Assist sits on top of this but doesn't help, because it generates only from Retool components.

If none of these hit you, Retool is probably still the right tool. If they do, the rest of this post is for you.

The open-source Retool alternatives — quick map

Tool License Best for Weak point
Appsmith MIT Code-first devs who want Retool with Git No native AI app generation
ToolJet AGPL v3 Mixed teams; best AI app generation in OSS Performance with large datasets; AGPL concerns
Budibase GPL v3 Fastest CRUD-from-database setup Hits limits on complex apps
Superblocks Agent-only OSS Enterprise governance + RBAC, code export Custom pricing, no built-in DB
Refine.dev MIT Senior React devs who reject drag-and-drop No AI layer; not batteries-included
NocoBase MIT Data-model-driven internal apps, ERP-style Smaller US presence
Open Mercato MIT Code-first teams who want AI-native foundation + CRM/ERP domain model Newer, smaller community

Each one solves a different slice. Appsmith is the closest like-for-like Retool replacement if you want drag-and-drop with Git. ToolJet is where the AI app generation in OSS actually works today. Budibase is the fastest path from a Postgres schema to a working CRUD UI. Refine is for teams who decided drag-and-drop isn't the answer.

The rest of this post covers the slice Open Mercato is built for: teams who want a code-first foundation, full ownership, and AI tools that produce consistent code across the whole team.

Open Mercato in one paragraph

Open Mercato is an MIT-licensed npm package that gives you an opinionated foundation for building internal tools, CRM, ERP modules and customer-facing operational apps. It's full-code (TypeScript / Next.js / PostgreSQL), not low-code. The novel part is that it's designed for AI agents — Cursor, Claude Code, Codex — to write architecture-aware code against it, because the architecture and specs ship inside the repo.

You start a project with:

npx create-mercato-app
Enter fullscreen mode Exit fullscreen mode

What you get is roughly 80% of the boilerplate already done: data model, RBAC, auth, audit trail, field-level encryption (AES-GCM), per-tenant isolation, override patterns. The remaining 20% is your domain logic.

The differences that matter to a Retool user

1. Code ownership vs vendor lock-in

Lock-in vs ownership

Retool apps live inside Retool. If you decide to leave after building 50 tools over three years, you're rebuilding from scratch. Retool itself acknowledges this in its own content marketing: "Using a proprietary tool for visual programming also comes with the risk of vendor lock-in."

Open Mercato is a normal TypeScript repo on your machine. Your code, your Git history, your CI/CD. If the project disappeared tomorrow, you'd still have a working monorepo. There is no platform to be locked into — it's a package and a set of conventions.

2. AI that knows where things go

Architecture-aware AI

This is the part I find most underrated. Most "AI in low-code" features generate apps from a closed component library, which is fine for demos but limits customization. Most "AI in your IDE" tools (Cursor, Copilot, Claude Code) are powerful but have no idea what your project's architecture is — they generate snippets, and consistency depends on the human reviewing the diff.

Open Mercato ships specs in the repo from day one. When an agent writes a feature, it has:

  • The data model in machine-readable form
  • The layering rules (where business logic goes, where validation goes, where UI goes)
  • The override pattern (how to extend without forking)
  • The naming and folder conventions

The result is that Cursor or Claude Code generates code that fits the project instead of code that fits the prompt. A junior developer can ship features that pass review on the first try, because the agent has guardrails.

This is a different idea than "AI app generator." It's: give your team a foundation where AI tools are productive by default.

3. Self-hosting as the default, not the upsell

You run Open Mercato wherever you run Postgres and Node. There is no cloud-only edition, no separate Enterprise SKU for self-hosting, no surprise data-residency conversation with your security team. For regulated industries (healthcare, finance, defense, anything with EU data), this is the difference between a six-week procurement cycle and a thirty-minute docker compose up.

4. Pricing model

Open Mercato core is MIT-licensed and free. No per-user, per-builder, per-end-user tax. If you're at 50 users on Retool Business today, you're paying ~$39k/year for licenses alone. Open Mercato moves that money into engineering time, which is usually the trade you want.

5. Code-first with sensible defaults

This is where Open Mercato sits closer to Refine.dev than to Retool. If you've used Refine, you already understand the pattern — a meta-framework that handles the boring parts of CRUD-heavy enterprise apps so you can write actual code for the interesting parts. Open Mercato extends that idea with a domain model (CRM, ERP, ops) and the AI-engineering layer described above.

If you've been resisting Retool because "I'd rather just write code, but I don't want to write the same admin layer for the fifteenth time," this is the shape you've been looking for.

When Retool is still the right call

Honest trade-offs:

  • You have non-technical builders assembling tools. Retool's drag-and-drop is genuinely better for this audience.
  • You need a tool live this afternoon for a one-off ops task. Retool's time-to-first-app is faster.
  • You are deeply embedded in Retool's integration library and don't want to wire up sources yourself.

Open Mercato (and most code-first OSS alternatives) pays off when the work has scale, longevity or compliance requirements that make ownership of the code matter.

What a migration usually looks like

Most teams don't migrate everything at once. The pattern that works:

  1. Pick the most painful Retool app — usually one that's hit the JS-only ceiling, or one that handles regulated data.
  2. Rebuild it on the new stack. With AI assistance and a prebuilt foundation, this is days, not weeks.
  3. Run them in parallel. Migrate users when the new tool is at parity.
  4. Use the experience to set conventions for new tools.
  5. Old Retool apps that are working fine? Leave them. Migration cost only makes sense where there's real pain.

Where to start

The point isn't that any one of these replaces Retool. It's that the category has matured enough that "open source Retool alternative" is now a real shopping list, not a wishlist.

If you've made one of these jumps recently, I'd be curious which trade-off pushed you over the edge — pricing, self-hosting, the AI story, or the lock-in. Drop a comment.

Top comments (0)