Why my founding cohort is hand-curated, not auto-issued

Two weeks from the first cohort invites going out, so it's time to write down a decision I actually made back in early May, before a single person was on the waitlist: RecoverStack's founding cohort is hand-curated. No auto-issued invite codes. I read and approve every application myself.

Who are the founding cohort? They are RecoverStack's first 30 customers, invited starting June 29. They get the real service working on their live Stripe account for free all through July 31. Then, they get 40% off list for life when the first charge fires on August 1. That's the deal, and it's a real one, which is exactly why I care who fills these seats.

The default playbook theory says otherwise: Collect a waitlist, blast codes & count signups. My planning math says that route fills maybe 15 of the 30 seats (300 waitlist x 5% conversion, scenario numbers, not data). And it fills them with whoever clicked first.

The problem is what the cohort is FOR. To me these aren't beta testers, they're design partners on the whole journey of getting this thing off the ground. Their recovery numbers, their onboarding friction, their (permissioned) case studies are what has to carry the August 1 hard-launch. That only works if I pick for fit and earn their trust first, which is hard to do if their invite codes are automatically issued to them.

So every signup goes through three filters by hand. Stated MRR fit: $5-50k subscription revenue. Engagement quality: did they reply to the drip with substance? Founder availability: did they commit to 1:1 interactions?

Here's the honest part: I've never run a cohort before. I'm preparing talking points, but mostly I want the 1:1s to flow naturally and hear the operator's actual problem. Maybe it's something I can build into the product, maybe it isn't and I learn something anyway. Either way I want it first-hand.

A concrete approve-vs-fail: "send me the link" and nothing else is a probably fail. "We're at $12k MRR on Stripe, our biggest decline code is card_declined, can your retry logic tell that apart from insufficient_funds?" is very likely an approve, and honestly that's a person I want on a call.

The cost is real: about 30 minutes of triage per member, 30 members, roughly 15 hours across the curation window. For a solo founder working on many other surfaces that's not a rounding error. A peer told me it doesn't scale. He's right, and it shouldn't. The founding cohort gets special treatment on purpose. Later, with the tone set and hopefully a team beside me, the big-client talks stay 1:1 but the rest gets systematized.

Next Monday I'll show the actual approval flow: the checklist, the admin command, the notes I write on every decision.

If you run a Stripe SaaS in the $5-50k MRR range and want one of the 30 founding seats, the waitlist is open at recoverstack.dev/early-access. Free through July 31, then 40% off list for life. I read every application myself, so a line about your actual decline-code pain goes a long way.

If you've run a founding cohort either way, what did your selection method actually get you?