The API Was Free. One Clause Killed the Product

I was reading an August trend report looking for something hot I could fast-follow. Three candidates came out of it: a tracker for whether your brand gets cited inside AI answers, a cloud-bill leak audit, and a database permission audit.

I could have built any of them in a day. So instead of building, I looked at numbers first.

• AI citation tracking: over $300M went into this category between mid-2025 and spring 2026. The leader raised $155M at a $1B valuation, and the large SEO suites already bundle the same feature. Meanwhile the entire category gets about 22,000 searches a month.
• Bill auditing: the platform already ships spend limits, alerts and observability. The actual market was agency blog posts.
• Permission auditing: the database product's own linter already flags the same issues, and there are three or more free open-source scanners.

That is where a question was overdue. If the category you want to chase is big enough to appear in a trend report, isn't that itself proof you are late? Appearing in the report means funded competitors already bought the paid channels. Someone without a channel cannot buy the same channel afterwards.

The one candidate left came from my own scar

After dropping those three, what remained was a problem I had actually lived: a checker that finds dead keywords and semantic mismatches in Korean product titles. The filter logic already existed, and I had measured that it strips about 90% of the noise. All that was missing was a wrapper.

The input data comes from a search-ad platform's keyword tool API. It is free. I already had a key. Calls work fine.

So right before building, I read the terms.

The terms were not on the public web

First surprise: search does not surface the full text. Not in the official repository, not on the policy pages. curl against the terms URL returns a 2.5KB empty shell — the page renders through JavaScript.

I rendered it with browser automation and pulled the body. 17,576 characters. And the first signal showed up right there:

search body for "API" → 0 hits

No API-specific carve-out. Which means anything obtained through the API is governed by the general member obligations. So I read Article 14:

• Clause 5: the member account may only be used for the purpose of using the service.
• Clause 6: do not provide "any information acquired" while using the service "to third parties".
• Clause 8: for the log-analysis service, commercial use and third-party provision are prohibited explicitly.

What I was about to build was exactly what clause 6 forbids: taking search volumes pulled with my key, processing them, and selling the result to someone else. The shape — SaaS, marketplace tool, or a human-delivered report — makes no difference.

This is where the fork is

Do you make each customer issue their own key, or do you run it on your key and look away from the clause?

Customer keys are legal: the party providing data to a third party becomes the customer themselves. The cost is that "sign up, create an ad account, issue a key, paste it here" becomes your first screen. In a self-serve tool, that means conversion dies.

My key has zero friction. And then the arithmetic looks like this:

The expected value is negative. It is a trade that risks an operating asset for a few tens of dollars a month. The calculation took under a minute.

It has the same shape as the time three payment processors rejected the whole category and I shelved monetization. The code worked then too. What stopped it was someone else's terms.

I did not drop the product. I swapped the source

What died was not "Korean data tooling" — it was that one source. So I went looking for a source whose contract is clean.

Real estate transaction prices from the government open data portal. Free, and the license is explicitly unrestricted in scope of use: commercial use and redistribution are allowed. Which means processing and selling it is fine.

I built it the same day. Original XML into English field names; the string " 82,500" (in units of 10,000 KRW) into the integer 825,000,000; area in both square meters and pyeong; three separate year/month/day fields into one ISO date; canceled deals behind their own flag. Then I published it to a marketplace (the real thing is here). Only the judgment date is pending.

If the lesson were "read the terms" it would be too thin. Precisely stated: the source contract eliminates product candidates before the market does. License checking comes before market research. Reverse the order and you end up like me — holding finished logic in front of a source you are not allowed to use.

Three self-checks

Point these at whatever you are building.

1. Have you checked the terms of the data you redistribute, down to the clause number? "Free API" is not a license.
2. Do those terms contain a provision specific to your access method (API, scraping, manual lookup)? If not, the general member obligations apply as written.
3. Have you written what you lose on violation and what you gain on success in the same unit? Monthly revenue versus account termination is a comparable pair of numbers.

The honest part

Swapping the source is not evidence the product sells. All I verified is that equivalent real-estate tools for other countries have roughly 30–55 monthly users, and that the Korean slot is empty. The scale is small too: a good outcome is tens to a few hundred dollars a month.

The reason the day was not wasted is that I did not stack two weeks on top of an unusable source. Reading the terms — including the rendering workaround — took twenty minutes.

The data you are about to redistribute: do you know where its terms live? If search does not find them, that is your first signal.