Landing page (adopt journey) user journey - landing redesign
Persona
The engineering lead at an existing organization - owns a living repository, an established SDLC, and human staff. Backwards compatibility is vital; they will not replace their workflow or people outright. Skeptical of AI PRs landing in their repo. Success for them: they install the GitHub App on a real repository and let Bloom plan and ship changes against the code they already have.
Entry points
| Entry | Arrives via | State of mind |
|---|---|---|
| Greenfield journey's switch strip | "Bringing an existing repository?" | self-selected, evaluating fit |
| Shared URL from a colleague/founder | "look at this" | defensive of the existing process |
| GitHub README pointer | already in the repo's orbit | wants specifics, not promises |
The journey
1. Hero + install card (0-5s)
- They see/do: H1 "Add Bloom to the repo you already have" and the GitHub App install card - repository bound, read-only snapshot, change-tickets planned against the code, PRs targeting the default branch.
- They're asking: "Does this disrupt what we run today?"
- Decision to win: adoption reads as an install, not a migration.
2. Journey check (5-10s)
- They see/do: the switch strip - "Starting from scratch? See the greenfield path."
- Decision to win: misrouted visitors switch instead of bouncing.
3. How adoption works (10-30s)
- They see/do: install the App → start from your codebase (change-tickets planned against a read-only snapshot, opened as GitHub issues, delegated to Bloom engineers) → normal pull requests (their CI, their reviews, unchanged) → your gates stay.
- They're asking: "What changes on day one?"
- Decision to win: "nothing is replaced" is demonstrated step by step.
4. Grow the team at your own pace (30-50s)
- They see/do: Engineers (Bloom alongside humans, least-loaded routing), Product owner + reviewers (advisory lenses on top of their reviews), Designers (per-project studies) - and the closing line: keep every human gate, retire duplicated ones at your own pace.
- They're asking: "Can we trial this without betting the org?"
- Decision to win: incremental adoption with reversible scope.
5. Exit (50s+)
- They see/do: "Bring Bloom to your repo" - adopt a repository and see what Bloom plans, grounded in the code they already have.
Exits and CTAs (ranked by intent)
- Open the dashboard (adopt a repository) - the conversion
- Read the developer docs - the diligence path for this persona (heavier than for the greenfield visitor)
- View on GitHub - inspecting how Bloom itself is run
Drop-off risks (accepted)
- This persona reads docs before installing anything - accepted; the docs CTA is deliberately prominent.
- Bloom does not yet take over a pre-existing backlog (verified in #912; the copy was aligned to shipped behavior). Leads who arrive expecting backlog takeover may bounce - accepted until #918 ships, when step 2 gets upgraded.
- The demo repo (
acme/storefront) is illustrative - accepted as standard practice; no real-customer implication.
Success signals
- GitHub App installs on existing repositories, followed by Bloom-planned change-ticket PRs reviewed through the org's normal process.
- Docs traffic from this page converting to installs rather than ending the journey.