Prove You Can Get the Data Before You Build the Thing That Needs It

Mostafa Dhouib·7 min read

Prove You Can Get the Data Before You Build the Thing That Needs It

The short answer. Some products are engineering products and some are access products wearing engineering clothes. If the thing that makes your product possible is data somebody else controls, then the question that decides whether it exists is not whether you can build it. It is whether you can get the data, under terms that permit what you intend to do with it, at a cost the unit economics survive, with reliability the product can depend on. That question costs days and a small fixed fee to answer. It is routinely answered last, after an architecture has been built on the assumption, and the answer arrives as the end of the project rather than as a finding.

A founder describes a product. It compares something, aggregates something, verifies something. The conversation goes immediately to the application: the interface, the matching logic, the ranking.

None of that is the risk. The risk is a clause in somebody's terms of service, or a tier that is not available to a company of your size, or a price per call that exceeds what the transaction earns.

Four questions, in order

Can you get it at all? Many providers in valuable data categories gate access. A small operator may simply not be eligible, and no amount of integration work changes that. This is binary and it is answerable by asking.

Are you allowed to use it that way? This one ends more projects than the first, because access is granted and the terms restrict the use. Comparison across providers, display alongside competitors, caching, redistribution and automated querying are all commonly restricted. A product built on an interface whose terms forbid its core behaviour is not a technical problem with a technical fix.

Does the cost work? Per-call pricing against your expected call volume and your revenue per transaction. If one user action requires many calls, the arithmetic can fail by a wide margin, and the failure is proportional to how useful the product is.

Is it reliable enough? Rate limits, availability, and how the provider behaves under load. A source that is unavailable during your peak is a source you have to design around rather than depend on.

Answer them in that order, because each one can make the rest irrelevant.

Why it gets answered last

Not negligence. Several ordinary forces push it there.

It is not fun. Reading terms and emailing a partnerships address is less engaging than designing the thing, and early-stage work follows energy.

It feels like a formality. Interfaces are public, documentation exists, a test key works. All of that is true and none of it answers the four questions, because a test key on a free tier tells you nothing about production terms.

It is somebody else's job. Technical people treat it as commercial, commercial people treat it as technical, and it sits in the gap.

The answer might be no. Not usually conscious, and present. A question whose answer could end the project is a question people are slow to ask, especially once there is a deck and a plan.

What the first milestone should be

On this kind of product, milestone one produces no features. It answers the four questions and it costs a few hundred to a couple of thousand, which is the cheapest money in the whole project.

Concretely it produces: a written statement of what access is available at what tier, the specific clauses that permit or restrict the intended use, a cost model at expected volume against expected revenue, and a measured reliability sample against the real interface rather than the sandbox.

Where the answer is no, the milestone is not a failure. It is the most valuable output the project will ever produce, because it arrived before the money.

And where access is unavailable on one path, the useful second half of that milestone is whether a different path exists. A partnership rather than self-serve access. A different provider. Reconstructing the signal from something adjacent rather than reading it directly. Structuring the product so a user supplies their own credentials. Those are architecture-shaping answers and they are cheap to explore before anything is built.

Design for either answer

The stronger version of this, when the answer genuinely is not knowable up front, is to shape the engagement so both outcomes lead somewhere.

A monitoring product once faced exactly this: nobody knew whether a controller could be read at all. The engagement was structured so that if it could, the system decodes it directly, and if it could not, the surrounding physical signals get instrumented instead. Two paths through the first gate, both shipping a working product, neither stranding the capital.

That is a different posture from assuming the favourable answer and hoping. It costs a little more design up front and it removes the single point of failure from the plan.

The same shape beyond data

The pattern is: a dependency outside your control that determines whether the product can exist, which is cheap to test and expensive to assume.

Platform policy, where an app category may not be permitted at all. Regulatory permission, where an activity requires a licence that takes months. Hardware availability, where a part has a lead time longer than the runway. Device capability, where a required interface is simply absent on a major platform and the product's form factor is decided by that rather than by preference.

In each case the same question applies. What is the one external fact that makes this impossible, and what would it cost to find out now rather than later?

The honest limit

Answering the four questions establishes the position today. Terms change, tiers are withdrawn, pricing moves, and a provider that is happy to serve you at low volume can take a different view at high volume, which is precisely when you most depend on it.

So this is a gate rather than a guarantee. The durable protection is architectural: an adapter per source so a provider can be replaced, a cost model you keep watching rather than one computed once, and knowing in advance which alternative you would move to. A product whose viability rests on one external relationship it does not control has concentration risk regardless of how good today's answer is.

FAQ

What is the first thing to validate in a product built on third-party data? Whether you can obtain the data at all, then whether the terms permit your specific use, then whether the cost works at your volume, then whether reliability is sufficient. In that order, because each answer can make the others irrelevant, and all four are answerable in days.

Why do terms-of-service restrictions end more projects than access limits? Because access is often granted while the terms restrict exactly what the product does. Comparison across providers, display alongside competitors, caching, redistribution and automated querying are commonly limited, and a product whose core behaviour is prohibited has no technical fix available.

Does a working test key mean I have access? No. A sandbox or free tier tells you nothing about production terms, production pricing or production rate limits. The questions have to be answered against the tier you would actually operate on, which usually means talking to the provider rather than reading documentation.

What should the first milestone of an access-dependent product deliver? No features. A written statement of available access at each tier, the specific clauses permitting or restricting the intended use, a cost model at expected volume against expected revenue, and a reliability sample measured against the real interface rather than the sandbox.

What if the answer genuinely is not knowable up front? Shape the engagement so both answers lead somewhere. One monitoring project did not know whether a controller could be read, so it was structured to decode it directly if yes and instrument the surrounding signals if no. Two paths through the first gate, both shipping, neither stranding the capital.

Does proving access once make the product safe? No, it establishes today's position. Terms change, tiers are withdrawn, and a provider comfortable at low volume may take a different view at high volume. The durable protection is an adapter per source, a cost model you keep watching, and knowing which alternative you would move to.