Building the internet's brand API with Yahia Bakour (Founder @ Brand.dev)

If you go through Yahia’s resume and body of work, one thing is clear: he’s a builder.

He has built multiple products, he scaled one of them to 250k users before selling it, and he is now building his next act: Brand.dev.

Here’s a masterclass from him on what he’s building, what he’s learned along the way, and how he is applying lessons from previous companies to execute …

At my last startup, Essense, we built an AI-powered customer research platform. One of our biggest challenges was onboarding, customers often dropped off because we needed a lot of information upfront to properly configure their accounts. Our product-led growth motion depended on getting SMBs signed up and seeing value quickly. Ideally, within a minute they could analyze their reviews. But that required them to at least point us toward their iOS, Android, or Steam apps.

To solve this, I hacked together a simple internal tool that could automatically scrape app information. This small change dramatically reduced onboarding drop-off, although it was extremely brittle and latency was a huge issue. Especially since the variance in websites is insane, some are client side rendered, some server side rendered, some have crazy scraping protection, others not so much.

Much later, when I spoke with other founders, I realized this wasn’t just a niche problem. Across industries, teams struggled with onboarding friction, and many wished they could instantly preload a new customer’s name, logo, description, and other context. The problem was that building and maintaining the infrastructure to do this reliably at scale was both complex and time-consuming.

That insight was the foundation for Brand.dev.

My vision for Brand.dev is to make brand and company data instantly accessible so that products can deliver personalization from the very first touchpoint. Right now, we’re focused on a specific wedge, branding data, onboarding, and transaction enrichment, but the opportunity is much bigger.

In a few years, I see Brand.dev becoming the default layer of context for SaaS: when a new user signs up with their corporate email, the product should already know who they are, what their company does, and how best to tailor the experience. Instead of lengthy setup flows, users would just confirm details and immediately see value.

That’s the future Brand.dev is building towards, frictionless onboarding and personalization.

With Stock Alarm, our B2C app, churn was always a battle, consumer apps tend to have high turnover, customers are very price sensitive, and most conversions happened within the first day. Growth was more of a volume game and customers want to hear about updates and improvements often.

Brand.dev, on the other hand, is the opposite in many ways. Churn is extremely low, customers aren’t nearly as price sensitive, and conversions usually happen after weeks of free-tier usage.

What’s similar is that both have grown heavily through word-of-mouth, with steady, compounding adoption over time. The big difference is I see a much higher ceiling with Brand.dev, the long-term potential feels significantly greater because the pain point is deeper and the solution integrates more directly into customer workflows.

One of the hardest challenges has been balancing scraping and image processing with strict latency constraints. Within about 10 seconds of an API call, our system has to:

And that’s just for logos.

In parallel, we also retrieve names, addresses, industries, descriptions, style guides, and other brand signals, all while keeping the experience fast and reliable.

The majority of paying customers today are software companies that integrate our API directly into their products. Roughly half are startups who need lightweight, plug-and-play personalization; about a quarter are mid-size SaaS businesses that want to enrich their onboarding or transaction flows; and another quarter are large, often public companies that need brand enrichment at scale.

Right now, the primary users are developers, people embedding Brand.dev into sign-up flows, CRMs, analytics dashboards, and automation pipelines. The engineering audience is still our core focus because they’re the ones building the infrastructure where brand data really makes a difference.

That said, we’re starting to see the edges expand. With the Zapier integration, a handful of product managers and marketers have begun setting up their own no-code workflows. For example, I’ve seen teams use it to auto-enrich leads in their CRM, preload brand assets into outbound campaigns, or instantly customize proposal docs with client logos and colors. It’s still a small percentage compared to developers, but it’s an encouraging signal of how broad the use cases can get once the barrier to entry is low.

Long term, I expect non-technical roles to lean on Brand.dev more and more, especially as we add integrations with the tools they live in every day (like HubSpot, Salesforce, or Notion). For now, though, we’re doubling down on the developer-first motion, because once developers bring Brand.dev into the core workflow, it naturally unlocks value for the PMs, marketers, and sales teams downstream.

To be honest, about half of our first 100 customers came directly from referrals—either existing customers recommending us to others in their network, or people discovering Brand.dev through my posts on Twitter/X.

Here’s what I’ve found works especially well for this audience:

On the flip side, there are a couple of things that haven’t worked well:

The affiliate program hasn’t really moved the needle yet.

What has worked recently are the interactive experiences we launched on the site: a “see something cool” widget that live-transforms a site’s styleguide, and a free UI demo to explore the data. Within a day of launch, those landed us in Product Hunt’s top 10 and brought in 5 new customers, early, but promising.

On the SEO side, I invested heavily from day one: every piece of data we offer has its own page, we rank well for key terms, and competitor comparison pages (“X Alternative”) consistently drive strong traffic.

I spoke to the founder of screenshotone.com recently (extensive website screenshot api with 20K MRR) and we agreed that there's some peculiarities about building an API business, specifically how slow the growth is and how low the churn is, i think it's impossible to build this type of product without being a developer yourself who has deep understanding of the market and use-cases for the data.

I think it's important to give back to the community in terms of learnings, specifically any technical challenges you solve as part of building your data pipeline, sharing nuggets of wisdom around scraping for example has gotten me some of my most important customers.