Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Context.dev (YC S26) – API to get structured data from any website

context.dev

Post reply on HN
Print view View original

11–20 of 102 posts

Re: Launch HN: Context.dev (YC S26) – API to get structured data from any website

#11

Post by modo_ »

I was using Context back when it was still Brand.dev. I found it to be a great product- one of those rare APIs that immediately made a problem I had disappear. Had it in production within an hour of signing up

Agents need clean/current context from the web, and this is the best way I’ve found to give it to them. The internet is clearly moving in this direction: companies are starting to realize their sites need to be legible to agents. Some are already adapting but many haven’t yet. Context feels like an important part of that transition

Yahia is a great builder. His pace of expansion has been impressive, excited to see where he takes Context.

Re: Launch HN: Context.dev (YC S26) – API to get structured data from any website

#12

Post by owlninja »

paytonjjones wrote: post #7
pavlov wrote: post #4

Earlier quoted context omitted.

Maybe AI-service-blocklist-as-a-service could be a YC company.

Better business model would be some sort of micropayment setup - allow humans, but make scrapers pay a hundredth of a cent for access.

Is this similar? https://blog.cloudflare.com/monetization-gateway/

Re: Launch HN: Context.dev (YC S26) – API to get structured data from any website

#13

Post by TheYahiaBakour »

modo_ wrote: post #11

I was using Context back when it was still Brand.dev. I found it to be a great product- one of those rare APIs that immediately made a problem I had disappear. Had it in production within an hour of signing up Agents need clean/current context from the web, and this is the best way I’ve found to give it to them. The internet is clearly moving in this direction: companies are starting to realize their sites need to be…

oh wow, happy to see you here, we didn't post this anywhere so its nice to see a customer find us so quickly, thank you for the kind words.

brand data is a shockingly hard problem to get right

Re: Launch HN: Context.dev (YC S26) – API to get structured data from any website

#14

Post by TheYahiaBakour »

m_w_ wrote: post #6

Unclear what difference exists against Firecrawl - their team has been shipping great features extremely quickly lately, and their core offerings have become really good. I am interested in KnifeGeek though - looking for a good OTF (ultratech?)

oh also on knifegeek, it'll be live again this weekend when i find a moment to fix the bug causing it to crash, i collect knives/watches so it was a super fun project to work on

Re: Launch HN: Context.dev (YC S26) – API to get structured data from any website

#17

Post by m_w_ »

TheYahiaBakour wrote: post #8
m_w_ wrote: post #6

Unclear what difference exists against Firecrawl - their team has been shipping great features extremely quickly lately, and their core offerings have become really good. I am interested in KnifeGeek though - looking for a good OTF (ultratech?)

There's alot of overlap at the moment, but we're diverging quite quickly. If you want differences as of right now - 1 credit = 1 scrape, no hidden credit multiplier - we have world class brand data - we're focused primarily on the infra use-case, rather than gtm & everything else - anecdotally, customers have seen their error rates drop quite dramatically In general it's a huge space, firecrawl is a wonderful company…

Interesting - I'll be sure to benchmark it at some point. We've found the best results come from blending providers depending on the task anyways.

Thanks for the quick response - and always happy to see more competition in the space. Best of luck with future features!

Re: Launch HN: Context.dev (YC S26) – API to get structured data from any website

#18

Post by TheYahiaBakour »

sheept wrote: post #15

Does this respect llms.txt and robots.txt, or have you found it more effective if agents see what humans see?

we try to read robots.txt, it's definitely more efficient if agents just see what humans see, we run a custom browser rendering stack

in terms of llms.txt, we're not primarily an AI product (although some features do use LLMs), and speaking to friends who run products it seems to be not very helpful, even though we have one as well, i didn't see it move the needle much

even my own coding agents don't look at llms.txt when looking at our own website, so unsure of whether that standard will survive the test of time

Re: Launch HN: Context.dev (YC S26) – API to get structured data from any website

#19

Post by TheYahiaBakour »

m_w_ wrote: post #17
TheYahiaBakour wrote: post #8

Earlier quoted context omitted.

There's alot of overlap at the moment, but we're diverging quite quickly. If you want differences as of right now - 1 credit = 1 scrape, no hidden credit multiplier - we have world class brand data - we're focused primarily on the infra use-case, rather than gtm & everything else - anecdotally, customers have seen their error rates drop quite dramatically In general it's a huge space, firecrawl is a wonderful company…

Interesting - I'll be sure to benchmark it at some point. We've found the best results come from blending providers depending on the task anyways. Thanks for the quick response - and always happy to see more competition in the space. Best of luck with future features!

please do, and if you see anything off let me know, we've yet to lose a single "bakeoff", i normally ask customers to just have cc/codex run it so its somewhat unbiased

on the 2nd point, most industries are not zero-sum, and many of customers use multiple data providers in any case, so agree with you there

thank you!

Re: Launch HN: Context.dev (YC S26) – API to get structured data from any website

#20

Post by TheYahiaBakour »

zuzululu wrote: post #16

new frontier models do this already

im not sure the models do this, rather the tooling around them, however web search/extraction by the model providers is ridiculously expensive and quite slow, so going into production it makes sense to use a provider (like us)
Post reply on HN