Alex Bouchard from Hookdeck. Competition is a good sign
When Supabase named Firebase as the competitor to beat, Alex Bouchard thinks that was a deliberate move, not marketing bravado. His rule since repositioning Hookdeck: not having a competitor to point to is probably a bad sign.
Alex Bouchard is the co-founder of Hookdeck, which spent its first three years describing itself as "webhook infrastructure" before repositioning as an event gateway — without changing the underlying product at all.
We get into why he's careful to distinguish that repositioning from a pivot, why deliberately attaching yourself to an established category like the API gateway makes a new category easier to understand than trying to be understood on your own terms, and the very specific SEO strategy of writing better documentation for other companies' webhooks than the companies themselves provide.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What's the actual difference between a pivot and the repositioning Hookdeck went through?
A pivot implies the product changes in some way — you're changing the market and the product together to fit that new market. What we went through last December, I feel uneasy even calling a pivot, because the product genuinely didn't change. We took how people were already using it and relabeled what that value was — the marketing, the documentation — around that existing usage. It's a different way of explaining what you do to the market without changing what you actually do.
You called yourselves 'webhook infrastructure' for three years. Why did that stop working?
At its core, Hookdeck received hundreds of millions of webhooks from platforms like Shopify and GitHub, queued them, and forwarded them to your server reliably. The problem was there wasn't really a category to compare ourselves to — the closest thing was staff engineers' Medium articles about building reliable webhook processing. Over time, users kept using the product in ways that had little to do with webhooks specifically, and it took us longer than I'd like to admit to piece that together. What we realized talking to people is that the webhook part — receiving an HTTP endpoint — is the part good engineers already understand well. What they were actually struggling with was the event-driven nature underneath it, and that's the part our positioning needed to emphasize instead.
How do you actually define what an 'event gateway' is?
It's the IO for all the events entering and leaving your infrastructure — but the important part of 'gateway' is that it lets you interrupt or integrate with the outside world. That could be third parties like Shopify or Twilio, but it could just as easily be your own customers sending you events, IoT devices, scanners, or you publishing events out to third parties or public event streams. We needed terminology broad enough to capture the actual breadth of what people were already building on the platform, rather than narrowing everything down to the webhook-receiving use case we'd been emphasizing.
Did the repositioning land differently depending on who you were talking to?
Very differently. More junior engineers with less exposure to event-driven architectures haven't lived through the pain yet — they haven't had a major event-system outage or mishandled a million webhooks over a weekend, so webhooks-as-a-problem still resonates because it's concrete and solution-oriented: 'I'm trying to receive this webhook from Stripe correctly.' More senior engineers have already lived through an API going down from a bulk retry, or a Black Friday incident, and have real experience with RabbitMQ, SQS, or Kafka — their problems are categorically different. The repositioning was really about aligning ourselves with that second group: positioning Hookdeck as cloud infrastructure for people operating at scale, receiving hundreds of millions of webhooks or events.
Do you have to replace an existing tool or workflow to create a new category, or can you get away with just replacing a habit?
If you're genuinely creating a category, you kind of have to replace a workflow — there's no real way around that. What matters more is how comparable what you're replacing is to something people already have top of mind. For the event gateway, the obvious proxy is the API gateway — it has an established value proposition around security, routing, rate limiting — and our pitch is that the event-driven world needs the same value proposition, just solved differently. Before the repositioning, all we had to point to was individual staff engineers' blog posts, which is about as far as that got us. You want to minimize the mental gymnastics someone has to do to understand your new category, and attaching yourself to something conceptually similar and adding your own twist does that far better than trying to be the whole twist yourself.
You've said having a competitor is actually a good sign. Why?
Supabase is a great example — not only did they attach themselves to an established category, they explicitly named Firebase as the competitor to beat. I think not having a named competitor is probably a bad sign. There's a founder instinct in the first six months to avoid even Googling what you're doing, out of denial that fifty other people might be doing something similar — but eventually something shows up on Hacker News, or a VC sends you a link to a similarly-funded company, and the instinctive reaction is to see that negatively. The truth is, if you're in a genuinely new category, more people operating adjacent to it is more people you can use as a proxy for explaining your own value. We've since published a comparison against AWS EventBridge for the same reason — we're not the only event gateway; Azure Event Grid and Google Cloud Eventarc are too, and pointing that out is useful, not threatening.
What are the specific risks of trying to create a brand-new category, rather than competing inside an existing one?
Two big ones. First, you lose the ability to make simple quantitative comparisons — pricing tables, feature-by-feature comparisons against competitors — because there often isn't a clean established peer group yet, which is part of why we're deliberately forcing comparisons like the EventBridge one. Second, and more dangerous, is product risk: there's no established convention for how a product in your category is supposed to work, so there's a real risk of getting core design decisions wrong from the start. In devtools specifically, that's brutal, because it's very hard to walk back naming and structural decisions later — an API used by thousands of people can't just get a backward-incompatible v2 the way a consumer product might reinvent itself without real consequences.
Can you give a concrete example of getting naming wrong early on?
We borrowed terminology from ETL tools like Fivetran and Segment — sources, connections, destinations — because that's the closest adjacent category we could take inspiration from, even though we're not an ETL tool. That created real confusion; people would say 'this is basically Fivetran,' which it isn't. We've also had to walk back specific endpoint names — we had a `/webhook` API endpoint that, in our own model, was genuinely unclear: is a webhook an event, a message, a connection? We renamed it to `connections`, but for backward compatibility we still have to maintain the old terminology and explicitly document in a little callout that this used to be called something else. You can alias it so it doesn't affect new users, but you're stuck carrying that history.
Without an established category of users to target directly, how did you actually find new users?
You have to attach yourself to the specific problems people are already dealing with in their current workflow rather than the category name itself — literally nobody is searching for 'event gateway.' Our early hypothesis was that people struggle with webhooks, so we built what's become a fairly comprehensive reference of well-researched articles on every webhook problem imaginable. But a senior engineer's actual problem is often something like dead-letter queue management in RabbitMQ, which has nothing to do with webhooks directly — they're further down the problem stack. Most of our real user acquisition and traffic comes from unbranded search around those specific, adjacent problems, not from content about the category we're trying to establish.
You've mentioned writing documentation for other companies' webhooks, like Shopify's. What's the thinking there?
If you're receiving webhooks from Shopify, you're going to search 'Shopify webhooks' regardless of Hookdeck, because you need to know their signature verification, retry policy, and payload format — Shopify is just the event producer in that story, but the search intent is real and high-value. So we invested in strong content about exactly that, and depending on where you are, a table sourced from our own documentation shows up directly in Google above Shopify's own docs, answering retry logic, timeouts, and hashing algorithm right away. The point isn't that Shopify's documentation is bad — it's that surfacing the answer immediately, in a form Google favors, builds a small amount of awareness for us in the process. Sometimes that turns into real collaboration too — GitHub's own docs team started writing content referencing Hookdeck after I opened a PR fixing a dead link to an alternative tool, entirely independent of us afterward; we only found out because of a referral spike on our website.
How do you deal with being dependent on a prospect's timing — waiting for their specific pain point to hit?
It's genuinely dangerous to lean fully on that, because you lose agency the moment you're dependent on someone else having a specific problem at a specific moment. Our approach is to make sure there's a low-friction, zero-consequence way to get value from the product at any time, independent of that inflection point — a CLI someone can download to receive webhooks locally and preview payloads, entirely on their own, with no organizational buy-in required. That builds trust in the brand and keeps you top of mind for whenever the real trigger — an outage, a new VP-sponsored project — actually happens. If you're leaning on product-led growth specifically, that's essential; if you're too dependent on timing, what you actually have is a sales business, not a product-led one.
What's your one takeaway for founders from this whole repositioning journey?
If you're building in a new category, embrace competition rather than avoiding it — actively try to associate yourself with it. And be deliberate about attaching yourself to existing, adjacent categories rather than trying to stand entirely on your own new terminology.