Is data or compute the real bottleneck for AI?

For most companies it is data. Compute gets cheaper on a predictable curve every year, so raw processing power is increasingly a commodity you can rent. High-quality data does not follow that curve: it has to be found, cleaned, licensed, and in regulated fields negotiated through privacy and compliance rules. That is the argument the founders of Flapping Airplanes made at Sequoia's AI Ascent. Today's strongest AI, search and coding, works because the internet supplied enormous amounts of free training data. Outside those data-rich areas, progress is gated by data, not GPUs. For a founder, that means your hardest constraint is usually getting the right data, and your most durable advantage is data your competitors cannot get.

What does data efficiency mean in AI?

Data efficiency is how much capability a model gets per unit of training data. A more data-efficient method reaches the same performance on far fewer examples. It matters because humans learn skills like coding from a tiny fraction of the examples a current model needs, which suggests today's heavy data appetite is a limitation of current techniques rather than a hard law. If models become more data-efficient, the advantage of hoarding a massive proprietary corpus shrinks, and smaller teams can reach useful capability without frontier-scale data. For founders, improving data efficiency, and picking narrow problems where a smaller, well-fed model wins, is what makes competing without a giant dataset realistic.

What is the difference between data-rich and data-poor AI problems?

A data-rich problem has a large, cheap, existing supply of training examples, like public text and code, which is why search and coding assistants matured first. A data-poor problem has scarce, expensive, or locked-up examples, like robotics, scientific discovery, trading, and most regulated industries. The trade-off is defensibility: data-rich problems are easy to start but hard to defend because everyone has the same data, while data-poor problems are hard to start but much easier to defend once you solve the data supply. Knowing which one you chose tells you where to spend effort. In a data-poor domain, your product roadmap is mostly a data roadmap.

How does a startup build a data moat?

By collecting proprietary data that competitors cannot easily get, then compounding it. You will not out-collect a large incumbent on public data, so focus on data only your product and customers can produce: the workflow exhaust from real usage, labeled outcomes from your customers, and real-world signal others ignore. Instrument your product from day one so ordinary user actions become labeled examples you own, and confirm you have the legal rights to collect and use that data, especially in regulated fields. Over time this proprietary dataset becomes the moat a model alone cannot copy, because a competitor can license the same model but not your data.

Data for AI: The Founder's Real Bottleneck

Every AI roadmap right now is a fight over compute. Who has the most GPUs, the biggest cluster, the next model. At Sequoia's AI Ascent, the founders of the research lab Flapping Airplanes, brothers Ben and Asher Spector, made a quieter argument that matters more for most startups: the real bottleneck is not compute, it is data. Flops keep getting exponentially cheaper. Good data does not fall nearly as fast.

That reframing changes how a founder should think about what to build and where the moat is. Here is the founder's version of a data strategy, drawn from that talk and from what other builders have learned the hard way.

Why data, not compute, is the real bottleneck

The core claim is simple. Compute scales; data does not. The cost of a flop drops on a predictable curve every year, so raw processing power gets cheaper over time. High-quality data does not follow that curve. It has to be found, cleaned, licensed, and often negotiated for, and in regulated domains it is tangled in privacy and compliance rules that no amount of GPUs will unblock.

Today's most impressive AI lives exactly where data is abundant. Search and coding work because the internet handed the models billions of examples for free. The Flapping Airplanes founders point out the flip side: most of the economy is not like that. As they put it in the talk, "If you care about the broad deployment of AI into the economy, you should care about making models much more data efficient." A world that needs less data to reach a capability is a world where more companies get to compete, instead of only the few who already sit on a giant proprietary corpus.

Data-rich and data-poor problems are not the same bet

The most useful thing a founder can take from this is a filter. Before you build, ask whether the problem you picked is data-rich or data-poor.

Data-rich: there is a large, cheap, existing supply of examples (public text and code, web pages, transcripts). Models already do well here, which also means competition is fierce and the advantage is thin.
Data-poor: the examples are scarce, expensive, or locked up (robotics, scientific discovery, trading, most regulated industries). Progress is slower, but whoever solves the data problem owns something durable.

Neither is automatically the better business. A data-rich problem is easier to start and harder to defend. A data-poor problem is harder to start and much easier to defend once you crack it. Knowing which one you signed up for tells you where your effort has to go: in a data-poor domain, your product roadmap is mostly a data roadmap.

Your proprietary data is the moat a model cannot copy

This is where the research talk meets the founder's reality. If capability increasingly comes from data, then the data you can get and your competitors cannot is your moat, more than the model you wrap.

In a Greylock conversation on building for AI agents, the point came up from the incumbents' side: large companies sit on years of proprietary data, while startups can move and innovate freely but start with an empty warehouse. That is the trade. As a founder you will not out-collect an incumbent on their turf, so the move is to find the data nobody has bothered to capture yet: the workflow exhaust from your own product, the labeled outcomes only your customers can produce, the messy real-world signal your competitors treat as noise.

Two rules follow. First, instrument for data from day one, so every user action becomes a labeled example you own. Second, treat data rights the way you treat security: know what you are allowed to collect, keep it clean, and do not build a business on a corpus you cannot legally use. The founder-as-CISSP version is that your data pipeline is part of your attack surface and your compliance surface, not just your product.

This is the same lesson as the durable-advantage question in what makes a real competitive moat: AI compresses feature and first-mover advantages fast, but the relationship and the proprietary data underneath it are much harder to copy.

Data efficiency changes who gets to play

The optimistic half of the argument is that data efficiency is improving, and that is good news for small teams. Humans learn to code from far fewer examples than a model needs, which suggests today's data appetite is a limitation of current methods, not a law of nature. If models can reach the same capability on less data, the advantage of hoarding a massive corpus shrinks.

The founders make the practical version of the point: a model that is a thousand times more data efficient would be a thousand times easier to deploy, because you would not have to hunt down and license as much data to reach the same result. For a founder that means the winning move is not frontier-scale data or budget. It is to pick a narrow slice where a smaller, well-fed model beats a bigger general one, so the efficient path wins on both cost and speed.

The layer where you win, then, is not the base model. It is the data and the product judgment on top of it, which is the same conclusion as choosing the best LLM for your product: the model is a commodity input, and what you feed it and how you use it is the business.

What to do this week

Classify your problem: write down whether your core use case is data-rich or data-poor, and be honest about how defensible that makes you.
Audit your data: list the proprietary data only you can collect from your own product and customers. If the list is short, that is your priority.
Instrument now: add logging so ordinary user actions become labeled examples you own, before you need them.
Check your rights: confirm what you are legally allowed to collect and use, especially in regulated domains, and treat that as a gate, not an afterthought.
Right-size the model: test whether a smaller, cheaper model fed your specific data beats a bigger general one for your task.

Data, not compute, is the constraint most founders will actually hit. Build your company so the data compounds in your favor.

Want the full operating system for running an AI-first startup, from data strategy to shipping? AI Operating System for Startups

Sources

Why Data Is the Real AI Bottleneck: Flapping Airplanes' Ben and Asher Spector, Sequoia Capital's AI Ascent, the talk this article distills.
Background on the lab Flapping Airplanes, founded by brothers Ben and Asher Spector: TechCrunch and Sequoia Capital.
Building Software for AI Agents Instead of Humans, Greylock, on the incumbents' proprietary-data advantage versus a startup's freedom to move.