FirstDistro (opens in new tab)
FirstDistro install rail
One install contract for founders, developers, and coding agents.
What FirstDistro is
FirstDistro is customer health software for B2B SaaS. It connects product usage, CRM, and revenue signals so teams see which accounts need attention before renewal.
My role
I founded FirstDistro and own product direction, design, and the shipped install experience. This case is the setup contract I wrote for a world where the installer might be a founder, a developer, or a coding agent in Cursor.
Why this problem now
FirstDistro only works after the SDK is in the customer codebase. The buyer is often non-technical. The installer is often not in the room. If setup depends on a README or a separate agent docs fork, activation dies quietly.
The bet
Install is product policy in pasteable form. One rail. Three tabs. Install is the default story (one-click pills plus CLI), but Manual and Email stay peers.
Three decisions
One contract, three doors
- Context
- Four real entry paths: founder pastes into Cursor, engineer runs CLI, someone copies a snippet, buyer emails a developer.
- Rejected
- Separate onboarding flows per path. A docs page fork for agents.
- Shipped
- Mode rail: Install, Manual, Email. Install tab has Cursor, Claude, VS Code, and Copy prompt pills, then CLI. One shared panel owns copy and tokens across empty state, settings, and modal.
- Why
- Different hands, same contract. Agents do not get a second product.
- Install, Manual, and Email share one panel.
- Install is the default tab on empty state.
Design for the agent as a user
- Context
- The prompt is what Cursor or Claude actually sees. If the agent invents unsafe patterns, the prompt failed.
- Rejected
- [YOUR_TOKEN] replace rituals. Long docs the agent must summarize.
- Shipped
- Pre-filled publishable token. Framework detect steps. Identity wiring. Verify checklist. Hard don'ts in the prompt body.
- Why
- The agent is a user with no patience for ambiguity.
- Token already filled in the prompt.
- Verify steps and hard don'ts in the body.
Honest verification
- Context
- Buyers want to know install worked. Fake green states teach the wrong lesson.
- Rejected
- Honor-system Connected button. Painted success before real events.
- Shipped
- Status from real events or honest "not yet." Live diagnostic ladder when CLI smoke is the only signal.
- Why
- Trust in setup flows is the same problem as trust in financial products. Say what you know.
- Connected only when events prove it.
- Diagnostic ladder when smoke is the only signal.
Key flow
Before vs after
| Before | After |
|---|---|
| Separate paths for CLI, AI, and manual | One rail: Install, Manual, Email |
| [YOUR_TOKEN] replace rituals in prompts | Pre-filled publishable token in copy |
| Honor-system Connected or painted success | Live events or honest waiting state |
Outcome
Shipped in the FirstDistro dashboard and npm package. Install tab is the default empty-state story. Manual and Email remain peers.