スキル一覧に戻る

developer-signup-flow

jonathimer
更新日 Yesterday
4 閲覧
76
4
76
GitHubで表示
メタapidesign

について

このスキルは、開発者向けツールの最小限のサインアップフロー設計を支援し、OAuth連携と即時APIキー生成に焦点を当てています。ユーザーがサインアップからコード記述まで60秒未満で移行できるよう、摩擦を軽減するための指針を提供します。技術系製品の登録UXを構築または最適化する際にご活用ください。

クイックインストール

Claude Code

推奨
メイン
npx skills add jonathimer/devmarketing-skills -a claude-code
プラグインコマンド代替
/plugin add https://github.com/jonathimer/devmarketing-skills
Git クローン代替
git clone https://github.com/jonathimer/devmarketing-skills.git ~/.claude/skills/developer-signup-flow

このコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします

ドキュメント

Developer Signup Flow

Create signup experiences that respect developers' time and get them to code as fast as possible.

Overview

Developer signup is your first chance to demonstrate that you understand developers. Every unnecessary form field, every extra click, every "verify your email before continuing" is a message that you don't value their time. The best developer signups feel like they barely exist—developers go from "I want to try this" to "I'm writing code" in under 60 seconds.

This skill covers OAuth integration, API key generation UX, progressive profiling, and measuring what actually matters in signup conversion.

Before You Start

Review the /devmarketing-skills/skills/developer-audience-context skill to understand your target developer segments. Signup optimization varies significantly based on whether you're targeting hobbyists exploring on weekends versus enterprise developers evaluating tools for their company.

OAuth Options That Work

The GitHub-First Approach

For developer tools, GitHub OAuth should be your primary option. Here's why:

  1. Identity verification built-in - Active GitHub accounts have commit history, repos, and social proof
  2. Scope familiarity - Developers understand GitHub's permission model
  3. Profile data - You get username, email, and can infer experience level from public activity
  4. Trust signal - GitHub is where developers already live

Good implementation (Vercel):

  • Single "Continue with GitHub" button dominates the page
  • Email option available but secondary
  • No password creation required
  • Immediate redirect to dashboard after OAuth

Bad implementation:

  • GitHub, Google, Twitter, LinkedIn, Email, and "Sign up with phone" all given equal prominence
  • Requires email verification even after GitHub OAuth
  • Asks for additional profile information before showing dashboard

OAuth Option Hierarchy

Prioritize based on your audience:

AudiencePrimarySecondaryAvoid
Open source developersGitHubEmailGoogle Workspace
Startup developersGitHubGoogleEnterprise SSO
Enterprise developersSSO/SAMLGoogle WorkspaceSocial logins
Data scientistsGitHubGoogleTwitter
Mobile developersGoogleGitHubFacebook

Google OAuth Considerations

Google OAuth works well when:

  • Your tool integrates with Google Cloud services
  • You're targeting Android developers
  • Your audience includes non-technical stakeholders (product managers, designers)

Google OAuth fails when:

  • Developers use personal Gmail but need to sign up with work identity
  • Your tool has no Google ecosystem integration
  • You require Google Workspace-specific scopes

Email Signup: When It Makes Sense

Email+password signup should exist but not dominate. It serves:

  • Developers in enterprise environments that block OAuth
  • Privacy-conscious developers who limit third-party access
  • Situations where GitHub/Google accounts don't reflect professional identity

If you support email signup:

  • Allow signup with just email—send magic link, don't require password creation
  • Never require email verification before showing the dashboard
  • Offer "Set password later" for developers who prefer magic links

Reducing Form Fields

The Zero-Field Ideal

The best signup has zero custom fields. Everything you need comes from OAuth:

  • Name (from OAuth profile)
  • Email (from OAuth profile)
  • Username/handle (from GitHub username)
  • Avatar (from OAuth profile)

When You Must Ask Questions

If you genuinely need information, defer it:

Bad: Blocking signup

Create Account
- Email
- Password
- Company Name (required)
- Role (required)
- Team Size (required)
- How did you hear about us? (required)
[Create Account]

Good: Progressive collection

Continue with GitHub
[Immediate dashboard access]

[Later, contextually in dashboard]
"To customize your experience, what are you building?"
[ ] API/Backend
[ ] Web app
[ ] Mobile app
[ ] Data pipeline
[Skip for now]

Field Elimination Checklist

For each field you want to add, answer:

  • Can we infer this from OAuth profile data?
  • Can we infer this from behavior after signup?
  • Can we ask this later when context makes it relevant?
  • What decision does this field enable that can't wait?
  • What's the conversion cost of this field?

Research suggests each additional required field reduces conversion by 5-10%.

API Key Generation UX

Immediate Key Generation

Developers sign up to write code. Show them an API key immediately.

Good implementation (Stripe):

  1. OAuth complete
  2. Dashboard shows test API keys immediately
  3. Keys are visible and copyable without extra clicks
  4. "Reveal" pattern for production keys, not test keys

Bad implementation:

  1. OAuth complete
  2. "Welcome! Complete your profile to get started"
  3. Profile form required
  4. "Create your first project" wizard
  5. Project settings page
  6. "Generate API key" button
  7. Finally see a key

Key Display Best Practices

Your API Key
sk_test_xxxxxxxxxxxxxxxxxxxx  [Copy]

[Show in cURL example] [Show in SDK example]
  • Show key in monospace font
  • Include one-click copy button
  • Show key in context (code example)
  • Test keys visible by default
  • Production keys behind "reveal" click
  • Never require downloading keys to a file

Multiple Keys and Key Management

Wait until developers need this. First-time signup should show one key.

Introduce key management when:

  • Developer creates a second project
  • Developer invites team members
  • Developer asks about key rotation

Onboarding Personalization

Use-Case Based Paths

Ask one question, then customize the experience:

Question (shown post-signup, skippable): "What are you building?"

  • Integrate with an existing app
  • Build something new
  • Evaluate for my team
  • Just exploring

Path customization:

SelectionDashboard emphasisFirst CTADocs default
Integrate existingSDKs and integrations"Install SDK"Integration guides
Build newQuickstart tutorial"Start tutorial"Getting started
Evaluate for teamPricing and features"Book demo"Use cases
Just exploringInteractive playground"Try playground"API reference

Framework/Language Detection

If GitHub OAuth is used, check public repos for language patterns:

Primary language: Python (45% of repos)
Also uses: JavaScript (30%), Go (15%)

→ Show Python SDK first in docs
→ Default code examples to Python
→ Suggest Python quickstart

Behavioral Personalization

After signup, track and adapt:

BehaviorAdaptation
Copies cURL exampleShow more cURL, less SDK
Views pricing page earlySurface free tier limits in dashboard
Creates multiple projectsSuggest team features
Frequent docs visitsAdd "Stuck?" help widget

Progressive Profiling

What to Collect and When

Signup (OAuth only):

  • Name, email, avatar (from OAuth)

First session (optional, in-context):

  • Primary use case (one click)
  • Preferred language (inferred or one click)

After first API call:

  • Company name (for enterprise features)
  • Team size (for collaboration features)

After hitting free tier limits:

  • Phone number (for billing)
  • Billing address (for invoicing)

After upgrade:

  • Full company profile (for account management)
  • Industry/vertical (for case studies)

Making Progressive Profiling Feel Natural

Bad: Random popup

[Popup after 3 days]
Help us serve you better!
Company: ___
Role: ___
Team size: ___
How did you hear about us: ___

Good: Contextual ask

[When developer invites first team member]
To set up your team workspace, what should we call it?
Company/Team name: ___

[When developer hits rate limit]
To increase your rate limit, we need to verify your account:
Phone: ___

Measuring Signup Conversion

Primary Metrics

Signup start rate

  • Visitors who click "Sign up" or "Get started"
  • Benchmark: 5-15% of landing page visitors

Signup completion rate

  • Users who complete OAuth or form submission
  • Benchmark: 70-90% of signup starts (for OAuth)
  • Benchmark: 30-50% of signup starts (for forms)

Time to signup

  • Seconds from signup click to dashboard
  • Benchmark: <30 seconds for OAuth, <60 seconds for forms

Activation Metrics (Post-Signup)

API key copy rate

  • Users who copy their API key
  • Benchmark: 60-80% within first session

First API call rate

  • Users who make at least one API call
  • Benchmark: 30-50% within first 24 hours

Time to first API call

  • Minutes from signup to first API call
  • Benchmark: <10 minutes for well-designed onboarding

Funnel Analysis

Track the complete funnel:

Landing page visitors: 10,000
├── Clicked signup: 1,000 (10%)
├── Completed signup: 800 (80% of clicks)
├── Copied API key: 600 (75% of signups)
├── First API call: 300 (50% of key copies)
└── Second day return: 150 (50% of first call)

Identify where developers drop off and why:

  • OAuth permission screen abandonment
  • Email verification delays
  • Confused by dashboard
  • Can't find API key
  • First API call failed

A/B Testing Priorities

Test in this order (highest impact first):

  1. Number of OAuth options shown
  2. Form field count
  3. Email verification timing
  4. API key placement on dashboard
  5. Default quickstart language
  6. Welcome email timing

Examples from Real Developer Tools

Excellent Signup: Vercel

  1. "Continue with GitHub" dominates
  2. OAuth completes in one click
  3. Immediate dashboard with import options
  4. No questions asked
  5. First deploy possible within 60 seconds

Excellent Signup: Stripe

  1. Email-based but minimal
  2. No email verification before dashboard
  3. Test API keys visible immediately
  4. Guided setup optional
  5. Clear test vs production modes

Poor Signup: [Common Patterns to Avoid]

  • "Complete your profile" blocking dashboard access
  • Email verification required before seeing anything
  • Required company name and team size
  • Mandatory phone verification
  • "Create your first project" wizard that can't be skipped
  • API keys hidden behind multiple navigation clicks

Tools

Analytics and Testing

  • Amplitude/Mixpanel - Funnel analysis and cohort tracking
  • LaunchDarkly/Split - A/B testing OAuth flows
  • FullStory/LogRocket - Session replay for signup debugging
  • Customer.io/Intercom - Onboarding email sequences

Authentication Providers

  • Auth0 - Full-featured but adds complexity
  • Clerk - Developer-focused, good defaults
  • WorkOS - Enterprise SSO when you need it
  • Supabase Auth - Simple, open source option
  • Firebase Auth - Good for mobile-first

API Key Management

  • Unkey - API key management as a service
  • Custom - Most developer tools build their own

Related Skills

  • /devmarketing-skills/skills/developer-onboarding - What happens after signup
  • /devmarketing-skills/skills/developer-audience-context - Understanding who's signing up
  • /devmarketing-skills/skills/free-tier-strategy - What they're signing up for

GitHub リポジトリ

jonathimer/devmarketing-skills
パス: skills/developer-signup-flow
0

関連スキル

content-collections

メタ

このスキルは、Content Collections(Markdown/MDXファイルを型安全なデータコレクションに変換するTypeScriptファーストのツール)の本番環境でテストされた設定を提供します。Zodバリデーションによる型安全性を実現し、ブログ、ドキュメントサイト、コンテンツ重視のVite + Reactアプリケーション構築時にご利用ください。Viteプラグインの設定、MDXコンパイルから、デプロイ最適化、スキーマバリデーションまで、すべてを網羅しています。

スキルを見る

polymarket

メタ

このスキルは、開発者がPolymarket予測市場プラットフォームを活用したアプリケーション構築を可能にします。API統合による取引や市場データの取得に加え、WebSocketを介したリアルタイムデータストリーミングにより、ライブ取引や市場活動を監視できます。取引戦略の実装や、ライブ市場更新を処理するツールの作成にご利用ください。

スキルを見る

creating-opencode-plugins

メタ

このスキルは、開発者がコマンド、ファイル、LSP操作など25種類以上のイベントタイプにフックするOpenCodeプラグインを作成することを支援します。JavaScript/TypeScriptモジュール向けに、プラグイン構造、イベントAPI仕様、および実装パターンを提供します。カスタムイベント駆動ロジックでOpenCode AIアシスタントのライフサイクルをインターセプト、監視、または拡張する必要がある場合にご利用ください。

スキルを見る

sglang

メタ

SGLangは、高性能なLLMサービングフレームワークであり、RadixAttentionプレフィックスキャッシュを活用したJSON、正規表現、エージェントワークフロー向けの高速で構造化された生成を特長とします。特にプレフィックスが繰り返されるタスクにおいて、大幅に高速な推論を実現し、複雑な構造化出力やマルチターン対話に最適です。制約付きデコードが必要な場合や、広範なプレフィックス共有を伴うアプリケーションを構築する場合は、vLLMなどの代替案ではなくSGLangを選択してください。

スキルを見る