In the early 2000s, Google had a unique problem: more customer data than any CRM on the market could handle. Bryan Schreier, a partner at Sequoia Capital, worked at Google when they built their own CRM, and it worked for a long time.
Google’s effort here was a success story, yet the conventional wisdom is: don’t try to build like Google. Most companies don’t have Google’s scale or data problems, and definitely not its engineering resources. Adopting Google-scale solutions tends to be cargo-culting that causes more problems than it solves.
But AI-assisted development has collapsed the cost of building software. The number of pull requests Retool merges daily is nearly 10 times higher than it was 18 months ago. That step change isn’t unique to Retool; we see the same pattern across our customer base.
Replacing build vs. buy with build with AI makes custom software accessible to everyone, but it also exposes a whole new cohort of builders to challenges that have historically only impacted experienced engineers. Bryan recently sat down with Retool’s CEO David Hsu to talk through what’s next for software builders, the new bottlenecks that have emerged, and how organizations can use governance to harness this speed and energy towards productive ends.
For most of the history of enterprise software, the build side of the build vs. buy equation was constrained by the cost and scarcity of engineering time. Buying a SaaS tool was faster and cheaper than building, and in most cases the gap was wide enough to make the decision a no-brainer. That gap has compressed dramatically. Teams that once had no realistic path to custom software can now build exactly what they need, faster than any procurement process was designed to handle.
Our 2026 Build vs. Buy Shift Report found that a staggering 60% of teams are shipping software outside official IT oversight. That number could easily be read as a governance failure, but teams aren’t usually trying to go rogue: they’re building because they can, and because the tools and processes meant to govern software acquisition were designed for a world where building was slow and expensive.
When Bryan was building at Google, governance was the foundation, not a bolted-on afterthought. Google had other scaffolding in place to support its own CRM: Perforce (an enterprise-grade version control system) for source code management, an internal cloud platform called Borg, and organizational processes that kept all of it governed. When Bryan’s team eventually pushed boundaries and broke things, there was accountability.
“Until now most companies in the world have not had these resources, nor the infrastructure or governance support,” said Schreier.
The pace of code has accelerated and expanded software building, but the engineering infrastructure that made Google’s build sustainable (robust version control, access controls, audit logs, organizational accountability) hasn’t come along for the ride. The capability to build is there, but the scaffolding that makes building safe at scale is a separate problem.
For as long as software engineering has existed, the primary guardrail on code quality has been human review. As the models have improved, the critical consideration now isn’t how good or bad the code is, but rather who is responsible for it.
“We’re generating way more code than we ever have before,” David said, “It used to be the case that every single line of code was either written by an engineer or reviewed by an engineer. How do you govern all of this code being generated all the time?”
That process is slow, but it does catch problems. With a firehose of new code, much of it written by non-engineers, the review guardrail no longer scales. When human code review was the primary guardrail, there was a clear chain of accountability. That simply doesn’t scale.
Enterprises take security and accountability seriously. Non-engineers are now building apps—exactly what you’d hope to see from a well-resourced company leaning into AI-assisted development. The problem arrives when those engineers bring their apps to a head of IT and ask them to deploy, host, and maintain them.
The traditional IT accountability structure doesn’t hold. If there’s a security vulnerability in an app a CIO’s team didn’t build and doesn’t control, who fixes it? If an AI-generated piece of code introduces a bug that affects customers, who’s on the hook?
Those questions don’t have a good answer in most organizations right now, because the tools that enable building have scaled faster than the organizational structures that govern them.
David and Bryan concluded that governance defined app-by-app or engineer-by-engineer doesn’t solve the problem. The volume is too high, and the builders too scattered. Governance has to live at the platform level: defined once, and inherited by everything built on top of it.
In practice, governance at the platform level means things like:
- Single sign-on configured at the platform level so every app inherits it by default
- Audit logging that happens automatically
- Data access controls that determine which resources any app can touch, regardless of who built it
The goal, as Bryan describes it, is that builders and users don’t have to think about security implications “because that’s not their job.” Security becomes a property of the environment, instead of relying on each individual developer.
David describes what this looks like among Retool customers that have embraced building on the platform: 70-80% of the company is actively building applications, with IT delighted rather than alarmed. When the guardrails are in the platform rather than in the review process, the review process no longer has to scale with the volume of code.
This is effectively what Google had 20 years ago. Source code management, an internal cloud, access controls, organizational accountability. The technology is different but the principle is the same: the infrastructure around the code matters as much as the code itself.
The companies treating platform-level governance as a first-order problem, rather than something to sort out after the building starts, are the ones positioned to get the most out of the current moment.
“We all want to see more innovation and creativity coming out of enterprises,” Bryan says. “I think it’s easy to forget the amount of scrutiny that IT and customers put software vendors through from a security perspective—kicking the tires around the vehicle until a decision is made. That’s not happening unless you have great governance.”
As Bryan put it, there is no sustainable end state other than good governance. It’s something orgs can (and should) build towards intentionally rather than learning the hard way.
“What you really need in order to harness the creativity and opportunity, is a platform for governance,” Bryan says. “That’s what enables people to build applications and be creative and move enterprises forward, but built in such that the builders themselves don’t even have to think. That’s how we cross this chasm between risk and opportunity when weighing build vs. buy.”
