身份认证：为 SaaS 选择默认方案与例外条件
决定应用如何完成登录、会话、账号恢复与组织入口，不把认证和授权混为一谈。
- 默认方向
- 新 SaaS 默认优先 Clerk；要求数据控制或自托管时选择 Better Auth；企业 SSO 与目录同步迫近时评估 WorkOS。
开发者决策索引
开发者工具选择，不必从一长串产品开始。
Starter Wiki 把任务、默认路线、替代方案和 Starter Stack 放到同一条决策路径里，帮助团队更快做出可解释的技术选择。
任务→默认路线→替代方案→Starter Stack
⌘ K
快速搜索
从这里开始
从决策开始
六个会决定现代产品技术路线的高影响选择。支付：为 SaaS 选择资金流与商业责任
先确定卖方和税务责任，再选择支付处理商、Merchant of Record 或平台支付路线。
- 决策路线
- 常规 SaaS 默认评估 Stripe；希望外包数字商品税务与买方支持时评估 Paddle 或 Creem。
数据库：以托管 PostgreSQL 作为大多数 SaaS 的起点
按数据模型、完整性、恢复与运维要求选择系统记录，而非先选热门后端平台。
- 决策路线
- 多数 SaaS 从托管 PostgreSQL 起步；需要一体化后端时看 Supabase，需要弹性分支工作流时看 Neon。
Hosting：按运行边界选择部署平台
比较框架集成、预览、后台进程、网络、区域和操作责任。
- 决策路线
- 现代 Web 应用通常从 Vercel 起步；需要通用容器服务时评估 Railway 或 Render。
Transactional Email
Choose a provider and operating model for application-triggered email without confusing delivery infrastructure with marketing automation.
- 决策路线
- Start with Resend for a small new web product.
LLM API：通过真实评估集选模型，而不是追随榜单
比较模型质量、工具调用、延迟、价格、数据政策和生命周期风险。
- 决策路线
- 从 OpenAI 或 Anthropic 的一个主模型路线开始；只有明确的可靠性或成本收益时才加入多模型路由。
决策地图
按领域浏览
先选择问题领域，再沿着有边界的顺序前进，而不是浏览平铺的工具目录。身份与访问：从登录到组织权限的决策地图
覆盖认证、授权、企业 SSO、组织模型和用户生命周期，重点是明确身份边界由谁拥有。
数据：选择系统记录、访问方式与运行边界
从数据库、对象存储、检索和缓存开始，把数据形态与运维责任放在同一张决策图里。
基础设施：部署方式、运行时与操作责任
覆盖 Hosting、Serverless、CDN 与容器平台，帮助团队按运行边界而不是品牌声量选择。
支付：先选资金流与责任，再选支付产品
把支付处理、订阅、税务、发票和 Merchant of Record 放在业务模型而非结账组件的层面判断。
消息与通知：把送达、触发和对话分开处理
邮件、通知与实时沟通有不同的可靠性、合规和产品边界。
AI：从模型能力、评估和运行控制开始
覆盖 LLM API、SDK、路由、Agent 与嵌入；关注产品任务的可测质量，而非模型排行榜。
可观测性：让运行问题变成可定位的证据
从错误、性能、日志和产品行为中建立可操作的反馈回路。
安全：把控制点放在真实威胁边界上
覆盖密钥、访问控制、应用保护与合规准备，避免把安全当成勾选清单。
产品能力：把体验需求拆成可验证的技术决策
CMS、后台、搜索和功能管理都应从产品运营方式出发。
开发工作流：让交付速度不以可维护性为代价
覆盖测试、CI/CD、代码质量和开发者效率，重点是缩短可靠反馈周期。
Working combinations
Starter stacks
Five opinionated starting points with explicit product assumptions and replacement boundaries.AI SaaS
Use this Stack when AI is a product capability inside a conventional SaaS system rather than a standalone model-research platform.
- Next.js
- Clerk
- Neon
- Stripe
- AI SDK
Main trade-off
View stack The stack accelerates product delivery but combines identity, database, billing, model, SDK, and hosting dependencies whose usage costs and failure modes must be measured independently.
B2B SaaS
Use this Stack when customer organizations, enterprise federation, provisioning, operational workflows, and account-level billing are core product requirements.
- Next.js
- WorkOS
- PostgreSQL
- Stripe
- Inngest
Main trade-off
View stack The stack covers common enterprise SaaS infrastructure quickly, but the team must own cross-system identity mapping, tenant isolation, authorization, event consistency, enterprise support, and vendor migration.
Content Site
Use this Stack when editors need a managed structured-content system and the product needs a custom Next.js frontend, dedicated search, global delivery, and managed deployment.
- Next.js
- Sanity
- Algolia
- Cloudflare
- Vercel
Main trade-off
View stack The Stack accelerates content operations and delivery but distributes data, indexing, cache, and runtime state across managed providers whose usage, failure, and migration boundaries must be operated deliberately.
Indie SaaS
Use this Stack when a small team wants a conventional SaaS foundation, prefers application-owned authentication, and values outsourcing seller-of-record operations.
- Next.js
- Better Auth
- Turso
- Lemon Squeezy
- Resend
Main trade-off
View stack The stack can be economical and portable at small scale, but the developer assumes more authentication and integration responsibility and must validate runtime compatibility, MoR eligibility, database behavior, and migration paths.
Next.js SaaS
Use this Stack when the product needs application authentication, relational data, card payments, transactional email, and managed web deployment without operating each subsystem.
- Next.js
- Clerk
- Supabase
- Stripe
- Resend
Main trade-off
View stack The stack minimizes initial operations but concentrates product risk across several managed vendors and leaves the application responsible for domain data, authorization, tax scope, and migration planning.
Selected evaluations
Featured evaluations
Tools that recur across important decisions, cover distinct routes, or define a widely misunderstood boundary.Clerk
IdentityClerk is the strongest general default for a new SaaS team that values a short path to polished authentication more than infrastructure ownership.Read evaluation
Better Auth
IdentityChoose Better Auth when owning the authentication runtime, schema, and data is a requirement rather than an implementation preference.Read evaluation
Stripe
Payment processorChoose Stripe when direct payment infrastructure, subscriptions, or platform payments are intentional and the business will own the remaining merchant operations.Read evaluation
Paddle
Merchant of RecordChoose Paddle when its eligibility, seller role, checkout, payout, tax, and contract model fit and reduced merchant operations outweigh lower platform control.Read evaluation
Supabase
Backend platformChoose Supabase when PostgreSQL, Auth, Storage, Realtime, and generated APIs belong in one coherent backend boundary.Read evaluation
Neon
Managed PostgreSQLChoose Neon when PostgreSQL compatibility, database branching, and elastic or suspendable compute align with the development workflow and workload.Read evaluation
Vercel
Managed web platformChoose Vercel when framework-aware deployment, previews, and managed web delivery materially reduce team effort.Read evaluation
Cloudflare
Developer platformChoose Cloudflare when its edge runtime and integrated delivery, security, and data products match the application's execution and locality model.Read evaluation
Resend
Transactional email APIChoose Resend when a compact developer API is the priority and the team can own consent, domain authentication, reputation, suppression, failure handling, and provider concentration.Read evaluation
PostHog
Product engineering and analytics platformChoose PostHog when suite consolidation is intentional and the team can govern identity, event taxonomy, replay capture, flag requests, retention, regions, and separate product meters.Read evaluation
Sentry
Issue-centric application monitoringChoose Sentry when application error triage is the leading job and the team can own SDK, release, source-map or symbol, sampling, and sensitive-data configuration.Read evaluation
AI SDK
AI application SDKChoose AI SDK when a TypeScript product benefits from shared application primitives and its supported provider adapters.Read evaluation
Editorial standard
How recommendations are made
A compact decision process designed to reduce the shortlist without hiding uncertainty.Clear defaults
A practical starting point when one route fits the common case.
Explicit exceptions
The conditions that should move you away from the default.
Verified sources
Important claims trace back to current, reliable documentation.