Best Stack for a Developer Tool
A developer-first stack for building CLIs, APIs, dashboards, and SaaS tools targeting developers. API key auth, usage metering, and a docs-first workflow.
Quick Verdict
Developer tools have a different audience from consumer SaaS: your users are technical, they expect GitHub login, and they'll judge your product by the quality of your API and documentation. This stack is built around those priorities.
The critical risk: API key design. Get it wrong and you'll need users to rotate keys, which causes incidents and erodes trust.
Best For
- Developer tools where GitHub is the expected identity — "Login with GitHub" removes friction
- API products that need key management, rate limiting, and usage-based billing
- Marketing + dashboard + API in one deployment — minimal ops at early stage
- Products with usage-based or seat pricing — Stripe Metered Billing handles this
Avoid If
- Your users don't have GitHub accounts (non-developer audience)
- Your API has streaming, WebSocket, or long-running process requirements
- You need a dedicated API gateway with custom routing logic
- Your usage metering logic is complex — test Stripe Metered Billing thoroughly before committing
Why GitHub OAuth Over Clerk
Developers trust GitHub and already have an account. "Login with GitHub" has zero friction for your target audience. Email/password or magic links feel like you didn't think about your users. Auth.js with the GitHub provider takes 30 minutes and delivers the right first impression.
What It Optimizes For
- Developer-first UX (GitHub login, API key management, good docs)
- One deployment for marketing + dashboard + API
- Usage tracking and metered billing at indie scale
What It Sacrifices
- Non-developer audience
- Long-running API operations
- WebSocket support
Implementation Order
npx create-next-app@latest --typescript --tailwind --app- Configure Auth.js with GitHub provider — working before anything else
- Neon + Drizzle schema:
users,api_keys(store SHA-256 hash, not plaintext),usage_events - API key generation endpoint — return plaintext exactly once, store only the hash
- API key validation middleware — hash the incoming Bearer token, compare against DB
- Upstash Redis rate limiting per key (5 lines of code)
- Usage tracking middleware — one row in
usage_eventsper API request - Stripe Metered Billing — report usage events via the API
- User dashboard: key management, usage chart, billing portal link
Do Now / Do Later
Do now: API key hashing (non-negotiable), rate limiting, usage tracking. Security and billing integrity must be right from day one.
Do later: tRPC typed SDK, OpenAPI spec, dedicated docs site. Build when users are asking for them.
What Breaks First
- API key security — if you ever expose plaintext keys in logs or responses after initial creation, that's a security incident requiring forced rotation.
- Usage metering errors — double-counting API calls or missing events creates incorrect invoices. Log raw usage events in your own table before reporting to Stripe.
- Dashboard auth vs API auth conflation — two separate auth flows. Dashboard: session cookie from GitHub OAuth. API: Bearer token from API key. Never mix middleware for these.
- Documentation as afterthought — devtools live or die on docs quality. Write your API reference before you build features. API shape should be designed from the consumer perspective.
AI Coding Notes
AI tools handle this stack reasonably well, but watch for security-critical generation errors. The most dangerous: AI sometimes generates endpoints that store raw API keys. Always verify the hashing pattern.
Common AI Mistakes
- Storing plaintext API keys — hash with SHA-256 in
crypto.subtle.digest(), never store raw - Missing separation between session auth (dashboard) and Bearer auth (API)
- No rate limiting in generated API handlers
- Usage metering without event deduplication — causes double-billing on retry
Migration Warning
Low for infrastructure — Next.js + Neon + Vercel are portable. The stickiest part is your API design: once developers integrate against your API, endpoint signatures and response shapes are part of your contract. Version from /api/v1/ from day one.
Confidence Score — Why
8/10. Proven for indie developer tools. Deducted 2 points for API key security complexity (must be done right from the start) and Stripe Metered Billing's testing complexity.
Starter Config Files
# My Developer Tool Stack
- Framework: **Next.js 15** (App Router, TypeScript)
- Styling: **Tailwind CSS** + shadcn/ui
- Auth: **Auth.js v5** with GitHub OAuth (dashboard), API keys (public API)
- Database: **Neon** (serverless PostgreSQL)
- ORM: **Drizzle ORM** (@neondatabase/serverless driver)
- Rate limiting: **Upstash Redis**Unlock full config files
Copy, download as .zip, and see all 5 complete files for this stack.