We recently spoke with Samraaj Bath, founder of ION, an AI-powered growth platform that designs, launches, and optimizes on-brand landing pages at scale. ION is a YC Winter 2024 company built for growth teams that need more traffic, better conversion, and faster iteration than a traditional agency workflow can usually support.
ION turns a website into a self-improving growth engine. Its agents analyze a company's existing site, identify gaps across SEO, conversion rate optimization, and performance, then create tailored landing-page variants and keep improving them.
That only works if ION understands a company before it starts generating. It needs logos, colors, typography, screenshots, imagery, company context, and enough visual signal to make generated work feel specific instead of templated.
For a while, ION built that context layer themselves.
The Original Brand-Data Stack
Before Context.dev, ION had already built a lot of the machinery internally.
When a customer onboarded, the system would spin up a sandbox. An agent would visit the site, take screenshots, run JavaScript against the page, and export the pieces ION needed: fonts, images, colors, and frequency data. That output fed another layer that generated brand assets and structured context for the rest of the product.
It worked well enough to prove the concept, but it created a problem ION did not want to keep owning.
"We built out a lot of very similar things, not cached, internally. When customers went onboard, we would spin up a sandbox, which would have an agent that would visit the site, take screenshots, run a JavaScript script to export where all the fonts, images, colors and their frequency were. And it was a pain to manage."
The hard part was not writing the first scraper. It was everything after that: incomplete data, inconsistent websites, rendering differences, edge cases, caching, maintenance, and the constant feeling that a core product team was spending time on infrastructure that was adjacent to the real product.
For a company whose value is in growth agents and page optimization, every week spent maintaining the brand-data layer was a week not spent making ION better at finding, shipping, and testing improvements.
Finding Context.dev in an Unexpected Way
ION did not find Context.dev through an ad or a polished comparison page. They found it backwards.
Someone on X had posted an open-source project that looked similar to what they needed. The project lived on GitHub, and its description called itself an open-source alternative to Context.dev. That line sent ION to Context.dev.
"I clicked it and it went into a GitHub. I was about to start using it, but then in the corner, in the description, it said the open source alternative to Context.dev. So I clicked on Context.dev and I was like, oh, this thing is better."
The open-source route had obvious appeal, but it still left ION with the burden they were trying to escape. They would need to host it, integrate it, maintain it, test it, and deal with the long tail of websites themselves.
The Context.dev approach was different because the infrastructure was already there: browser rendering, caching, social-source enrichment, structured brand outputs, and a real API contract.
"I'd rather pay someone, know they're a real company, and not worry about it."
That was the important part. ION did not need another package to own. They needed a dependable context layer.
Why This Was an Infrastructure Decision
Brand data sounds simple from the outside. Find a logo, pull a few colors, maybe detect a font. But ION did not need a prettier logo lookup. It needed a context layer with structured outputs the rest of the system could trust: visual identity, image context, company data, style-guide signals, and an API contract stable enough to plug into an agent pipeline.
Their agents make decisions from that context. If the brand profile is thin, incomplete, or wrong, the generated landing page feels generic. If it is strong, the page can inherit the company's actual visual language.
The ION team had already learned the same lesson Context.dev was built around: scraping the modern web is full of variance. AI-generated scraping code tends to work on the happy path. Real websites do not stay on the happy path.
"With scraping, agents code for the happy path, and maybe they're a little bit defensive, but there's just so much variance in the web that it's a nightmare."
Context.dev fit because it moved browser rendering, source enrichment, asset extraction, and structured output generation out of ION's application layer. That made the decision less about replacing a utility and more about moving an entire maintenance surface out of ION's product.
The Integration Took an Afternoon
ION's codebase already had a modular context layer, so the replacement was clean.
They passed Context.dev's documentation, npm package, and a few implementation details into their development workflow, then swapped the old internal module for Context.dev. The main work was adapting data structures so the rest of ION's system could keep consuming brand context without caring where it came from.
"In an afternoon. I passed through your documentation, your npm package, and a couple other things. My codebase is very modular. The entire context layer was highly modular and highly documented, so it was very easy for me to say, just rip this entire module out, replace it with Context.dev, and modify the data structures to match."
ION now uses several Context.dev endpoints across the system, including brand data, images, company information, and style-guide data.
For ION, the speed mattered because it changed the evaluation from a long migration project into a practical afternoon swap. The question was not "can we afford to refactor this?" It was "does this API make our context layer better by the end of the day?"
What Context.dev Unlocked
The biggest win was not a new UI feature. It was removing a problem from ION's roadmap.
"Infrastructure not being my problem was huge. It allowed me to move way faster without having to worry about brand stuff and taking care of a new module in my product, which freed me up space to do a lot more with our core offering."
The impact showed up in three places.
First, stronger brand fidelity. Context.dev's output is more comprehensive than the internal approach ION had built with browser scripts and rudimentary AI scraping, so generated pages can start closer to the customer's actual visual language.
Second, less maintenance. Website variance, asset extraction, and source enrichment no longer sit inside ION's core codebase.
Third, faster product iteration. The team can spend more time on the parts of the product that matter most: identifying growth opportunities, improving pages, testing results, and turning those results into a compelling customer experience.
"It was an infrastructure improvement, a cost improvement, and a quality improvement all in one."
The Result
After the swap, ION no longer owned a fragile internal brand-data module. It called Context.dev as infrastructure.
The practical outcome was simple:
- An afternoon integration instead of a drawn-out migration
- Three to four endpoints powering brand, image, company, and style-guide context
- Better brand data than ION's internal scraping layer could produce on its own
- Less infrastructure to maintain inside ION's core product
- More time for the team to focus on website analysis, page generation, and optimization
Context.dev now sits behind the scenes as the context layer ION calls before its agents start improving a website. It is not a flashy integration for its own sake. It is a piece of infrastructure that let a small team stop maintaining a side system and keep building the thing customers actually buy.
P.S. If you want AI agents that find, ship, and test website improvements automatically, check out ION. They help growth teams improve SEO, conversion, and growth pages without waiting on a traditional agency cycle.