Site Engagement Without Site-Facing Tech: How We Got Here

TL;DR: A while ago, we built a site-facing marketplace for site engagement. It scaled fast. 1,400 research sites joined in 3 months. But it failed at what matters most: building trust, reducing burden, and enabling true collaboration. This essay explains why marketplaces with site facing portals are the wrong model for site engagement, and what we built instead. This is the story of my mistake, so you don’t repeat it. Better fail differently.

Prefer listening instead? Access the audio version.

Engagement is communication. Communication is a transaction.

Tech’s response to most transactions is: a marketplace.

This is the story of how we made the mistake of building a site portal, what we learned from it, and why you must avoid offering (rather: imposing on) sites a portal to engage with them.

Part I: The Turning Point

Hey,

I had such a fun week at Yendou. By far the sales-heaviest week since Yendou’s conception. 35 potential client calls. Most of them are referrals. I love where this is heading. One topic kept popping up, and that’s what I want to discuss today:

The site experience; and why we should stop building software for site ops.

Over a year ago, I decided that the best Site Engagement experience isn’t a sponsor-site marketplace (Airbnb-style) with a site-facing tech solution. The best Site Engagement experience is a technology that enables engagement without burdening sites with more tech.

So, even with 1,400 oncology research sites joining Yendou’s site engagement marketplace (Product version 1.0) in just three months, the news writing about our fundraise and fast growth, and the investors happy about it, I made the decision to kill the product and start anew. No one was amused.

Part II: Minimalism, AI, and the Interface Epiphany

With the rise of AI-powered search platforms like ChatGPT, Gemini, and Perplexity, we all realized something:

But what about exchanging information? I wanted to make that happen for sites.

The new direction was clear: let’s build an automation-powered Site Engagement platform and make email the only tech sites need to use to interact with clinical research teams at Sponsors/CROs.

Email and chat are the most powerful minimalistic, conversational user interfaces tech has ever invented. The social media “feed” is nothing but a replication of the email and chat interface design. The premise? Make it super easy for people to share information. AI providers are riding the old and gold, proven genius wave. Turns out, there are things we shouldn’t reinvent.

Things like… the email interface.

Sites already use email daily, so why introduce yet another data exchange tool?

We went back to the drawing board. We asked:

And Yendou, as people know it today, was born: the AI and Automation-Powered Site Engagement Platform.

It wasn’t cheap to get there. So here’s the story:

Part III: Why Marketplaces Don’t Work in Clinical Trials

And Why We Shut Ours Down

1. Clinical trials are about trust. Marketplaces kill it.

Marketplaces work for quick, simple transactions. Perfect for consumer markets: a $45 cab ride, a $500 Airbnb stay. These are transactions. Clinical trials are not. Clinical trials are relationships.

Every interaction is part of a complex environment of confidential documents, unapproved molecules, patient safety, and regulatory compliance. This isn’t a $50 transaction. It’s a multi-year, multi-million dollar collaboration with reputational and human stakes.

You cannot replace the trust required to let someone manage your clinical pipeline with a “Submit Order” button.

2. Marketplaces are transactional. Clinical trials are iterative.

Marketplaces operate under the assumption that the match is the job. Once buyer and seller agree, the platform has done its part. This model assumes low variability, short timeframes, and well-defined deliverables.

Clinical trials are the opposite. They are not a single event; they are complex, adaptive systems. Between site identification and site close-out lie hundreds of contingencies: evolving protocols, staffing changes, document delays, and regulatory constraints. Sponsors and sites must collaborate through uncertainty. And this is done over a very long time period.

A marketplace cannot handle that. It was built to reduce relationships to clean, clear transactions. Clinical operations require infrastructure that supports iteration, escalation, and adjustment over a long time period.

Apropos time!

3. You don’t hang out in a marketplace. You hang out in a system.

Nobody spends hours inside Uber. You open it, book a ride, and move on.

That’s what marketplaces are built for: visit, transact, exit. They’re designed for throughput, not engagement. They are built for low-stakes, one-off decisions, not longitudinal workflows.

But clinical operations don’t work that way. Trials last years. They evolve. They’re filled with dependencies, protocol amendments, staffing changes, inspection risks, and knowledge that accumulates over time.

The job isn’t to book a ride, an appointment, to send a document, or to answer a survey. The job isn’t to do something. The job is to manage everything; over months, sometimes years.

The job isn’t to ease the efficiency of discrete transactions. The job is to sustain value over time.

4. Marketplaces rely on real-time symmetry. Clinical trials are asymmetric.

There’s another problem: marketplaces only function when both sides show up at the same time with a clear intent to transact. They depend on instant mutual availability; what economists call temporal coordination. If one side doesn’t show up, nothing happens.

This built-in dependency works in B2C because most consumer services are low-friction, low-stakes, and high-frequency. A customer books. A provider responds. The loop closes in minutes.

But clinical research doesn’t work like that. In site engagement:

• One side (Sponsor/CRO) initiates demand, sets the rules, and requires compliance under tight timelines.
• The other (Site) is reactive, overloaded, and deeply asynchronous; often unable to respond in real time.

The marketplace model assumes no bottlenecks. That both sides are ready now. That neither can delay the job. That’s fiction in clinical trials.

In this environment, dependency becomes fragility. Trials stall not because of poor matching, but because the model assumes symmetry where none exists. The very structure of a marketplace becomes the bottleneck, it creates artificial dependencies in workflows, holding ClinOps teams back from getting the process running.

The technology itself erodes strategic control over the process.

5. Marketplaces require standardization. Clinical trials demand customization.

From Uber to Airbnb, every marketplace relies on standardized units of service.

An Uber ride is an Uber ride. A hotel night is a hotel night. The platform scales because the work is predictable and the deliverables are consistent. The interface doesn’t need to change because the product doesn’t either.

But clinical trials are not standard. They’re:

• Indication-specific,
• Protocol-specific,
• Country- and site-specific,
• And timeline-specific.

You could argue that clinical operational processes are all the same. Sure, but stakeholder reaction to them is a huge variable. No two trials are the same. No two sites answer the same set of feasibility questions. Even the same sponsor will ask for different workflows, formats, and timelines from one trial to the next.

Instead of recognizing this complexity, marketplaces flatten it and penalize anything that doesn’t conform.

In fact, the only way to escape the standardization penalty of marketplaces is through customization that occurs outside the system, thereby increasing redundancy and operational burden. (Made a note to write about this paradox.)

This makes it impossible to create the kind of clean “book it and forget it” interfaces that marketplaces depend on. You cannot “productize” a study the way you productize a food delivery. The inputs change, the workflows evolve, and the output demands agility in response.

Part IV: Why Marketplaces Don’t Work for Sites

And Why We Shut Ours Down

Now I told you why marketplaces don’t work for clinical trials. It’s time to answer the question, why not for sites.

1. Sites Don’t Want to Be “Listed.” They Want to Be Understood.

Site engagement marketplaces treat sites like interchangeable vendors on a digital shelf. The logic: show up, fill in your profile, and sponsors will find you. (Remember SIP?)

But that assumes the value of a research site can be captured in a dropdown.

It can’t. (I’ve got plenty of stories to prove it.)

Sites aren’t Uber drivers with stars reviews. They’re institutions embedded in complex ecosystems: hospital affiliations, staff availability, PI interests, local SOPs, ethics boards. Their readiness isn’t static. Their capabilities aren’t comparable. The value they bring lives in the context of past relationships, current studies, and operational nuance. Without that context, there’s no way to engage, build trust, or form meaningful relationships.

A site’s job isn’t to sit in a marketplace and wait. It’s to execute high-fidelity science under real-world constraints. Being understood matters more than being matched.

2. It Adds Another Portal to an Already Overloaded Stack

Sites are drowning in systems: CTMS, eTMF, EDC, IRT, feasibility portals, survey tools, sponsor-specific platforms, email threads, shared drives. A marketplace is just another login. Another inbox. Another UI to learn. We should remember that

You think you’re streamlining? You’re not. Adding a portal fragments what was working, by inserting yet another workflow.

3. It Creates Dependencies That Slow Down ClinOps; and lift Up the Pressure on Sites

Marketplaces rely on responsiveness: log in, review, click, respond. They assume real-time availability. That’s not how sites operate.

ClinOps teams are full-time trial managers. Sites are clinical teams juggling patients, protocols, and competing demands. They’re asynchronous by nature.

When platforms expect instant engagement to move things forward, the site becomes the bottleneck and is ultimately penalized for how their world actually works.

Expecting sites to behave like gig workers in an app? That’s not just unrealistic. It’s a design flaw.

Part V: Why Vendors Still Build Marketplaces

In clinical research, marketplaces aren’t built because they add value. They’re built because monopolies resist interoperability. So everyone has to build everything.

In other industries like Sales, FinTech, even HR tech, interoperability is the default. Vendors integrate. Data flows across platforms. Users win.

Let’s take Sales as an example:

Every CRM connects with a diverse ecosystem: engagement tools, appointment schedulers, note-taking apps, AI sales coaches, analytics dashboards. The philosophy is simple: People pick what works. And software wins by playing well with others.

Integration isn’t a nice-to-have. It’s a go-to-market strategy.

As a CRM provider, you don’t restrict users from better tools just to force adoption of your weaker “engagement module.”

Finance Tech works the same way. You got banking, accounting, HR systems, all stitched together. Interoperability is how scale happens.

But in clinical research? We do the opposite.

Vendors play a zero-sum game.

Scarcity mindset drives the roadmap. The goal isn’t to help customer grow by enabling growth. The goal is to trap them. Control matters more than impact. Monopoly > customer centricity.

Faced by the question how to expand business growth? dilemma, innovate or survive, they ask: If a product can’t win on performance or ROI, what do you do?

And the answer is always: block integrations. And build competitive modules.

This forces every new entrant to rebuild infrastructure just to function. what was supposed to be a platform, is now a marketplace, because stakeholders must connect. Marketplaces are often the obvious Go-to, when faced by such artificial barriers.

Sometimes the most obvious answer, is the wrong one. Wrong and necessary.

The result? the worse tech experience for all customers.

The not so funny part is: The incumbents aren’t even winning. They’re distracted. Too busy defending territory to actually dominate anything.

There’s a reason Salesforce is worth $143 billion. They do one thing. And they do it well. CRM! Focus is a superpower.

So, we killed the marketplace. We decided to focus.

Part VI: Why We Killed Ours

It took us a year, all my savings, and investor money to build Yendou V1.0: the site engagement marketplace.

We had 300 prospects on the waitlist and 1,400+ research sites on the platform. Then we observed everything I’ve just told you above. I remember going to sites, spending the day there, having conversations with site owners and investigators, shadowing study coordinators, and realizing: damn it.

The arguments above are the result of those observations, interviews, and many debates about what’s right and what’s wrong.

Realizing it was the wrong model wasn’t easy. It took courage to kill the marketplace and start over.

When you kill something, you make a lot of people afraid, including yourself.

You also make a lot of people upset.

What if you’re wrong again?

What about the sales motion already in progress?

You’re shutting down your revenue-generating engine and going back to building.

You know you’re racing against time. You’re gambling.

Most people don’t dare to pivot. They’d rather crash hard into a wall than try a second time.

But I’ve gambled a dozen times.

Won many. Lost many.

My motto is:

Another reason to change course: it became very clear to me that

Marketplaces are the lazy answer to the site engagement problem.

Lazy, because it allows us to avoid the interoperability issue in the industry.

But that war is ending. The tech burden at the site level has become impossible to ignore. Sponsors, frustrated by inefficiency and rising costs; are now demanding better vendor collaboration.

The shift is inevitable. The pressure to streamline is rising.

Soon, the industry will have no choice but to adopt technology that serves research, and not force research to serve tech incumbents’ hunger for unearned monopoly.

We’re anticipating that future.

It’s also lazy to build a marketplace, because it’s easy.

Easy is building a site engagement strategy that serves sponsors and CROs, but not sites.

Hard is building a strategy that works for both.

Hard is designing for knowledge workers at desktops, and clinicians moving between patient rooms.

Hard is making site engagement valuable for both sides. Visible for sponsors/CROs, and invisible for sites.

And it turned out:

hard was the right way.

In the long term, hard is always the easy path.

Part VII: The AI & Automation powered Site Engagement Platform (Yendou V2.0) Is Damn Awesome.

By the time Yendou was ready, we were ready, and the industry was ready.

Many sponsors and CROs went from doubling down on CRAs and Study Startup Leads to recognizing the power of site engagement in scaling site performance.

In the last 12 months, the job market for Site Leads, Site Engagement Leads, Site Relations Managers, and Clinical Site Liaisons has surged.

On LinkedIn, postings for these roles have increased significantly as sponsors and CROs acknowledge site engagement as a critical function in clinical trials. The need to understand and monitor engagement became urgent.

If we hadn’t dared, there wouldn’t be a Site Engagement Platform in the market, when the market needed it. A site Engagement platform built for the clinical research workforce of the future.

Part VIII: What Comes Next

As of today, we are far from where our vision of the future lies; yet far ahead in terms of technological enablement for clinical research teams compared to what exists in the market. But to get there, killing what was semi-working in favor of what is truly needed was necessary.

I’ve always been a proud technocrat. I strongly believe in the power of technology to advance our lives, enable business growth, and generate value for society at scale. When I founded Yendou, I never imagined I’d be proudly pitching it as the only site engagement platform with no site-facing tech.

But here we are.

I strongly believe in the power of technology to empower research sites too.

Yet I also believe it won’t be through static web applications.

I dream of a world where IoT and voice-to-data move with site staff, capturing information, structuring it, and seamlessly distributing it across systems.

A world where no healthcare worker ever has to touch a piece of software to share information.

We’re close to that world.

And that’s the only world I want to build for research sites.

Until then, I’ll keep building the infrastructure to enable that transition, while honoring the limitations of today, to achieve the maximum possible for today’s taskforce.

And as we are moving towards a new era of work, here’s my recommendation: