Researching a space turns up gaps — things that are missing, unsolved, conspicuously absent. The reflexive reading of a gap is “opportunity”: here is something no one has built, so building it is the opening. This reading is right often enough to be dangerous, because it is also wrong often enough to sink projects. Some gaps are doors you can walk through to a defensible position. Others are problems that everyone entering the space will face, including you, and mistaking the second kind for the first means building toward a wall.

The distinguishing question is who the gap belongs to. A door-gap belongs to the users: there is a job they need done, and no one is doing it for them in the way they’d prefer. Walking through it means serving that unmet need, and the reward is their adoption. A dependency-gap belongs to everyone building in the space: it is a hard, shared, infrastructural problem that every participant must solve to operate, and it is unsolved because it is genuinely hard and not yet standardized. Filling it doesn’t serve a user need so much as it removes a blocker that you and all your competitors share equally.

The trap is that both kinds of gap look identical in a survey. Both show up as “nobody has built X.” The difference only appears when you ask what happens after X exists. If X is a door-gap, building it gives you something users come to you for. If X is a dependency-gap, building it gives you something that becomes table stakes the moment anyone builds it — including the larger players who will build it as infrastructure, fold it into a platform, or wait for a standards body to specify it away. The effort spent solving a dependency-gap is rarely recovered as advantage, because the thing you built was always going to exist; you just paid to be early to a commodity.

A useful tell is to ask who else is working on the gap and why. If the answer is well-funded infrastructure providers, platform teams, and standards committees, the gap is almost certainly a dependency, not a door. Those actors converge on shared problems precisely because the solutions become universal infrastructure that everyone needs and no one can own for long. A small builder who tries to win that race is competing on the dimension where scale, distribution, and incumbency matter most — the worst possible terrain for an entrant. The gap is real, but it is not yours to claim.

The constructive move when you identify a dependency-gap is to reclassify it rather than discard it. A dependency-gap is not noise; it is a constraint you will inherit when you build your actual product. Knowing it exists tells you what your eventual offering will eventually need to handle — the auth, the compliance, the integration, the scale problem that everyone faces. You file it as a future requirement, not a present opportunity, and you let the infrastructure players or the standards process solve it on a timeline that serves the whole space. Then you build the door-gap, the thing users actually come to you for, on top of the infrastructure once it stabilizes.

This reframing changes how a survey concludes. Instead of a list of “gaps to consider building,” you end with two lists: doors to walk through, and dependencies to track. The doors are where the product decisions live. The dependencies are where the roadmap risks live — the things that will be required later and are better watched than built early. The skill is not finding gaps; gaps are easy to find. The skill is sorting them into the two piles correctly, because the cost of putting a dependency in the door pile is months spent building something you were always going to get for free.