Ramp Built Its Critical Internal Tools on Retool. Here's the Build-vs-Buy Framework That Matters

Ramp's first internal tool wasn't a CRM. It wasn't a dashboard. It was a risk management system that let customer support agents adjust credit lines, review flagged transactions, and manage fraud cases, all from a single screen. They built it in weeks, not months. And according to Retool's customer page, Geoff Charles, Ramp's VP of Product (now CPO), credits the platform with contributing to an estimated $8M in cost savings across the company.

That number deserves scrutiny. "Estimated" is doing a fair bit of work here, and neither Ramp nor Retool has published the methodology behind it. But here's what isn't in dispute: Ramp built over 100 internal tools in its first year using Retool. The alternative, buying equivalent SaaS licences or building from scratch, would have cost more in either money or time. Probably both.

The question isn't whether Ramp got the call right. The question is whether *you* would.

TL;DR

• Ramp built 100+ internal tools on Retool in under a year, covering underwriting, fraud analysis, KYC/AML compliance, and customer data management.
• Retool's customer page claims $8M estimated savings and 20% operational efficiency gains. These figures come from Ramp's Geoff Charles and are not independently audited.
• 35% of enterprises have replaced at least one SaaS tool with a custom build, and 78% plan to build more in 2026 (Retool Build vs Buy Report, 817 surveyed).
• The 7Cs framework is the decision tool most teams skip. We break down each one for internal tools.
• Retool pricing: Free ($0), Team ($10 builder/$5 end user), Business ($50/$15), Enterprise (custom; SSO locked to Enterprise).
• Bottom line: Build-vs-buy isn't binary. The real question is which internal tools to build, which to buy, and when a platform beats doing either.

What Ramp built (and why it matters)

Geoff Charles didn't arrive at Ramp with a Retool playbook. He arrived with scar tissue. At a previous fintech startup, his team built their own internal CRM from scratch. "We built our own internal tool system, and that was very painful," he told Retool. The system pulled customer data for support calls. It worked until it didn't. Once it became unusable, product teams scrambled to fix tooling while the support team was already drowning.

At Ramp, Charles made a different bet. From day one, every internal tool went onto Retool. The most-used apps handle underwriting, fraud analysis, and risk management. One tool, from the risk team, lets support agents pull up a customer's full transaction history, review flagged items, and adjust credit limits from a single interface. Before Retool, according to Charles, these workflows would have required engineers to write custom queries or build entire micro-services. Now, the team that uses the tool also maintains it.

Charles told Retool the setup delivers "at least 10 to 20% improvement to operational efficiency." He's talking about three mechanisms: end users own the tools they use, the feedback loop between "this is broken" and "it's fixed" collapses from weeks to hours, and the people doing the work modify workflows without filing a ticket.

What Brex learned the hard way

Ramp's approach looks obvious now. It wasn't obvious to Brex.

Before Brex existed, its founders worked at Pagar.me, a Brazilian payments startup. Pagar.me built 15 separate internal tools, each with its own codebase. At first, this worked. Then component library changes started breaking tools. Test coverage was poor. The codebase became spaghetti. Fifteen tools, fifteen maintenance burdens, zero shared infrastructure.

When the Brex team started fresh, they used Retool from day one for risk, compliance, and operations tools. Derek, one of Brex's founders, built his first project (a transaction simulator for testing) in 30 minutes. "Before Retool," he said, "I would have taken hours, or days, to create a simple command-line tool that no one else would have used." That simulator is now used daily across Brex's engineering team. The company scaled 10x in three years.

The pattern is identical in both cases: internal tools treated as first-class product infrastructure, not afterthoughts. Pagar.me is the cautionary tale. When internal tools are bolted on after the product ships, they rot. When they're part of the architecture from the start, they compound.

The 7Cs framework: the decision tool most teams skip

So far, this looks like a vendor case study. Two fintechs used Retool, things went well, end of story. But the real value isn't in deciding whether to use Retool. It's in having a framework for deciding *what kind of software infrastructure you actually need*.

Sue Nallapeta, now CTO at 23andMe (formerly CTO at Trusted Health, VP of Engineering at Apartment List and Zoosk), developed what she calls the 7Cs framework for build-vs-buy decisions. She's made enough mistakes to know that most teams skip the framework step entirely. They default to whatever the loudest person in the room prefers: "we should own this" or "just buy Salesforce and move on."

The framework forces seven questions. Here's how they apply to internal tools.

1. Core Capability

Is the thing you're building your actual product, or is it support infrastructure?

If it's your product, build it. You don't outsource the thing customers pay for. But internal tools are almost never core capability. Ramp's core capability is corporate cards and expense management, not the risk dashboard their support team uses. That dashboard is critical, but it's not what customers pay for. Nallapeta's rule: if buying gets you 80% of the way there and you can configure the last 20%, buy. If building lets you ship faster on your actual product, build.

2. Cost

Most teams only count engineer salaries. Nallapeta's framework forces you to count maintenance, hosting, onboarding, offboarding, and the cost of being wrong.

Ramp's $8M figure (again, estimated and vendor-supplied) attempts to bundle all of this. But the biggest line item in build-vs-buy isn't the build. It's the maintenance. Retool's 2026 Build vs Buy Report found that the maintenance iceberg (ongoing fixes, dependency updates, onboarding new team members to custom tools) is the top reason teams abandon custom builds and switch to platforms. If you build it, you're on the hook forever.

Current pricing makes this concrete: Team is $10 per builder and $5 per end user per month. Business is $50 per builder and $15 per end user. Enterprise is custom, and here's the catch: SSO is locked to Enterprise. If you're a mid-size company that needs single sign-on, you're negotiating a custom contract before you've built anything. That changes the cost equation.

3. Complexity

Do off-the-shelf tools fit your workflow, or do they force you to work their way?

Fintech is a good test case. Most SaaS tools aren't built for fintech's specific workflows. Underwriting, KYC/AML compliance, transaction monitoring, these require tools that talk to your specific data in your specific format. Buying a generic CRM means forcing your risk team to work inside a tool designed for sales pipelines. That's complexity you're importing, not solving.

Nallapeta's advice: if your requirements are bespoke enough that you'd spend more time configuring a bought tool than building a custom one, build. On a platform like Retool, "build" doesn't mean from scratch. It means assembling from primitives that already exist.

4. Competence

Do you have the people who can build and maintain this? Can you afford the opportunity cost?

Geoff Charles's previous team tried to build an internal CRM and failed. Not because the engineers weren't good. Because internal tools are a different discipline from product engineering, and maintaining them pulls your best people away from the work that actually differentiates your company. Charles's insight at Ramp: Retool shifts tool ownership to the people using the tools, not the people who could be building the product.

5. Cohesion

Will what you build or buy integrate cleanly with the rest of your stack?

This is the hidden killer of "just buy it." You buy five SaaS tools, each with its own data model, and suddenly you're running an integration tax every time you add something new. Pagar.me's 15-tool nightmare is the extreme version. The more common version is a team that spends 30% of its time maintaining glue code between bought tools that don't talk to each other.

6. Competitive Advantage

Does building this tool help you win? Or is it just keeping the lights on?

Ramp's risk management tool probably doesn't win them customers directly. But it lets their support team move faster than a competitor's, which means better customer experience, which means retention. That's competitive advantage by proxy. Nallapeta's framework says: be honest about whether you're differentiating or just operating. Most internal tools are operations, not differentiation. Build them efficiently and move on.

7. Culture

Does your organisation default to building or buying? And is that default helping or hurting?

Some companies have a builder culture so strong they'll build a calendar app rather than use Google Calendar. Others have a buyer culture so ingrained they'll buy five overlapping tools rather than fire up a code editor. Neither extreme is rational. Nallapeta's point: you need to know which bias you carry before you can correct for it. If your engineering team reflexively says "we'll build it," show them the maintenance numbers. If procurement reflexively says "buy it," show them the integration spreadsheet.

The pendulum is swinging

The 7Cs framework isn't theoretical. Retool's 2026 Build vs Buy Report found that 35% of teams have already replaced at least one SaaS tool with a custom build. 78% expect to build more in 2026. The categories most at risk: workflow automations (35% replacing), internal admin tools (33%), and BI tools (29%).

This isn't happening because companies suddenly love writing code. It's happening because platforms like Retool have shrunk the cost and complexity of building to the point where the old assumptions ("always buy unless it's core IP") no longer hold. A functional risk management dashboard in weeks rather than months shifts the calculus.

"Build" in this context doesn't mean hiring a dev team and writing React from scratch. It means using a platform that handles the boring infrastructure so your team can focus on the logic specific to your business. That's the variable that changed the equation.

The takeaway

Build-vs-buy was always a false binary. The real question is three-way: buy a SaaS tool, build on a platform, or build entirely from scratch. The 7Cs framework gives you a way to decide instead of defaulting to whatever your organisation did last time.

Ramp's story is compelling but it's a vendor-supplied case study. The $8M figure is estimated. The 20% efficiency gain is self-reported. The 100-tools-in-one-year stat is impressive but doesn't tell you what those tools do or how many are actively used.

None of that invalidates the core insight. Ramp built internal tools from day one on a platform. They didn't treat internal tooling as an afterthought. They didn't buy a stack of SaaS products and hope they'd integrate. And they didn't make their product engineers maintain a parallel codebase. That three-part decision (build on a platform, treat as first-class, keep product engineers on product) is what actually matters. The framework exists so you can adapt that decision to your context, not copy Ramp's.