Retool Blog | How a Data Analyst Built a Self-Serve Customer Insights App

When you live in a workflow every day, you don’t need a 20-page spec to know what’s missing. You feel the friction. The fastest way I’ve found to remove it is to let the person closest to the problem assemble the first version of the solution—and give engineering all the guardrails to keep it safe.

That’s what I did with our Gong Super App in Retool (more details on that in a minute).

I sit on the data team at Retool, so I’m far from a frontend developer. I spend most of my time in SQL, Python, and systems. But with Retool’s building blocks, I shipped a tool that our sales, success, and marketing teams actually use—without borrowing a sprint from product.

Thesis: Let business builders ship. Let engineering control the blast radius.

My team consistently fields a steady stream of questions like, “How often do customers mention [topic/competitor]?”, “Where did this objection come up last quarter?”, or “How are people describing us in their own words?” We had the data in Gong, but getting from question to answer involved a lot of context-switching and ad hoc work.

We didn’t need a new data pipeline. We needed a simple, trustworthy surface for searching, reviewing, and summarizing calls—ideally one that our go-to-market teams could use without us in the loop.

The Gong Super App is straightforward on purpose. To make it usable quickly, all it needed to do was:

None of this required frontend experience. It’s mostly wiring up components, writing queries to transform the data, and polishing the details that make an internal tool feel trustworthy.

I didn’t follow a traditional frontend workflow, and that turned out to be an advantage. Here’s what worked. Instead of writing React components and wrestling with build tools, I was dragging UI elements onto a canvas and wiring them to live queries. The feedback loop was instant—change something, see it update with real data, adjust based on what I learned. Here’s what worked:

My starter prompt to myself was: “How can sales/CS quickly find where customers mention X—and what should we do about it?” That shaped the UI, helping me stay focused on exactly what end users needed.

With Retool, you drop inputs and tables onto a canvas and wire them to real data immediately. You’re building with actual Gong calls from the start, not mockups. When I noticed people only cared about what customers said (not our reps), for example, I added an “external only” toggle. Identifying these kinds of patterns was easier when working with live data.

I didn’t write CSS. I used building blocks and focused on tiny quality signals. A loading skeleton instead of a blank screen. Right-aligned numerics for match counts. Monospaced timestamp chips you can copy. Small polish goes a long way.

I tested with real users early and often. When someone got confused by the interface, I’d fix it immediately—whether that was better column names, clearer empty states, or keyboard shortcuts. That tight loop is what made the difference between something that worked in theory and something people actually used.

When you talk about letting non-devs build production apps, the immediate concern is security and governance. It sounds like a risk. But giving non-devs the keys doesn’t mean giving up control. Retool provides the guardrails that kept everyone comfortable:

Once engineers and security configure these controls, they apply to every app you build, so everyone can build safely within those boundaries. These aren’t heroic processes—they’re boring, repeatable guardrails that make it easy to say “yes.”

The impact of this app wasn’t just about saving time—it changed how teams work, and made it easier for more teams to get closer to our customers. Instead of asking for help, or just dropping it altogether, they were sharing what they’d already found.

Fewer interrupts. Fewer “can you check X?” is always a win for a data analyst, and we certainly got that here. People can now self-serve and paste summaries into Slack instead of waiting on our team to run queries.

Faster feedback loops. Sales and CS teams answer questions in the moment with data instead of anecdotes. When someone asks “What did customers say about that feature?” during a standup, they can pull it up right there.

Sharper coaching and messaging. Summaries cluster the objections and unmet needs in the customer’s words, which makes enablement sessions more concrete. Instead of “customers have concerns,” teams are able to say “here are the three specific objections from last week’s calls.”

Reusable pattern. Once folks saw filter → review → summarize → share work here, they asked for the same flow on support tickets and product feedback. The pattern proved its value.

This app gave us something we didn’t have before: a way to surface qualitative insights from a huge amount of unstructured data. Instead of reading through hundreds of calls to spot patterns, we could search, filter, and summarize across everything at once.

Now we can take that capability and replicate it across data sources and disciplines. The skeleton I built for Gong calls works for any source that captures customer voice or operational signals.

For example, we could swap Gong for:

The skeleton is always the same: presets → filters → table → summarize selected → ask ad-hoc → trends. Once you build it once, you can adapt it to any text corpus you need to search and understand.

You don’t need a comprehensive guide to start—just a clear question and a willingness to iterate. The steps below work whether you’re searching Gong calls, support tickets, or product feedback. Here’s the 30-minute version I’d recommend to any analyst or ops lead:

You’ll learn more in an hour of clicking than a week of requirements. And once people see it working, they’ll help you make it better.

This didn’t happen because I wrote a better spec. It happened because I was close to the problem and had the keys to ship, while engineering gave me guardrails that made “yes” the safe answer. Once you see that combination work, it’s hard to go back.

Pick one high-friction question your team asks every week. Build the smallest surface that answers it. Ship in days, improve all quarter.