developer-signup-flow – skill Lập trình cho agent AI

Developer Signup Flow

When to Use

Use this skill when you need design frictionless signup experiences for developers including GitHub OAuth, API key generation, and onboarding personalization. Trigger phrases: developer signup, dev registration, OAuth flow, API key onboarding, reduce signup friction, developer authentication, signup conversion,...

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. Account authentication - OAuth authenticates a GitHub account; public activity does not verify a person, employer or business entitlement

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:

| Audience | Primary | Secondary | Avoid |

|----------|---------|-----------|-------|

| Open source developers | GitHub | Email | Google Workspace |

| Startup developers | GitHub | Google | Enterprise SSO |

| Enterprise developers | SSO/SAML | Google Workspace | Social logins |

| Data scientists | GitHub | Google | Twitter |

| Mobile developers | Google | GitHub | Facebook |

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
• A read-only preview may precede verification; verify ownership before account linking, secrets, paid resources or sensitive workspace access
• 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?

Measure field impact in your own funnel; no universal per-field conversion penalty is established here.

API Key Generation UX

Immediate Key Generation

Developers sign up to write code. Offer a scoped sandbox key after identity and abuse controls; test credentials remain secrets even when they cannot move real money.

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)
• Reveal newly created sandbox keys only in an authenticated session; exclude all keys from analytics, replay, logs and URLs; support rotation and revocation
• 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:

| Selection | Dashboard emphasis | First CTA | Docs default |

|-----------|-------------------|-----------|--------------|

| Integrate existing | SDKs and integrations | "Install SDK" | Integration guides |

| Build new | Quickstart tutorial | "Start tutorial" | Getting started |

| Evaluate for team | Pricing and features | "Book demo" | Use cases |

| Just exploring | Interactive playground | "Try playground" | API reference |

Framework/Language Detection

With disclosed, optional personalization and least-privilege scopes, public repository language patterns may suggest a preference; let developers override it:

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:

| Behavior | Adaptation |

|----------|------------|

| Copies HTTP request | Prefer HTTP examples over SDK-only flow |

| Views pricing page early | Surface free tier limits in dashboard |

| Creates multiple projects | Suggest team features |

| Frequent docs visits | Add "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

… (nội dung đầy đủ có trong gói tải về)