Building the Recruiting API from Zero

The context

Respondent is a research recruiting marketplace. Researchers pay to recruit qualified participants for interviews, unmoderated studies, and surveys, and participants earn by completing them. The business model is high-bar by design: researchers pay per completed research event, not just per recruit, and participants only get paid when they finish a study in full. That rigor is what makes the panel valuable. It's also what makes the platform demanding to operate.

When I joined in December 2022, Respondent was about 15 to 20 people. The company had recently closed its first round of funding and had just reduced headcount by roughly 20% after a period of flat growth. The sales team had largely tapped out on growing the business through direct enterprise relationships. Enterprise customers liked the product, the quality of participants was genuinely strong, but they were only putting a small slice of their total research budgets into Respondent. The pricing model had recently shifted to flat-rate per event, which created friction for teams that needed flexibility across different types of research. Growth had stalled.

The only way in was through the web app. It was functional but dated, the kind of UI that hadn't been meaningfully updated since the company started. Researchers, and in some cases agencies acting on their behalf, were navigating it to set up every campaign. They were putting up with it because the results were good enough to justify the friction. But there was a ceiling on how much of their research workflow Respondent could ever own if the only way to use it was through a single, slow, clunky interface.

The question

The CEO, Jack Pratten, had a clear vision: Respondent should be the backbone of research recruiting. The gold standard. The platform that every researcher reaches for when they need to find the right participant.

That framing clicked for me immediately, because I'd just spent time at Twitter working closely with measurement partners like Nielsen and Moat, whose value came precisely from being embedded everywhere. Nielsen didn't win by having the best interface. They won by being the infrastructure. Every broadcaster, every media buyer, every ad platform eventually needed to plug into them. Their ubiquity was the product.

If Respondent had a real shot at becoming the gold standard of research recruiting, it couldn't only be accessible through its own UI. It had to show up inside the tools researchers were already using: their survey platforms, their interview tools, their unmoderated study products. Respondent needed to become the recruiting engine that everyone else plugged into.

And the moment I looked at the product, the absence of a public API was obvious. No programmatic access. No integration story. No path for a research tool to say "recruit participants through Respondent" without sending their users somewhere else entirely.

I brought the idea to Jack. He liked it immediately, and said he wasn't sure when we could take it on. About a month later, he came back and made it the top priority. In the background, he'd been talking to the CEOs of several research tool companies, Great Question, Maze, Indeed, and found they were all thinking about solving recruiting themselves. Some were considering building their own panels. Jack saw the window: if we could get an API in front of them before they went down that road, we could become the infrastructure layer they relied on instead of the competitor they had to beat.

Discovery and validation

Jack started making introductions. Over the following weeks I ran interviews with product leaders and CEOs at Great Question, Maze, Indeed, and others. The goal was straightforward: understand the problem from their side, figure out how they imagined recruiting appearing inside their product, and gauge their appetite for building an integration.

What I learned shaped everything that came after.

First, the functionality gap was smaller than I expected. These tools already had their own scheduling systems and their own targeting logic. They didn't need Respondent to duplicate that. They needed Respondent to hand off the right parts: targeting criteria, participant profile data, and real-time recruiting status. That was the minimum viable integration. Get those three things right and a research tool could offer their users Respondent-powered recruiting without rebuilding their entire workflow.

Second, appetite varied a lot. Some teams were engineering-heavy and ready to build. Others were lean and wanted as little custom development as possible. That shaped a later decision to plan embeddable UI components for lower-appetite partners, though that stayed on the roadmap rather than shipping in the first release.

Third, I needed to know we had real commitment before we put our engineering team on this. My bar before greenlighting the build: five to eight companies willing to actually build an integration, a customer base differentiated enough from Respondent's existing users that we weren't just cannibalizing our own traffic, and a commitment of recruiting spend from the integration partners rather than just interest.

We hit that bar. Great Question agreed to be our beta partner and to work alongside us through the build, adopting endpoints as they became available. We also decided to focus first on unmoderated study tools, which had simpler recruiting flows than live interviews. That let us build the API sequentially from least to most complex functionality and learn with each step.

Building it

The engineering team working on the API was small: three engineers dedicated to it, with two others pulled in periodically to help refactor our internal infrastructure. That last part mattered more than it might sound.

Respondent's codebase was a product of its history. Several internal APIs handled different functions across the platform, each the output of a different engineering era, carrying significant tech debt. The previous engineering team was gone. What remained was a spider web of logic that worked, but only just.

The decision we made early was to build the public API the way we'd want to consume it if we were one of our own integration partners. Not as a wrapper around the mess that existed, but as the clean, stable interface we wished we had. That forced us to clean up what was underneath: deprecating older internal APIs, consolidating the abstraction layer, refactoring to align internal services with what we were surfacing externally. The tech debt cleanup wasn't a separate project. It became part of the API work itself. That gave the engineering team something worth rallying around, and they did.

The testing period with Great Question ran for several months and was more collaborative than a typical beta. We helped them plan their UI implementation, adopted feedback in real time, and ran into things we hadn't fully anticipated.

The biggest one was scheduling translation. We knew we didn't need to surface Respondent's full scheduling system through the API, since Great Question had their own. But we still needed to translate their scheduling events into Respondent's system to accurately status participants. A participant completing a study through Great Question's interface still needed to reflect the right status on our side. That required more back-and-forth than expected, and we kept checking with other pipeline partners to make sure we weren't building a solution that only worked for one integration.

The hardest single call was around participant trust and messaging. Respondent's participant experience was designed with Respondent's brand front and center. When a third-party tool is doing the recruiting, that relationship gets complicated. We made a deliberate choice not to hand the participant relationship fully to the partner. We introduced a "trusted partner" flag in the participant UI that explained when a partner was doing the recruiting, so participants weren't confused about who they were working with.

We initially decided not to include messaging in the first API release. Participants pushed back almost immediately. They expected to communicate with researchers the way they always had, regardless of what tool was doing the recruiting. We ended up having to accelerate messaging functionality into the API on short notice, which required a layer of security and encryption work we hadn't scoped for. It shipped, but it was a scramble we could have avoided with more foresight.

The launch and what came next

By the time we launched publicly, we had three partners actively recruiting through the API, five more in active development, and open conversations with another 15 to 20 tools. The launch was marketing-focused by design. We'd already been having the real conversations with the partners we cared about most. The public announcement was about sending a signal to the broader industry that Respondent was open for a new kind of business.

It worked. Within six months we had five active partners recruiting hundreds of participants through the API. The target was for API-sourced revenue to represent 20% of total revenue within the first year. And shortly after our launch, our largest competitor, User Interviews, released their own API with significantly less functionality. The fact that they followed our move was the clearest validation that we'd made the right call.

The project also gave Jack the space to step back from day-to-day product and engineering. With that overhead handled, he could refocus on investor conversations and long-term strategy, which was where he was needed most. My promotion to Head of Product followed a few months after launch.

What I'd do differently

Two things. First, I would have pushed back on the timeline and taken three more months to stabilize the internal platform before starting on the public API. The tech debt cleanup happened alongside the build, which meant we were sometimes refactoring and shipping at the same time. A more deliberate foundation would have produced a more stable result. The pace was right for the business moment, Jack had seen the competitive pressure and we needed to move, but I should have advocated harder for a short delay.

The second is a missed opportunity I still think about. At the time we were building, Anthropic was beginning to recruit participants to help train their models. That was an entirely different use case for Respondent's panel, and we were right in the middle of building the infrastructure that could have powered it. I didn't push hard enough to explore it. Looking back, that was a real opening we didn't take.

What I'm proud of

The engineering team built something genuinely good under pressure and with a complicated codebase beneath them. That doesn't happen automatically. Part of what made it work was that the project gave them something worth caring about: a clean external API to be proud of, and a mandate to fix the internal mess that had been dragging on everyone. They took ownership of it in a real way.

That outcome, a team that believed in what they were building, is something I think about as much as the API itself.