Every AI product ends up building the same web-data stack
Somewhere in the codebase of almost every serious AI product, there is a directory nobody is proud of. It holds the headless browser config, the proxy rotation logic, the HTML-to-text cleanup functions, the retry queues, and the cache that papers over all of it. None of this is the product. All of it exists because the product needs to know what is on the web right now, and the web does not make that easy.
The web was designed for people looking at screens. An agent that needs the same information has to fight through cookie banners, JavaScript rendering, bot detection, and markup that changes without warning. Teams that start with "we'll just scrape it" discover they have hired themselves into a second job: running browser fleets and babysitting parsers for sites they don't control. The usual escape is to stitch together vendors, one for scraping, one for screenshots, one for company data, each with its own contract and failure modes.
Context.dev collapses that whole layer into a single API. You send it a URL, a domain, a company name, a sitemap, or a file, and you get back what your application actually wants: clean markdown, raw HTML, a screenshot, brand assets, or structured JSON that matches a schema you define. The browsers, proxies, rendering, extraction, caching, retries, and queues are Context.dev's problem. The company's one-line pitch is that it gives AI agents realtime web context, and it went through Y Combinator's Summer 2026 batch on the strength of that idea.
Pick an output, not a pipeline
The core design decision in Context.dev is that you specify the result, not the process.
A traditional scraping setup makes you think procedurally. Launch a browser, wait for the page, strip the navigation, find the selectors, handle the timeout. Context.dev's API inverts that. The request says what you want to end up with, and the format options map to what AI applications actually consume:
Markdown is the default currency of LLM pipelines, and a one-credit scrape returns a page as clean markdown with the chrome stripped out. This is the format for RAG systems, agents doing research, and anything that feeds pages into a model's context window.
Structured JSON is where it gets more interesting. You hand the API a JSON Schema and extraction instructions, and it crawls the relevant pages of a site and returns data shaped exactly the way your application expects. That turns "parse this pricing page" from a scraper-maintenance chore into a declarative call.
Screenshots come as full-page or viewport captures, useful for agents that reason over visual layout or products that need to show a site rather than describe it.
Brand data is the odd one out, and it explains the company's history. Ask about a domain and you get back logos, dominant colors, font families, and company metadata. You can look a company up by domain, email address, name, or stock ticker.
On top of the single-request calls sit two primitives for production use: Batches, for pushing large workloads through without managing your own queue, and Monitors, which re-check sources on a schedule so the data your product relies on stays current instead of quietly going stale.
It started as a logo API
Context.dev did not begin life as a web-data platform. It began as Brand.dev, an API that returned logos, colors, fonts, and company info for any domain, built for product teams that wanted to personalize onboarding screens and dashboards without manually hunting down assets.
That sounds like a small product, and deliberately so. But a brand API turns out to be a gateway drug to a much bigger one. To reliably pull a logo and a color palette from any domain on the internet, you have to solve rendering, crawling, extraction, and freshness for the whole messy web. Once that machinery worked, founder Yahia Bakour expanded the product into general scraping, AI-powered extraction, and product intelligence, and in March 2026 rebranded the company from Brand.dev to Context.dev to match what it had become. The YC batch came after the pivot, not before it.
The origin still shows in the product's surface area: the brand endpoints are still there, and the ability to look a company up by email or stock ticker is the kind of feature you build for fintechs and sales tools, not for crawler enthusiasts. Context.dev is not a research prototype that grew an API. It is an API business that grew a bigger job description.
The plumbing is the product
It is worth being concrete about what Context.dev absorbs, because "we handle scraping" undersells it.
Modern websites are hostile to automation in layered ways. Much of the content only exists after JavaScript executes, so you need real browser rendering at scale. Sites rate-limit and fingerprint datacenter traffic, so you need proxy management. Pages fail intermittently, so you need retries with backoff and queues that don't lose work. The same page gets requested by many customers, so caching matters for both speed and cost. And after all that, raw HTML is still not an answer; something has to extract the meaning.
Each of these is a solved problem individually. The grind is operating all of them together, forever, against an internet that keeps changing. That is exactly the kind of undifferentiated heavy lifting that makes sense to buy rather than build, the way teams stopped running their own email servers and payment rails. Context.dev's bet is that web context is next in that lineage: every AI product needs it, almost none of them are differentiated by how they get it.
One operational detail says a lot about the mindset: failed requests are never billed. In a category where flaky targets are the norm, that puts the cost of unreliability on the vendor, which is where the incentive to fix it belongs.
Pricing a developer can read from the docs
Context.dev prices the way developer infrastructure should: published numbers, a real free tier, and costs that map to work performed.
Everything runs on credits. A standard markdown or HTML scrape costs one credit, a screenshot costs five, and brand retrieval or structured extraction costs ten. Signing up with a work email gets you 500 credits with no credit card, plus 10,000 logo requests, two concurrent monitors, one concurrent batch, and a 30-request-per-minute limit. Paid plans go from a $25 Developer tier through a $149 Pro tier to a $499 Scale tier.
The free tier is generous enough to build a real integration, not just run a demo, and the credit costs tell you honestly which operations are expensive to serve. A developer can price out a production workload from the pricing page alone, without a sales call. For a product whose buyers are engineers deciding between "use this API" and "keep maintaining our scraper," removing that friction is not a detail. It is most of the go-to-market.
Who is already relying on it
For a company this young, the customer list is unusually load-bearing.
Context.dev reports more than 400 customers, with over 5,000 businesses having used the API, and the named users cluster in exactly the segments you would predict. Mintlify, which hosts documentation for thousands of software companies, uses it. So do Daily.dev, Similarweb, Chatwoot, Passionfroot, and Rho. One published case study describes Slashy running its inbox-enrichment feature on Context.dev to enrich 5,000 companies a day.
Similarweb is the name worth pausing on. When a web-intelligence company shows up on a startup's web-data API, it carries the same signal as AI lab engineers adopting someone else's agent tooling: the people best positioned to build it themselves found it worth using anyway. That is what the commoditization of a layer looks like from the inside.
The company has also leaned into being callable by machines, not just integrated by humans. Context.dev is available to agents through MCP integrations, so coding agents and agent frameworks can wire it up directly rather than waiting for a human to write the glue. When your stated customer is "every agent that needs to understand the web," being reachable from inside agent toolchains is table stakes.
A founder on his third swing
Context.dev is run by a small team in San Francisco, and its shape reflects the founder's background. Yahia Bakour led engineering at Sunrun, worked at Amazon before that, and built and sold two startups along the way. This is someone who has operated production systems at scale and has already been through the full arc of a company, twice.
That resume matches the product's temperament. Nothing about Context.dev is flashy. It is priced plainly and pointed at operational pain its customers can name precisely because they have felt it. Products like that tend to come from founders who have personally maintained the bad version of the thing they are replacing.
The context layer
The framing Bakour uses for the company is that it is building the context layer between the internet and every agent or application that needs to understand it. Strip away the branding and there is a real structural claim underneath.
Models are becoming interchangeable faster than the systems around them. What an AI product knows at inference time increasingly depends on retrieval, and for anything touching companies, prices, products, news, or people, the freshest source of truth is the live web. A model with stale context loses to a worse model with current context. That makes the pipe between the web and the model a permanent piece of the stack, not a temporary workaround, and it is indifferent to which model wins.
Every platform shift has a moment when some grubby, necessary capability stops being something every team builds and starts being something everyone calls. Web context for AI applications is having that moment now. Context.dev's wager is that when teams stop building it, the API they call instead will be the one that already handles the browsers, the proxies, the retries, and the queue, and just hands back the answer.
