When it comes to building client apps in Retool, there’s a difference between building something impressive and building something useful. Just ask Miguel Ortiz.
Miguel runs BuildReallyFast.com, a Retool consultancy that’s helped dozens of clients transform chaotic workflows into fast, focused, and functional tools. In the Community forum’s inaugural episode of Builder Talks, an interview series featuring community experts, As a top contributor to the community forum, Miguel shared what he's learned about designing apps for clients—and more importantly, what to leave out.
Here, you’ll find his guidance on what to build, what not to, and how to make sure the stuff you ship actually gets used.
Miguel’s message is simple but powerful: keep your apps small. While Retool now supports multipage apps, Miguel—who has built hundreds of tools for clients through his agency, BuildReallyFast.com—still sticks to the principle of breaking functionality into focused, lightweight applications.
“Clients start complaining when the app gets too big. It gets slow, hard to debug, and harder to maintain.”
The temptation to build a sprawling all-in-one solution is strong, especially when clients are excited and the canvas is wide open. But when apps start bloating with too many queries, components, and nested interactions, things slow down—both technically and for the end user.
Instead, Miguel emphasizes modularity:
- Split apps by function, not department.
- Keep logic tight with 2–3 key workflows per app.
- Use Retool Workflows for complex logic or integrations that span multiple apps.
Retool’s new global variables and multipage app support can certainly improve navigation, but they’re not a free pass for making your app an entire ERP system. If anything, these tools make it easier to stay modular while still offering seamless experiences.
Miguel pointed out that while multipage apps have made it easier to organize functionality, he still prefers keeping apps separated by role or task. Not just for performance—but for client clarity.
“If it gets big, clients don’t know where to click, or what the app is for anymore.”
Smaller apps help enforce a single-purpose mindset—what am I trying to do here?—for both the developer and the user.
Some red flags that your Retool app might be suffering from scope creep:
- You’re managing more than five user-facing views within a single app.
- You're hitting rate limits or timeouts from bloated queries.
- You've had to create elaborate workarounds for state management across too many components.
- Clients are asking for “just one more” feature... repeatedly.
When that happens, it’s probably time to break it up—or reach for a workflow or global state to bridge apps more gracefully.
In Retool, there’s often a temptation to keep everything inside your app’s main interface—especially when working fast. But as apps grow more complex or span multiple data sources, it’s not just a matter of best practice—it’s a matter of performance, maintainability, and client sanity. Workflows are Miguel Ortiz’s go-to tool for managing that complexity, and if you’re building client-facing tools, they should probably be yours too.
Miguel Ortiz shares a golden rule of thumb that’s saved him (and his clients) more than a few headaches:
If your Retool app needs more than three queries to fetch, transform, and combine data—use a workflow.
Why? Because once you’re stitching together multiple data sources or writing complex logic, putting that load into your app UI can make things feel messy fast. Not only does it bog down performance, it also creates an invisible tangle of dependencies that become harder to debug later on.
Workflows help you:
- Keep query logic out of the front-end, where it clutters component code.
- Reuse complex fetch/transform logic across different apps.
- Make asynchronous processes (like API calls and retries) easier to track.
Even if the workflow itself is simple, offloading complex logic away from the UI gives your app space to breathe.
For Miguel, workflows aren't just about logic separation—they're a lifesaver when it comes to debugging.
Unlike app queries, workflows come with built-in logging and block-by-block inspection. That means when a client reports an error or something doesn’t work as expected, Miguel can go into the workflow, find the exact execution run, and see where things went wrong—without having to reverse-engineer every component’s behavior.
This alone makes workflows worth the investment.
“I love how workflows give you a full debug trail. If a client says something didn’t work, I don’t have to guess. I just look at the workflow run history.”
Bonus: Once a workflow is built cleanly, it can be reused across apps. Miguel often modularizes logic into workflows so he can plug them into other projects without rebuilding the wheel.
For a solo developer juggling multiple client projects, the right tool can mean the difference between a clean, scalable build and a rabbit hole of technical debt. In the Builder Talk video, Miguel doesn’t just talk theory—he shares the actual features and techniques he uses every day to ship fast and stay sane. These aren’t “nice to haves”—they’re how he ensures his apps will be client-ready.
Miguel is all-in on global functions—a newer Retool feature that lets you define reusable snippets of logic across apps.
These help him:
- Standardize data formatting logic.
- Avoid repeating common tasks across components.
- Ensure consistent variable behavior across complex apps.
One of his favorite use cases? Setting and updating global state without introducing weird edge cases. Instead of writing JavaScript inline for each component, Miguel wraps logic in a global function and calls it wherever he needs to update state safely.
“Every action that touches state—I try to wrap it in a function. It’s just safer. It keeps things clean.”
Global variables also feature heavily in his approach to multi-page apps. Instead of using brittle local state, Miguel stores things like in-progress form data or selected user IDs in globals—so users can jump between pages without losing work.
Miguel calls out two features he uses on nearly every query:
- Transform Results: Especially formatDataAsArray, which he adds by default.
- Event Handlers: Often chained with a Run script block for flexibility.
The real insight here is that these aren’t just powerful—they’re habits. Miguel applies them consistently to every app he builds, even if the app is tiny. That consistency makes it easier to onboard clients, debug apps, and avoid regressions later on.
“Even if I’m not sure I’ll need it—I’ll format the data, add the event handler. It saves me from rewriting later.”
For Miguel, Workflows aren’t just a backend feature—they're a philosophy shift.
In Retool, workflows allow you to build and orchestrate multi-step logic using a visual builder. But when do you know it’s time to build one? Miguel recommends building out a workflow if three or more queries are required to complete a task.
That number isn’t arbitrary. Here’s why.
When building data-rich apps or integrations, you’ll often find yourself:
- Pulling from multiple resources (e.g. APIs, internal databases, third-party tools).
- Cleaning or transforming results before surfacing them in your UI.
- Needing logic that’s reusable across multiple parts of the app or even multiple apps.
Once the orchestration of that logic spans more than a couple of queries, putting everything inside a visual workflow makes things more maintainable. You get debugging tools, versioning, error handling—and you don’t need to overload your app logic with backend data plumbing.
“I love Workflows for debugging. You can look back at the history of every run and see exactly what happened at each block. That’s something you just don’t get with in-app queries.”
Workflows also help teams avoid “copy-paste query soup”—where business logic gets duplicated in multiple apps and no one remembers where it came from.
By building discrete workflows that handle things like syncing external data, transforming large datasets, or enriching internal reports, you’re creating shared backend primitives that can be versioned, improved, and reused over time.
This makes your Retool instance cleaner, your apps faster, and your teammates happier.
Building internal tools in Retool isn’t about copying and pasting your spreadsheet workflows into a new UI. It’s about rethinking what a system can do—and how to reduce the friction of managing data at scale. In Miguel Ortiz’s Builder Talk, this idea was a recurring theme.The goal isn’t to move your mess into Retool. It’s to replace the mess with structure.
Many Retool projects begin with a spreadsheet: dozens of tabs, manual steps, inconsistent columns, and logic that lives in someone’s head (or in fragile formulas). Miguel emphasized that for small and medium businesses especially, this chaos adds up. One of the most appreciated projects he's built? A simple app that replaced Excel-based personality testing with a structured, sharable, automated workflow.
“The client was sending Excel sheets to 100+ people. If someone typed a 6 instead of a 5, the whole thing broke. Now they just send a Retool link. Done.”
Replacing that spreadsheet wasn’t about matching it feature-for-feature. It was about understanding the job it was doing—and delivering a better system that saved the client hours every week. That’s what Retool is for.
Miguel put it bluntly in the session: “Unless there’s a very specific edge case, I don’t integrate with Google Sheets.” The reason? As soon as you keep Google Sheets in the loop, you reintroduce all the problems you were trying to solve in the first place: inconsistent edits, unclear ownership, hard-to-scale workflows, and more.
Instead, Retool gives you the chance to be the source of truth. With support for databases like PostgreSQL, integrations with Airtable or Supabase, and native support for APIs, you can build your own internal systems the right way from the start.
I is everywhere right now. But in Retool apps? It's not about building a chatbot for everything. It's about knowing when AI can accelerate your work—and when it’ll just generate more noise. Miguel Ortiz makes smart, grounded use of AI in his workflow, and his take is refreshingly un-hyped.
Miguel credits AI—specifically LLMs like ChatGPT—with helping him become a developer in the first place.
“I studied law. I wasn’t a developer. ChatGPT became my professor.”Miguel Ortiz
When he was first getting started with Retool and JavaScript, he used ChatGPT not just to generate code, but to explain it back to him. That learning-first approach stuck. Today, he still uses LLMs regularly to draft snippets, troubleshoot ideas, and think through logic faster than he could solo.
He even keeps one screen open for LLMs while working—almost like a pair programmer.
Beyond learning and drafting, Miguel also builds light AI into client apps when it makes sense. Common use cases include:
- Extracting structured data from uploaded documents (e.g. invoices)
- Summarizing long-form content or report outputs
- Cleaning and standardizing messy inputs
These aren’t sci-fi use cases. They’re practical, time-saving automations that slot neatly into workflows clients are already using.
There’s a clear throughline in Miguel’s approach: AI is never the main product. It’s always the assistant, never the hero.
“They’re appendices to the actual app. Not the app itself.”
Clients may be excited about AI—and sometimes even ask for “something with ChatGPT.” But Miguel cautions against building AI just for AI’s sake. Unless there's a clear, value-driving use case (like saving the client time or surfacing insights they’d otherwise miss), he steers the project back toward business impact.
Some smart heuristics he uses:
- Use AI when it saves repetitive human work (summarizing, extracting, cleaning).
- Use it to accelerate your own thinking during development.
- Don’t use it as a crutch for app logic or schema design.
- Don’t make it the centerpiece unless the business case is airtight.
In other words: treat AI like you treat Workflows or global variables—powerful tools when used intentionally. But not something to reach for just because it’s shiny.
If there’s one lesson to take from Miguel Ortiz’s approach to Retool consulting, it’s this: build with intention.
Not every client idea needs to become an app. Not every spreadsheet deserves a second life. The best Retool builders—especially those working with clients—know how to separate the genuinely helpful from the merely possible.
Here’s the cheat sheet Miguel leaves us with:
- Keep apps small and focused. If it feels like an ERP, break it up.
- Reach for workflows when logic gets heavy—or when reuse matters.
- Default to structure over chaos. Don’t mirror messy spreadsheets. Replace them.
- Use AI to accelerate, not distract. It’s a tool, not a product.
- Build systems people actually want to use. Then walk away proud.
Miguel’s tools don’t win awards for flash. They win because they work. Whether you’re a solo builder, an internal dev, or running a consulting shop of your own—Miguel’s approach offers a clear path: build what’s meaningful, not just what’s shiny.
Want to see more of his process? Watch Miguel’s full episode of Builder Talks.
Thank you to Mathew Pregasen for his help on this article.
Reader
