> ## Documentation Index
> Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Pilot onboarding

> What happens between Pilot Reservation payment and the first migration email leaving your tenant — week-by-week activities, ownership, milestones.

The Pilot Reservation locks the engagement and starts the paid work. The first migration email doesn't leave the tenant on day one. This page covers what fills the time in between.

A typical pilot moves from payment to first-wave kickoff in **two to four weeks**, with the exact cadence shaped by how quickly Stripe Connect activates, how the entitlement source is structured, and how big the first pilot cohort needs to be. This runway sits before the program clock — the quoted quarter starts at kickoff, with the pilot running as the program's first two weeks.

By the time the reservation is paid, two artefacts already exist: the [Migration Analysis](/working-with/migration-analysis) (the post-call decision document that supported the buy decision internally) and the signed Migration Agreement covering pilot + migration phases. Pilot onboarding picks up from there.

## Week 1 — kickoff

The first week sets up the rails before any subscriber sees anything.

<Steps>
  <Step title="Kickoff call">
    Founder-led, \~60 minutes. Confirms cohort axes, identifies the entitlement source (RevenueCat, Adapty, Firebase, custom backend), names the engineering point of contact, and locks the pilot wave plan. Recurr brings a draft brief into the call; you brief any internal stakeholders before or after.
  </Step>

  <Step title="Stripe Connect onboarding">
    Recurr generates the Connect onboarding link. You complete Stripe's standard flow — company details, banking, identity verification. Stripe verifies the account; activation typically lands within 1–3 business days. The pilot can't ship until the Connect account is live.
  </Step>

  <Step title="DNS for branded checkout">
    Subscribers see `subscribe.{yourdomain}.com` rather than a Recurr URL. You point a CNAME at Recurr's checkout host; we issue the certificate. \~15 minutes of DNS work, propagation within hours.
  </Step>

  <Step title="Entitlement integration sized">
    Your engineering point of contact and Recurr's integration lead walk the entitlement source together. For most centralised entitlement setups (RevenueCat, Adapty, custom), this is a 2-hour conversation that produces the integration plan. The plan covers webhook subscriptions, identity-match strategy, and the cutover sequence.
  </Step>
</Steps>

## Week 2 — wiring + content

Engineering integration runs in parallel with copy and cohort-data work.

<Steps>
  <Step title="Webhook + entitlement wiring">
    Engineering work on your side: subscribe Recurr's webhook stream into the entitlement source, surface the `is_subscribed` boolean from the new web subscription state alongside existing Apple / Google receipts. Typical scope: 2–4 engineering hours for centralised entitlement setups.
  </Step>

  <Step title="Cohort data export">
    You export the eligible subscriber list per the pilot wave plan. Shape: CSV with the cohort-axis fields (tenure, geo, plan, engagement signal, current store rail). Format details land during the kickoff call. Recurr loads, validates, and confirms the cohort size against the pilot plan.
  </Step>

  <Step title="Copy review">
    Recurr drafts the migration email + checkout copy, branded to your voice. You review one round, mark up anything that doesn't sound like your brand. Recurr revises and re-ships for final approval.
  </Step>
</Steps>

## Week 3 — staging + sign-off

The pilot rehearses against a small internal cohort before any external subscriber sees the migration email.

<Steps>
  <Step title="End-to-end staging run">
    Recurr fires the migration email + checkout + entitlement cutover against a handful of internal test subscribers (typically Recurr-side + a few of your team members opted in). You verify the experience end-to-end — email lands, checkout works, entitlement flips correctly, the app continues to grant access after migration.
  </Step>

  <Step title="Holdout selection">
    Recurr selects the matched store-billing holdout cohort — same tenure, plan, engagement, geo as the pilot cohort, kept on store billing so churn impact is measurable. You see the holdout spec and confirm it matches your read of the segment.
  </Step>

  <Step title="Gating thresholds agreed">
    Migration rate, holdout-relative churn delta, web-side billing health, and support volume — each gets a pre-agreed threshold. If a wave breaches any threshold, the next wave doesn't ship until cause is understood. You sign off on the thresholds before the first wave launches.
  </Step>

  <Step title="Internal comms">
    Heads-up to your support, CS, and any team touching the subscriber relationship. Recurr supplies a wave brief; you adapt it to your internal voice.
  </Step>
</Steps>

## Week 4 — first wave (program week one)

The onboarding weeks above are runway. The program clock starts here — the quoted quarter begins at first-wave kickoff, and the pilot runs as the program's first two weeks.

<Steps>
  <Step title="Pilot wave 1 launches">
    The first migration email ships to the first pilot cohort. Recurr operates the send; you watch the dashboard.
  </Step>

  <Step title="Conversion accrues">
    Subscribers receive the email, click through to checkout, migrate or stay. The dashboard tracks open / click / conversion / drop-off in real time. Recurr's CX layer holds Tier 1 support inbound on the billing center directly.
  </Step>

  <Step title="Wave report + gating decision">
    7 days after launch, the wave report lands in the dashboard. You review against the agreed thresholds. If gates clear, the next wave ships; if a gate breaches, the program pauses while the cohort spec adjusts.
  </Step>
</Steps>

## What's standing up by first wave

By the time the first wave ships, you have, in your hands:

* **Connect dashboard access** with full visibility into every charge, fee, and payout
* **Webhook + entitlement integration** wired into your existing identity source
* **Branded checkout** live at `subscribe.{yourdomain}.com`
* **The operator dashboard** showing wave performance against gates in real time
* **The matched holdout cohort** running on store billing for retention comparison
* **Pre-agreed gating thresholds** the program operates against wave-to-wave

These join the Migration Analysis and Migration Agreement already in hand from the pre-reservation phase. The pilot's job is to validate the model on your real subscribers; the artefacts above outlast the engagement — your Stripe account, your DNS, your subscriber data, your integration code. Recurr operates on rails you own.

[Migration Analysis →](/working-with/migration-analysis)

[Migration framework →](/framework/pilots-and-waves)