Check out the Build Series. Part 1 | Part 2 | Part 3 | Part 4 | Part 5
Three weeks after I launched DraftKit, I had 4+ collaboration requests sitting in a queue. I had designed a clean booking page, written a clear welcome message, and set up availability that reflected when I actually had bandwidth. I thought the hard part was done.
It was not. About a third of those requests had no topic alignment with the receiving creator. A crypto newsletter pitching a technical PM publication. A parenting blogger requesting a collab with a B2B SaaS writer. Great writers, wrong fit, and none of them knew it until a host declined.
The problem was not the writers. I had built an intake form that collected names, messages, and dates, but had zero intelligence about whether the two parties should actually be working together. I had put the entire fit-check burden on the host, after submission, after a decision was already framed.
If your product has any kind of request or intake flow, this is happening to you too. A form that collects information without evaluating fit is just a prettier version of a cold inbox. It moves the pain downstream instead of preventing it.
If you want a second set of eyes on where your product’s intake is generating invisible friction, email me at hello@elenacalvillo.com. I look at the flow, identify the friction layer, and tell you exactly where to intervene.
This Is an Industry Problem, Not a Product Quirk
Substack crossed 8.4 million paid subscriptions in Q1 2026, up 68% from 5 million in March 2025, and nearly 100,000 publications now earn money on the platform. That is a doubling of creator density in under a year, and the competition for collaborators’ attention is real. When a creator has 30 incoming requests in their queue, they remember which platforms made it easy to evaluate a match and which ones wasted their time with misfit pitches.
The cost of a mismatched request is not just one declined message. It is a signal to the requester that the platform did not help them. Every bad-fit request that lands in a host’s inbox is one the requester sent blind, without any context about whether there was a topic intersection worth pursuing. That friction is a product failure, not a user failure.
The intake failure shows up in three specific places:
✅ Hosts spending review time on requests that were never a match. Every review is time spent. Even a 30-second reject is friction the platform caused.
✅ Requesters getting declined without understanding why. They submitted. The host said no. The reason was invisible. That is a trust problem on both sides.
✅ Platforms watching approval rates stay low despite high request volume. If your approval rate is low, the bottleneck is usually fit, not intent.
The Pattern Is the Same Everywhere
Whether you are building a marketplace, a collaboration tool, or any platform with an inbound request flow, the default answer to “when does fit get checked?” is always the same: after submission, by a human. That default costs everyone. The request still travels. The host still evaluates. The mismatch still happens.
Why Your Product Workflow Misses This
Most PMs design intake forms as a UX problem. They focus on field labels, confirmation states, and email notifications. The question “does this request make sense before it arrives?” rarely makes it into the spec. By the time volume data reveals the pattern, the form is already live and changing it feels like a regression. So a filter gets added at the review stage instead of the submission stage, which means every bad-fit request still costs the host attention and still costs the platform credibility.
Lenny Rachitsky has written about how the best products reduce friction at the point of intent, not after. The same principle applies here: if you have signal available at submission time, that is where the evaluation belongs.
The Approach I Follow
✅ Move the intelligence upstream. Every piece of screening logic that lives in the review stage can potentially live in the form itself. The question is whether you have a signal to evaluate at submission time. For a collaboration platform, content is that signal.
✅ Use the data that already exists. DraftKit’s users have Substack newsletters with RSS feeds. That is a publicly available, structured record of what they write about, what performs, and how they sound. I did not need a proprietary database of manually tagged topics. The content was already there and structured enough to analyze.
✅ Surface analysis at the moment of intent. SMART Match fires when the requester enters their Substack URL, before they finish writing their pitch message. They see 3 topic suggestions in real time. That changes the frame: they are no longer submitting a blind request, they are confirming a specific collaboration idea before they send it.
✅ Never block. Always inform. The AI analysis does not reject anyone. It gives the requester a clearer picture of the potential match, so they can write a better message or decide the fit is not there before submitting. The product makes a mismatched request less likely without adding friction for well-matched ones.
✅ Rate limit before you scale. An AI feature on a public booking page is a cost center with no ceiling if you do not control it. I built rate limits into the edge function from day one: 10 AI requests per hour for unauthenticated users, 50 per hour for authenticated ones. That keeps the feature sustainable regardless of traffic spikes.
If you want a technical review of where your product’s intake flow is generating avoidable friction, reach out at hello@elenacalvillo.com.