Recurr is operated by a small team. Migrations today are delivered with the founder — Matt — in the room from the Migration Review through pilot, full migration, and post-launch monitoring.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.
What “in the room” means
- Migration Review call: Matt runs it. Not a pre-sales engineer who hands off to delivery later.
- Pilot kickoff: Matt is on the kickoff call, walks through the cohort spec, and is the named contact for any operational decisions.
- Wave reporting: Matt is on the weekly review. He’s reading the same dashboards your team is.
- Operational decisions: when something needs adjustment — cohort spec, offer details, gating thresholds — the decision is made with Matt, not relayed through a project manager.
- Direct line: matt@recurr.dev. Reply-all on every relevant thread. No tier-1 support layer in front.
Why this matters at this stage
The migration framework is well-defined, but every customer’s app has specifics — cohort distribution, store mix, audience type, internal politics — that benefit from a single reviewer with full context. At the current scale, that reviewer is Matt. The tradeoffs are explicit:- Faster decisions. No “let me check with the team” loops. Decisions land in the call.
- More direct alignment. The strategy and the execution are running through the same person.
- Limited concurrency. Recurr can run a small number of pilots and migrations at once. New engagements are sequenced rather than parallelized.
