Building apps with Claude Code and Retool

There’s plenty of content right now pitting Claude Code against other tools. I don’t find that framing helpful when solving real-world challenges. These tools aren’t competing with each other. They solve different problems at different altitudes, and the interesting part isn’t which one wins: it’s how they work together. To put it simply: Claude is where I think, Retool is where I deploy.

I use Claude Code daily as a coding assistant in our codebase, and as an agent I built for my own workflow. I also use Retool daily. It’s where I build and deploy the tools, workflows, and agents that my team and the rest of the company actually use.

Claude (whether that’s Claude Code in my terminal or Claude Chat on my desktop) is a research partner, a pair programmer, and a prototyping environment. It's where I explore how systems connect, reason through API behavior, and work through problems before I start building. Retool is where the thing I built becomes something my team can use. It's where I deploy and share, securely and effectively.

In this post, I’ll break down what each tool does well, their limitations, and how I use them together in my role at Retool.

Claude Code is Anthropic’s terminal-based AI coding agent. It reads your codebase, edits files, and runs commands autonomously. You can run it in your terminal or in VS Code’s sidebar. It’s built for individual developers who want high-leverage assistance inside their existing workflow.

Having spent real time in both worlds, here’s where Claude Code works most powerfully.

Generating production application code

This is what it was built for. If you’re writing code for a product you're going to ship to users, Claude Code is home turf.

Working inside an existing codebase

Claude Code’s full-codebase awareness makes it especially strong for refactoring, debugging, and extending existing systems. It can reason across multiple files, not just as autocomplete, but understanding context and making informed changes.

Personal projects and solo tools

If you’re the only person who needs it and you have the technical skill to build with it, Claude Code is probably faster. I build websites and small web apps on the side, and I reach for Claude Code every time. There’s no reason to involve a platform with RBAC when something will only be used by you.

Rapid prototyping

When you’re still figuring out if something is worth building at all—before you’ve committed to infrastructure, before you know whether the idea has legs—Claude Code lets you explore fast and cheap. Prototype first.

The moment of reckoning comes when you build something with Claude Code, it works, you’re proud of it, and then someone from your team asks, “Can you share this with the rest of the team?”

Suddenly, you’re solving a completely different set of problems. Hosting. Authentication. Permissions. Networking. These are problems that have nothing to do with the tool you were trying to build, but they’re now your problems. Each one is a project you are responsible for because you showed just how fast you can build with Claude.

This is where builders (including myself) consistently underestimate the gap. You think you’re 80% done because the thing works on your machine. In reality, you’re about 20% done. The first thing that bites you is deployment: where does this thing actually run? Then it’s permissions: who’s allowed to see what? Then it’s maintenance: what happens when the API changes or a dependency breaks? Then it’s security: is this thing safe to connect to production data?

Each layer reveals the next, and none of them are trivial.

Retool is a platform for building and deploying internal tools, agents, and workflows that connect to your company’s production data. It’s purpose-built for teams who need to ship things their entire organization can use.

The friction you hit with Claude Code is exactly the set of problems Retool was built to solve.

Apps and internal tools your whole team needs to use

Permissions, access controls, and sharing are built in from the start. You share an app with a team, and access is controlled by permission groups you’ve already defined. You don’t set up auth, you configure it.

Anything touching sensitive company data

When you build on Retool, you evaluate the platform's security posture once, and every app you build inherits that baseline. With custom builds, you evaluate every app individually. That’s not a scalable approach when you're building dozens of internal tools, and it’s a real risk when the data involved includes PII, financial information, or anything subject to compliance requirements.

Agents that need to run without you

Retool agents run on schedules, respond to event triggers, include human-in-the-loop approval steps, and produce full audit logs. They’re accessible to your entire team, not tethered to whoever’s machine the agent happens to be running on. If your team depends on it, it can’t depend on your laptop being open. It would be disingenuous to say that Claude can’t run headless: it can, and you can see that in Mac Mini shortages. This still doesn’t resolve all the challenges of deploying, securing, and scaling software.

Connect to stable, managed integrations

Retool’s integrations are maintained by Retool. They’re tested, updated, and supported. MCP integrations, by contrast, are largely community-maintained, version-pinned to whenever you installed them, and liable to break silently when upstream APIs or the MCP spec itself changes. This doesn’t even begin to touch the challenges with MCP breadth and the lack of functionality on many connectors. The official MCP repository states that community servers “are untested and should be used at your own risk.” Spec-level breaking changes, like the removal of JSON-RPC batching and changes to return signatures, compound the issue. When you’re running something your team depends on, the stability of your integrations matters.

Let’s take a look at a few examples of how you can use Retool with Claude to maximize the strengths of each platform. Soon we’ll have an MCP server that fully connects each system, but here’s how I use each tool now.

Retool helps with query writing, UI building, and refactoring inside the platform. But a lot of my work involves reasoning across systems: figuring out how to format API requests for an external endpoint, mapping dependencies between services, and understanding how one system’s data model translates to another’s. That kind of cross-system research that identifies patterns is where I reach for Claude, because it’s what Claude is built for.

Sometimes the handoff is direct: I give Claude a problem, it works through the research and gives me findings, and I hand those findings to Retool, or I use them to make the edits myself. Claude does the thinking outside the box; I build inside it. These tools don’t step on each other in my day-to-day. They’re covering different ground.

A big part of my role involves standing up demos and integrating with resources I'm not deeply familiar with. Claude Code is invaluable here! It researches the resource integrations, drafts queries, and reasons through how the systems connect. Those outputs become Retool apps and workflows.

When I’m building a demo with an unfamiliar data source, Claude helps me understand how to set up the external system securely and properly for our use case. From there, I use Retool to generate mock data, hydrate the demo data source, and build the product experience on top of it. Claude helps me with the upfront learning, and Retool handles the delivery.

We recently migrated our applicant tracking system from one provider to another. Both systems had different API endpoints, different data models, and different query patterns, and we had workflows and apps throughout Retool that depended on the old provider's endpoints.

I used Claude Code to map the API endpoints between the two systems and rewrite the queries we had across our workflows. Claude did the cognitively expensive part: cross-system reasoning, mapping fields to their counterparts, and generating the updated queries. I reviewed and validated the outputs, then deployed them to the workflows and apps where they actually run.

That’s the pattern: Claude handles the research and reasoning. Retool is where the work lives and is executed.

About a month ago, when OpenClaw (formerly known as Clawdbot, Moltbot) went viral, I was excited by the promise. But the problems became clear quickly: it didn’t work consistently, was horribly insecure, and if I were to introduce it to our team, it would pose a risk to our business if I tried to apply it to any of our workflows.

So, in my personal time, I set out to create my own agent with Claude Code.

This started out as more of a learning exercise. Understanding what developers are building with these tools is part of my job, and I wanted to know (from direct experience) what the process looks like, where the friction is, and what the end result feels like to use.

I started small and, over the next few weeks, spent a few dozen hours getting it fitted to my workflow. Each integration was added piece by piece, either created by me or custom-forked from existing MCP servers and CLI tools that I tailored to my specific use cases.

The end result works, and it works really well… for me.

It has its bugs and quirks, but I don’t mind because I know how it functions. I know which edges to avoid and how to work around the rough spots. That said, I wouldn’t roll this out to my team, and even if I tried, it wouldn’t work because it’s custom-made for my integration access and workflow. That distinction is the whole point.

The distance from “works for me” to “works for my team” is massive, and heavily underestimated. My agent works because I built it, I maintain it, and I’m the only user. The moment you need someone else to depend on it, someone who doesn't know its quirks, who can’t debug a broken MCP integration at 10 pm, who just needs the tool to work, you need something built for that purpose. That experience is exactly why I can say with confidence: if you’re building agents for your team, build them in Retool.

The question isn’t “which tool should I use?” It’s “which layer of the problem am I solving?”

Claude code works best for exploring. Reach for it when:

Move to Retool for deploying and sharing apps. Reach for it when:

One tip: this framework is meant for when you don’t yet know what to build. If you already know you’re building an internal tool, just start in Retool, and you’ll be off to the races. The “start with Claude, land in Retool” path is for when you’re still in the exploration and research phase, figuring out whether something is feasible, how systems connect, and what the right approach is.

The best builders put outcomes first (even Linus explored vibe coding!) Claude Code is powerful. So is Retool. Knowing when to use each, and how they work together, is what separates a quick experiment from something that actually changes how your team works. Start building in Retool today.