Embedly, YC Founder Story

Company: Embedly Founders: Sean Creeley (CEO) & Arthur "Art" Gibson (Co-founder) YC Batch: Winter 2010 Industry: Developer Infrastructure / Media Embedding Location: Boston, MA Status: Acquired by Medium (2016) Customers at peak: LinkedIn, Salesforce, Reddit, The New York Times, Microsoft Scale at peak: Close to 1 billion monthly impressions

---

---

The One-Line Summary

Two founders in Boston, far from the Silicon Valley spotlight, noticed that "embedding a link" on the web was a fragmented mess, built a meta-layer on an obscure protocol nobody had taken seriously, and quietly became the embedding engine running underneath LinkedIn, Reddit, and The New York Times for six years.

---

Lens 1, The Before State

Who Was Sean Creeley Before YC?

Unlike many YC founding stories built on dramatic pre-startup struggle, Sean Creeley's path into Embedly was the result of paying close attention to a small, unglamorous technical annoyance that almost nobody outside developer circles even knew existed.

Sean was a working technologist before Embedly, comfortable with Python, embedded in developer communities, and aware of a quietly growing standard called oEmbed, a protocol that let one website request embeddable representations of content (like a YouTube video or a Flickr photo) from another. The problem: oEmbed existed, but barely anyone implemented it well, and the libraries built around it only supported a tiny handful of providers.

His co-founder, Arthur "Art" Gibson, brought the steadiness that Sean would later describe, after their acquisition, as making him "the best co-founder and company man I know." That detail matters, Embedly wasn't built by two people chasing hype. It was built by two people who trusted each other enough to spend six years on infrastructure plumbing most users would never see.

The Personal Pain They Were Living

The frustration was structural, not personal trauma: embedding content on the web was a mess. If you wanted your website to show a rich preview of a YouTube link, a Tweet, or a SoundCloud track, you had to write custom integration code for every single provider. There was no single layer that handled it all. Developers were "reinventing the wheel with every new embed," as Sean put it years later when reflecting on why Embedly existed at all.

This is a different, and important, origin pattern for aspiring founders to study: not every great YC company comes from a founder's personal crisis. Some come from a founder noticing friction that an entire industry has simply normalized and stopped questioning.

Why They Weren't the "Obvious" YC Profile

Boston-based, non-flashy, building on top of an existing technical standard rather than inventing something from scratch, with a team size of exactly 2, Embedly didn't look like a unicorn-in-waiting. There was no previous exit, no Ivy League pedigree being waved around, no viral pre-launch buzz. It was two engineers who saw a gap in plumbing that the rest of the internet quietly tolerated.

Key Insight for Aspiring Founders

You don't need a dramatic origin story. You need a precise diagnosis. Embedly's founders didn't suffer from a broken industry, they simply refused to accept "that's just how embedding works" as an answer. Sometimes the founder advantage isn't pain, it's intolerance for unnecessary friction that everyone else has stopped noticing.

---

Lens 2, The Idea Origin

How the Idea Actually Emerged

Embedly's idea origin is one of the cleanest examples of a "standard-on-top-of-a-standard" strategy. The oEmbed protocol already existed, an open specification that let sites declare how their content should be embedded elsewhere. But individual implementations (like early Ruby and Python oEmbed libraries) only supported a handful of providers each, and most webmasters had to maintain their own patchwork list of regex-matched URLs for each new service they wanted to support.

Embedly's insight was simple but valuable: build the meta-layer. Instead of asking developers to maintain their own provider lists, Embedly maintained one comprehensive, constantly-updated catalogue covering more than 100 services, YouTube, Flickr, Hulu, Picasa, Ustream, Twitpic, Quantcast, CrunchBase, and dozens more, and exposed it through a single clean API.

The First Version Nobody Initially Noticed

In Embedly's earliest days, the product was narrow by design: take any URL, detect what kind of content it pointed to, and return a ready-to-embed representation automatically. No manual mapping. No per-provider integration work. Just a URL in, rich media out.

It wasn't a flashy consumer product. It wasn't going to trend on the front page of a news site. It was the kind of tool that, when it worked, was invisible, and when it was missing, was an annoying afternoon of someone's engineering time.

The Signal That Validated It

The validation came from developer communities adopting Embedly's data even when they weren't using Embedly's core product. As one independent developer documented in 2010 while building a Ruby oEmbed library: when his own implementation couldn't keep up with new provider URLs, he turned directly to Embedly's JSON catalogue of supported services and forked it into his own library, because Embedly's coverage was simply more complete than anything else available, including the standard's own reference implementations.

That's a powerful, under-the-radar form of product-market fit: other developers were building on top of your data even when they weren't your direct customer.

The Pattern This Follows

Embedly is a textbook example of the "unsexy infrastructure layer" archetype that recurs throughout YC's portfolio, similar in spirit to Stripe's approach to payments. The market doesn't reward the most visible problem; it rewards founders who correctly identify the boring, repeated task that thousands of other companies are quietly re-solving from scratch.

---

Lens 3, The Application Anatomy

What Made Embedly's Pitch Work

Embedly's application strength wasn't a dramatic market size claim, it was specificity and breadth of coverage, stated plainly: "Embedly provides a platform and suite of tools to make embedding and previewing links simple," supporting over 100 different websites and APIs, automatically converting links into embedded media on the fly.

That phrase, "more than 100 websites and APIs", is a number, not an adjective. It's verifiable, testable, and instantly understandable to a technical reviewer. Compare that to vaguer pitches like "we make content richer", Embedly's framing left no ambiguity about what the product did or how broad its coverage already was.

What They Had (And Didn't Have)

Why a Small, Unglamorous B2B Tool Got In

YC's selection process has never required a company to be consumer-facing or viral to get accepted. Embedly's application worked because it answered the only question that matters in a technical infrastructure pitch: does this solve a real, recurring, verifiable problem for a definable group of users (in this case, developers and publishers)? The answer was unambiguously yes, and the breadth metric (100+ providers) proved it wasn't a toy.

Application Scorecard

---

Lens 4, The Interview Moment

The Quiet Confidence of a Narrow, Correct Answer

Unlike founders pitching a sweeping vision, Embedly's strength in any partner conversation would have come from precision under pressure. When the inevitable question arrives, "Why won't a bigger company just build this themselves?", the honest, defensible answer is structural: large platforms didn't want to maintain 100+ shifting integrations as their core business. Embedly's bet was that maintenance of fragmented standards is a business in itself, even if it never becomes a billion-dollar narrative.

This is an important interview archetype for technical, infrastructure-style founders to understand. It's not the "this will be a generational company" interview. It's the "this is real, recurring, and someone has to own it" interview, where the partners are testing whether you understand the durability of the problem more than the size of the dream.

What This Type of Founder Needs to Prove

For infrastructure plays like Embedly, the implicit test in any YC interview is: will customers trust you to keep this working indefinitely? Reliability, not charisma, is the deciding factor. The proof isn't a slide, it's the existing breadth of providers already supported, which Embedly could simply demonstrate live.

The Interview Archetype

Embedly's path fits the "plumbing, not theater" interview type, a category that rewards founders who can show, rather than narrate, that the unglamorous problem is already meaningfully solved. If you're building infrastructure rather than a flashy consumer product, your best interview asset is a live demo that simply works across many edge cases, not a story about disruption.

---

Lens 5, The Batch Experience

Building Outside the Bay Area Bubble

Embedly is also a useful case study for founders who don't live in or relocate permanently to Silicon Valley. Based in Boston, the team built a company that landed Y Combinator backing, SV Angel, Betaworks, Lowercase Capital, and Venture 51 as investors, all while keeping their operational home base on the East Coast. The company's Boston office stayed open even after acquisition.

This matters because aspiring applicants sometimes assume YC requires a Bay Area relocation to be a "real" YC company forever. Embedly's six-year run shows that the YC stamp and network can travel with the founders, rather than requiring them to permanently uproot.

From Two-Person Team to Powering the Web's Biggest Platforms

What's striking about Embedly's batch-to-scale trajectory is how far a two-person team's infrastructure reached. By the time of acquisition, Embedly's embedding technology was running underneath LinkedIn, Salesforce, Reddit, and The New York Times, sites with audiences in the hundreds of millions, and the company was processing close to a billion monthly impressions at its peak.

That scale was achieved without a large team. It's a strong data point for the idea that infrastructure businesses can achieve enormous reach without proportionally enormous headcount, the leverage comes from being the layer that many other products depend on, not from headcount growth.

The Growth Number

Billion monthly impressions, a customer roster that includes some of the most recognizable names on the internet, and a six-year run from YC-backed startup to acquisition, all built by a founding team that started at two people in Boston.

---

Lens 6, The Mindset Shift

The Limiting Belief They Had to Kill

The tempting (and common) founder belief is: "If it's not consumer-facing and viral, investors and customers won't care." Embedly's team had to reject that belief entirely. Their product was, by design, meant to be invisible to end users, the whole point was that readers browsing LinkedIn or Reddit would never notice the rich media embed was powered by a third party. Embedly succeeded precisely because it disappeared into the products it powered.

The Uncomfortable Action: Building for Other Developers, Not End Users

Most early-stage founders are told to obsess over the end user. Embedly's founders had to develop comfort with a less glamorous truth: their actual customer was a developer or product team at another company, and their actual end user would often never know Embedly existed at all. That requires a different kind of patience, pride has to come from the elegance of the API, not public recognition.

The Identity Shift, From Founder to Standards Steward

In Sean Creeley's own words upon the Medium acquisition: "Embedding on the web is a mess. Developers lack strong standards and end up reinventing the wheel with every new embed. At Embedly, we started off trying to standardize embedding across providers."

Notice the shift in language: not "we built a product" but "we started off trying to standardize." Over six years, Embedly's founders moved from thinking of themselves as a startup selling an API to thinking of themselves as stewards of a missing internet standard. That reframing, from product builder to standards builder, is what allowed the company to be valuable enough that Medium wanted not just the product, but the team's continued leadership on embedding as a discipline.

The Identity After Embedly, Honesty About Rejection

Perhaps the most valuable mindset lesson from this story comes after Embedly. Sean Creeley later co-founded Podsights, and publicly wrote about applying to YC again with his new venture and getting rejected. He didn't hide this. He wrote about it candidly as just one part of a messy post-acquisition period that included a paper company, consulting work, and a political campaign tool before Podsights found its footing.

This is a crucial corrective for aspiring founders building a mental model of YC acceptance: getting into YC once does not guarantee getting in again. Even founders with a successful acquisition behind them face rejection on subsequent ventures. The cycle of building, applying, sometimes failing, and continuing anyway doesn't end after one success.

The Transferable Principle

Aim to disappear into the products you power. The biggest compliment an infrastructure company can receive is that its users never think about it. If your product works so well that nobody notices it, you may be building something far more durable than a feature people talk about.

---

Lens 7, The Replicable Playbook

Action 1, This Week: Find the Protocol Nobody Implemented Well

Look for an existing open standard, spec, or protocol in your field that technically "exists" but is poorly or inconsistently implemented across the ecosystem. Embedly didn't invent oEmbed, they built the best, most complete layer on top of it. This week, identify one standard in your space where coverage is currently fragmented across five mediocre implementations rather than one excellent one.

Action 2, This Month: Get Other Developers Building on Your Data, Not Just Your Product

Embedly's most powerful validation signal wasn't paying customers, it was independent developers forking their open data and building their own tools on top of it. This month, find a way to make some piece of what you've built (a dataset, a schema, a public API endpoint) usable by developers who aren't your direct customers yet. If they start relying on it anyway, you've found early signal that's hard to fake.

Action 3, Before Applying to YC: Make Your Coverage Number Concrete

Embedly's pitch worked because "100+ websites and APIs" is a real, checkable number, not a vague claim of completeness. Before you apply, find the equivalent metric for your own product: number of integrations, number of edge cases handled, number of formats supported, latency improvement, anything specific and verifiable. Precision beats ambition in an infrastructure pitch.

Story Relevance Tags

---

3 Things You Can Screenshot Right Now

"Embedding on the web is a mess. Developers lack strong standards and end up reinventing the wheel with every new embed.", the entire company existed to fix one sentence's worth of friction.

"Aim to disappear into the products you power. The best infrastructure company is the one nobody notices is there."

"Getting into YC once doesn't mean getting in again. Even a founder with a successful acquisition behind him got rejected on his next application, and kept building anyway."

---