Hydra
From install to first fix merged.
Onboarding Spec  ·  Internal  ·  May 2026
───────────────────────────────────
Tristan Benozer
Visual implementation pending brand identity from Neil.
Section 01

The Problem

We installed seven competitor apps. Same result every time: blank dashboard, no direction, no first experience. A dead end.
The Root Cause
0

value delivered before the user is asked to configure something. That is settings-first onboarding. Completion rates collapse.

The fix
Value before completion

The user gets their first meaningful result before the onboarding screen closes. Not after. During. The onboarding IS the first audit.

The activation event
First fix merged

Not first login. Not first finding. First fix merged. Every screen in the flow exists to remove friction toward that moment.

Section 02

Six Rules

Every screen in the onboarding flow answers to these. No exceptions.
Design Principles

The constraints that govern every screen.

1
Value before completion
Real finding on real code before the onboarding screen closes.
2
Aha moment = first fix merged
Every screen before that moment exists only to remove friction toward it.
3
One action per screen
No configuration menus. No sidebars. One clear thing to do. Then advance.
4
Demo repo as silent fallback
Zero findings on their repo? Switch silently. No dead ends, ever.
5
Plan selection at peak motivation
User has seen the full fix and the PR before they choose a plan. The value is undeniable when the question arrives.
6
Free is real
Full product, generous limits. No degraded experience. No "upgrade to see results."
Section 03

The Flow

Nine steps. Install to first fix merged.
Gold = user action.   Green = Hydra runs automatically.
The Flow · Overview

The full path.

1
Install GitHub App user
GitHub native flow. Redirects back to Hydra.
2
Enter Anthropic API key user
BYOK. Key validated before advancing.
3
Pick a repo user
Free-pick. Standard GitHub selector.
4
Discovery + Audit hydra
Live progress feed. 8-12 min. Back button disabled.
5
First finding surfaced hydra
One finding shown. Not a list. Real code, real risk.
6
Fix runs hydra
Live progress. Tests baseline, writes fix, verifies, opens PR.
7
PR created hydra
User reviews the diff on GitHub.
8
Choose a plan user
Free / Team trial / Business trial / Enterprise.
9
PR merged -- aha moment
Finding auto-closed. Activation confirmed. Dashboard.
Steps 1-3 · User actions

Three user steps before Hydra takes over.

Step 1 · User
Install GitHub App

GitHub's native App install flow. Hydra does not control this screen.

On completion, GitHub redirects back with ?installation_id=...&code=... -- handled by the existing SetupWizard callback.

No new engineering needed here.

Step 2 · User
Enter Anthropic API key

Headline: Connect your Anthropic API key

Body: You control the costs. We never mark them up.

  • Masked input field
  • Key validated against Anthropic API before advancing
  • Error: "Check key starts with sk-ant-"
  • Do not advance on failure
Step 3 · User
Pick a repo

Headline: Which repo do you want to start with?

Standard GitHub repo selector. Name + last pushed date. Nothing else.

  • Free-pick -- no Hydra filtering
  • Developer knows their codebase better than we do
  • One click, then Hydra runs
Step 4 · Hydra · The most important screen

Discovery + Audit running.

This is not a spinner. The user needs to see something real is happening.

Reading your codebase...
Mapping your architecture...
Identifying languages and frameworks...
Running 39 audit tools...
· Verifying findings against your code...
· Reviewing results...

Each line appears as the step completes. Animated ellipsis if a step exceeds 3 seconds.

Visible on screen
Cost + time estimate

"Typical audit: 8-12 minutes. $15-35 in Anthropic costs."

Sets expectations. Their API key -- their cost. No surprises.

Rule
Back button disabled

Cannot interrupt a running audit. Timeout (>15 min)? Surface partial findings. None? Switch to demo repo.

Step 5 · Hydra

First finding surfaced.

Headline: Hydra found [N] issues in [repo name]

One finding shown. Not a list. One finding made concrete and solvable.

Critical
SQL query constructed from unvalidated user input
src/api/users.py  ·  line 47
A user-supplied parameter is interpolated directly into a SQL string. An attacker can inject arbitrary SQL -- including commands that read or delete data from any table.

"Hydra can fix this automatically -- write the code change, run your tests, and open a PR."

[See the fix →]

Why one finding
One finding is solvable. 24 findings is a list.

The full findings list lives on the dashboard. This screen has one job: make the problem feel real and the fix feel obvious.

What comes next
Fix runs. Then plan selection.

The user sees the finding, then watches Hydra fix it and open a real PR. Plan selection comes after the PR is created -- when the value is not a promise but a fact.

Step 6 · Hydra

Fix running.

Same live-progress pattern as Step 4. Not a spinner.

Creating isolated workspace...
Running your test suite (baseline)...
Writing the code change...
· Running tests -- verifying nothing broke...
· Running lint and format...
· Reviewing the diff...
· Opening a pull request...

Estimated time: 3-6 minutes.

If fix passes all gates

PR opened on GitHub. Proceed to Step 7.

If fix fails all gauntlet gates

Do not dead-end. Offer to create a Linear ticket for the finding instead.

User leaves onboarding with something tangible -- a tracked issue, not a blank screen.

Step 7 · Hydra

Pull request ready for review.

Hydra opened a PR in [repo name]. Review it and merge when ready.

[View PR on GitHub →]   primary

[Go to dashboard →]   secondary

What's in the PR
  • Code written using your codebase's own conventions
  • Tests passing -- gauntlet-verified before PR opened
  • Lint clean
  • Diff reviewed by Hydra's reviewer agent
  • Finding reference in the PR description
What happens next
Plan selection.

The user has just watched Hydra write a fix, pass tests, and open a real PR on their code. The value is not hypothetical. This is the right moment to choose a plan.

Step 8 · User · Plan selection

The fix is in your repo. Now pick your plan.

Free
$0
No credit card. Ever.
  • Full Discovery + Audit
  • 5 fixes / month
  • 5 Linear cycles / month
  • 1 doc run / month
  • Unlimited repos
[Continue on Free]
Business
$40/dev/mo
14-day trial  ·  no card today
  • Unlimited repos
  • Jira integration
  • Audit logs + reporting
  • Priority fix queue
[Start Business trial]
Enterprise
Custom
White-glove. Separate path.
  • SSO / SAML / RBAC
  • VPC deployment
  • Compliance reporting
  • SLAs + dedicated support
[Talk to us →]
Step 8 · Trial mechanics

No credit card until day 14.

PlanTrialCredit cardStripe
FreeNoneNeverNot created
Team14 daysNot at signupDay 14
Business14 daysNot at signupDay 14
EnterpriseWhite-gloveNegotiatedContract

Onboarding continues immediately after plan selection. No interruption.

10
Day 10 -- trial reminder email
"4 days left. Add a card to keep going -- or switch to Free."
14
Day 14 -- Stripe billing activates
No card added? Account reverts to Free -- not zero access.
Cancel any time
Access continues to end of billing period. Always lands on Free -- never on nothing.
Step 9 · Onboarding complete

Dashboard.

One finding card visible from onboarding. Full findings list accessible but not the lead. PR merge is still pending -- the checklist nudges toward it.

Connected GitHub
Connected Anthropic API key
First audit complete
First fix opened
First fix merged
Run Hydra on a second repo

Checklist disappears when complete or dismissed. "First fix merged" closes via GitHub webhook.

Onboarding complete. The aha moment is one PR merge away. The checklist keeps the user moving toward it.

The expansion nudge

"Run Hydra on a second repo" surfaces naturally after the first repo is working. Not during onboarding. After.

Empty State · Zero findings on their repo

Their repo is clean. Show them the real thing anyway.

Trigger

Audit of user's repo returns zero findings. Surface the result honestly, then offer a real alternative -- not a pre-seeded fake.

What the user sees
Your repo looks clean. Want to see Hydra work on a real codebase?

Enter any public GitHub repo URL. Hydra runs a real audit -- live LLM, real findings, real fix. Not a demo. Not pre-loaded data.

github.com/ expressjs/express

What happens next

1
User enters any public repo URL
No restrictions. Any public GitHub repo. They pick something they know or care about.
2
Hydra runs a full audit
Real LLM cost, real findings. Progress feed continues as normal. Anthropic API key is theirs -- they see exactly what it costs.
3
Finding surfaced, fix runs on a fork
Hydra cannot open a PR on a repo they don't own. It forks the repo, applies the fix, and shows the diff. Same output -- different merge target.
4
After onboarding -- resurface their own repo
Dashboard banner: "Your repo is in great shape. Run Hydra again when your codebase grows." Their clean repo is a good thing, not a failure.
Edge Cases

Every failure has a path forward.

ScenarioHandling
GitHub OAuth failsError screen with retry + contact support link.
Anthropic key invalidInline error: "Check your key starts with sk-ant-." Do not advance.
Audit times out (>15 min)Surface partial findings if any exist. If none, switch to demo repo.
No supported languages in repoExplain supported languages. Prompt to pick a different repo. Do not switch to demo repo silently -- requires explicit re-selection.
Fix fails all gauntlet gatesOffer to create a Linear ticket instead. Never dead-end.
Browser closed mid-onboardingResume from last completed step on next login. State persisted server-side.
Enterprise clicks "Talk to us"Route to contact form. Onboarding ends here -- separate white-glove path.
Trial user misses day 14Reverts to Free tier limits. Does not lose access. No punitive gate.
Activation Metrics

Instrument these from day one.

EventWhat it measures
onboarding_startedGitHub App install callback received
api_key_connectedAnthropic key validated and saved
repo_selectedUser picked a repo and clicked Start
audit_completedFindings returned (real or demo)
finding_viewedStep 5 rendered
plan_selectedfree / team-trial / business-trial / enterprise
fix_startedFix workflow kicked off
pr_createdPR opened on GitHub
pr_mergedAha moment. GitHub webhook on merge.
demo_repo_fallbackZero findings, demo used

Benchmarks

install → audit completed
<12 min
finding viewed → plan selected
<2 min
plan selected → PR created
<8 min
pr_merged within 24h of install
= activated
free → paid within 90 days
8-15%
Open Items

Decisions still needed.

ItemOwnerNotes
Trial terms -- 14-day, no CCTristanConfirm before Stripe implementation begins
Demo repo contentsTyler3-5 pre-seeded findings. Python or TypeScript. At least one fixable in onboarding time.
Resume-from-last-stepTylerServer-side state persistence -- browser close must not restart from zero
Enterprise contact pathTristanContact form or Calendly? What happens after "Talk to us" is clicked?
Day 10 trial reminder emailTylerStripe-triggered or in-house? Copy TBD.
Annual discountTristanShow on plan selection screen? Standard PLG is 20% for annual.
Seat definitionTylerWho counts as a developer seat? Must be unambiguous before Stripe setup.
Brand identityNeilAll visual implementation blocked until brand is delivered.
The Activation Event

Install. Find. Fix.
Done.

First fix merged in under 24 hours.
That is the only metric that matters at launch.