We caught up with Luke Ramsden, CPTO at Architect, to hear how his team ended up using Context.dev across a lot more of their product than they originally planned.
What started as a search for a logo lookup tool turned into something that now runs in both their onboarding flow and their sales workflow.
What Architect does
Architect builds personalized landing pages on the fly. Instead of serving the same page to every visitor, it generates a version tailored to who's looking at it, pulling in signals like the visitor's intent, role, and the channel they came through.
The system uses AI agents to assemble the page, so a first-time visitor from a paid ad sees something different from a returning prospect who's been reading the docs. The goal is to cut wasted ad spend and give the team a clearer read on buyer behavior.
What Architect was actually looking for
Luke's team went looking for one specific thing: a way to pull logos from websites. They found Context.dev while searching for that, and then realized it did a lot of other things they needed too.
"We found Context.dev when searching on the internet for services to pull logos from websites, but Context.dev solved many other problems for us too."
So the initial use case widened. They didn't just need logos; they needed reliable brand data they could use across onboarding and sales.
Getting it running
The setup was fast. Self-serve signup, API key on the spot, docs that made it obvious what to call and what to expect back.
"Getting started is very simple. API docs are great and sign-up is self serve, with an API key generated immediately. Took 10 minutes to start integrating."
No sales call, no gated trial, no demo before they could see a response body.
Where they use it
Context.dev now shows up in two places inside Architect:
"Been very handy as part of both our product onboarding + our sales GTM motion."
In onboarding, they use brand data to make the first-run experience feel less generic — the user sees their own company's assets reflected back at them instead of a blank placeholder.
On the sales side, the team uses the same data to put together pitch materials faster. Logos, colors, and basic company info are already there when a rep pulls up an account, so prep time drops.
The takeaway
A 10-minute integration, two use cases, no back-and-forth with a sales team. That's really it. The initial scope (pull a logo) turned into something broader once they had the key and saw what else was in the response.
Once it was in, it stayed out of the way, which is mostly what you want from this kind of dependency.