3 min read
Building internal AI tools: what Ramp and Stripe's bet reveals for small teams
Ramp and Stripe built their own internal vibe-coding platforms instead of buying vendor tools. The reasons are more instructive than the trend itself.
By intermac
The most interesting thing about the Ramp and Stripe story isn't that the tools work. It's that they get adopted when vendor tools don't.
Ramp's Glass is now part of new-hire onboarding, to the point where practically every non-engineer at the company uses it. Stripe's Harbor was built by a single engineer in about six weeks. These are not heroic engineering feats. They are modest, focused investments that produced something the organization actually wanted to use.
Vendor tools failed the adoption test not because they were technically inferior, but because they couldn't speak the organization's language: its data sources, its design system, its internal vocabulary. A custom CRM with 50+ fields built in Glass looks overwhelming from the outside, but it's exactly right for the person who made it. That fit is hard to get from a general-purpose platform.
The reasons that actually scale down
Large companies cite several benefits to building internal: data safety, design consistency, no vendor wait times, educational value for engineers. Not all of these scale down to a small studio.
Educational value scales fine—building AI infra makes your team better at AI infra. Design consistency scales fine too, if your internal tools touch user-facing surfaces. But the adoption argument is strongest at scale, where you have dozens of non-engineers who would otherwise struggle with a generic tool.
The one reason that scales down cleanly, regardless of team size, is data safety. If your workflow touches sensitive client data—and most professional workflows do—wiring that data into a third-party platform is a real risk, not a theoretical one. An internal tool removes that exposure entirely. For us, that consideration alone is often enough to tip the decision.
The trade-off vendors don't advertise
Building internal is not free. Ramp used two engineers for a few weeks; Stripe used one for six weeks. At a 500-person company, that's a rounding error. At a four-person studio, it's a meaningful chunk of capacity. You're also taking on maintenance: the tool will need updates, and nobody else will ship them for you.
Vendors, on the other hand, cost compliance reviews, price negotiations, and the constant friction of working around their abstractions. Gergely Orosz makes the point directly: selecting and tailoring the right vendor might take comparable effort to just building the thing yourself. That rings true to us.
What we'd actually do
For a small team, the build-vs-buy decision on internal AI tools comes down to two questions. First, does the tool touch data you cannot safely hand to a third party? If yes, build. Second, will the tool be used heavily enough to justify ongoing maintenance? If the answer is no, a vendor tool's rough edges are probably acceptable.
The Ramp and Stripe cases demonstrate something useful: a focused internal tool, scoped tightly and connected to real internal data, will outperform a general-purpose vendor product on adoption every time. The lesson isn't that every company should build its own Lovable. It's that internal fit matters more than feature count, and sometimes the fastest way to get that fit is to build it yourself.
Sources
- The Pulse: new trend of building “internal vibe-coding apps” at tech companies (original)
- Found via the TLDR newsletter