前言
受到同事的鼓励与引导，我也决定开始做自己的出海 SaaS 工具站了。
9 月 8 日，我去银行开通了一张支持海外支付的万事达卡，随后便开始买域名、建项目，直接开搓！
项目开发初版，第一天直接部署上线，并提交到 Google Search Console（GSC） 和 Bing Webmaster Tools，希望两个搜索引擎能够尽快收录我的网站。
买域名
我打算做一个音乐相关的工具站，所以首先需要购买一个合适的域名。
经过对比，我发现同一个域名在 Spaceship 上的价格比 Namecheap 更便宜，于是最终选择了 Spaceship。
关于域名的选择，之前看过一些相关文章，大致总结了几点经验：
- 如果资金充足，优先考虑
.com域名，其次可以考虑.ai和.app。 - 域名尽量简短、易记，最好包含与产品相关的关键词。
- 尽量避免在域名中使用横杠、生僻英文单词或者毫无规律的字母组合。
之所以推荐 .ai 和 .app 这类域名，是因为用户在 Google 搜索时，经常会使用 xxx app、xxx ai 这样的关键词。如果域名与产品定位比较契合，也有利于用户理解和记住你的网站。
不过，由于我暂时不想在域名上投入太多资金，所以最终购买了 musictool.tools，价格大概是每年 6 欧元。
建项目
做出海 SEO 站，我个人更倾向于选择支持服务端渲染（SSR）的技术栈，让搜索引擎能够直接获取相对完整的 HTML 内容，降低内容抓取和索引的难度。
因此，我没有选择纯客户端渲染的 SPA 方案。现在 Next.js 这类对 SEO 比较友好的技术栈越来越流行，也是这个原因。
不过，我个人不太喜欢 Next.js 相对繁重的开发体验，所以最终选择了 TanStack Start（RC）。
项目初始化方面，我依然使用之前分享过的开源项目：
通过它创建好初始脚手架之后，再根据自己的需求指挥 AI 进行修改即可。
下面是我这个项目使用的技术栈。
基于模板创建项目后，我又接入了一些自己需要的基础设施。这些服务基本都有免费额度，对于刚起步的独立开发者来说，完全够用了。
支付方面，我选择了对独立开发者比较友好的 Waffo，也是偶然刷到后才了解到的。
Stripe 的接入通常需要考虑境外主体、银行账户等条件。我目前还没有办理香港银行卡，所以就先接入了 Waffo。
接入过程也比较简单，基本就是按照官方文档，把相关提示词和 Skills 提供给 AI，让它帮忙完成集成。
当然，如果条件允许，还是建议根据自己的业务情况考虑接入 Stripe。
工程与工具链
| 类别 | 技术 | 说明 |
|---|---|---|
| Monorepo | pnpm workspaces + Turborepo | 多包管理、并行构建 |
| 语言 | TypeScript | 全栈类型安全 |
| 代码质量 | Oxlint + Oxfmt | Lint 与格式化 |
| 环境变量 | @t3-oss/env-core + Zod | 服务端 / 客户端 env 校验（packages/env） |
前端与全栈框架
| 类别 | 技术 | 说明 |
|---|---|---|
| 全栈框架 | TanStack Start | SSR、文件路由、Server Functions |
| 路由 | TanStack Router | 类型安全路由、SSR 集成 |
| 构建 | Vite 8 | 开发与生产构建 |
| SSR 运行时 | Nitro | 服务端渲染与 Vercel 部署适配 |
| UI 库 | React | 组件化 UI |
| 样式 | Tailwind CSS v4 | 原子化 CSS |
| 组件库 | shadcn/ui（packages/ui） |
共享 UI primitives |
| 图标 | lucide-react | 统一图标 |
| 主题 | next-themes | 深色模式 |
| 动画 | Motion | 页面与组件动效 |
| 通知 | Sonner | Toast 提示 |
数据与状态
| 类别 | 技术 | 说明 |
|---|---|---|
| 服务端状态 | TanStack Query | 数据请求、缓存、SSR 集成（oRPC 客户端数据） |
| 客户端状态 | Jotai | 跨组件共享的 UI / 会话态（atom + useAtom） |
| 表单 | TanStack Form | 表单状态与校验 |
| API 层 | oRPC | 端到端类型安全 RPC，OpenAPI 集成 |
| ORM | Drizzle | TypeScript-first 数据库访问 |
| 数据库 | PostgreSQL | 主数据存储 |
| 本地数据库 | Docker Compose | 开发环境 PostgreSQL |
认证与国际化
| 类别 | 技术 | 说明 |
|---|---|---|
| 认证 | Better Auth | Session、社交登录、TanStack Start 集成 |
| 登录方式 | Google OAuth | 第三方登录 |
| 国际化 | Paraglide JS + inlang | 编译时 i18n；URL 区分语言（SEO） |
AI
| 类别 | 技术 | 说明 |
|---|---|---|
| AI SDK | Vercel AI SDK | 流式对话、Server Actions |
| 模型 | @ai-sdk/google | Google 模型接入 |
基建服务（第三方 SaaS）
| 服务 | 用途 |
|---|---|
| Vercel | 托管、CI/CD、Serverless 函数 |
| Cloudflare | 域名 DNS |
| Google OAuth | 用户登录 |
| Waffo Pancake | 订阅支付与 Webhook |
| Resend | 事务邮件（用户反馈） |
| Cloudflare R2 | 对象存储（S3 兼容，预签名直传） |
| Google Analytics 4 | 流量统计（仅生产环境） |
| Microsoft Clarity | 用户行为分析、录屏回放（仅生产环境） |
| Sentry | 前后端错误监控（仅生产环境） |
部署上线
其实，现在独立开发一个项目并部署上线，已经没有想象中那么复杂了。
如今的 Serverless 服务已经非常成熟，对于一些轻量级的 SaaS 工具站来说，我们完全可以不用自己购买和维护服务器，也不需要让服务 24 小时保持运行。
直接选择支持弹性扩容的 Serverless 平台即可，例如 Vercel 和 Cloudflare。
我的项目就是直接把 Git 仓库连接到 Vercel，每次 Push 代码之后，Vercel 都会自动构建并部署更新，整个过程基本不需要手动操作。
在目前这个阶段，部署方面也几乎没有产生什么费用。
对象存储方面，还得感谢 CF 大善人提供的 Cloudflare R2，免费额度对于项目初期来说相当够用，基本不需要额外花钱。
目前主要的支出，反而是开发功能时调用的一些第三方 API，需要提前充值少量费用。不过，这部分成本也在可以接受的范围内。
所以，对于独立开发者来说，现在从零开始做一个项目，前期的基础设施成本其实已经很低了。
如果你也想尝试独立开发，完全可以先用这些平台的免费额度把项目跑起来，等真正有了用户和收入，再根据实际情况升级配置。
开发的过程
项目的基础设施搭建大概花了一天时间，接下来就可以正式进入功能开发阶段了。
如果对目标领域不太熟悉，可以先让 AI Research 帮忙做一轮竞品调研，梳理一下同类产品的核心功能和用户需求。
由于我自己对这个领域比较熟悉，也清楚需要开发哪些功能，所以就直接开始 AI Coding 了。
我的开发流程大致分为两个阶段：先做设计稿，再进行需求拆解与功能实现。
设计稿方面，我主要使用 Pen，接入 deepseek 并开启 x6 后，整体设计效率还是很高的。
功能开发方面，我主要使用 Matt 的工作流，整体流程大概是这样的：
grill me：先和 AI 充分讨论需求，明确功能的实现方式。/to-spec：将讨论结果整理成完整的需求规格和总体任务。/to-tickets：把总体任务拆分成多个可以独立执行的子任务。/implement-spec：按照拆分好的任务逐步实现功能。/code-review：让 AI 对代码进行审查，最后自己再检查一遍。
Matt 这套工作流用起来还是蛮舒服的。
在实际开发过程中，我发现一个比较有效的方法，就是把每次遇到的问题和纠正过的错误，都让 AI 记录到项目的 AGENTS.md 中。
这样一来，AI 后续开发时就能参考之前积累的项目规范和经验，减少重复犯错。
不断地发现问题、修正规范、优化执行流程，也算是一种 Loop 吧。
等到项目的 Harness 逐渐配置完善之后，后续开发新功能就会顺畅很多。
特别是对于一些相似的功能，只要需求描述和任务拆解足够清楚，基本就可以放心地让 AI 去搓了。
当然，最后还是得自己检查一下，不能真的完全闭眼。
开发过程中，唯一让我比较头疼的，就是个人能够使用的 Token 实在不太够。
最开始，我开了 Cursor 每月 20 美元的会员，结果大概 4 天就把额度用完了，当时主要使用的还是 Grok。
后来又转到了 Codex 的 20 美元版本，虽然整体体验还可以，但经常需要等待 5 小时的使用额度重置，用起来也不算特别爽。
期间 Tibo 的额度也重置过一次，但依然不太够用。
再后来，Z Code 又送了很多 Token，额度有好几亿，虽然最近爆料出那个大瓜但用都用了。
我逐渐把开发流程改成了：
使用 GPT 5.6 或 GPT 6 讨论需求和总体设计，再将拆解好的具体任务交给 GLM 等国产模型执行。
一开始，我对这种方案其实也不太放心，总觉得复杂一些的功能还是得交给更强的模型来写。
但实际尝试之后发现，如果前期的方案设计足够清楚，任务也拆解得足够细，GLM 这类国产模型同样能够完成不少实际开发工作。
尤其是一些边界明确、实现路径清晰的功能，执行效果已经能够满足我的需求。
后来，Z Code 的额度也用完了，我就又开了 Command Code 的 10 美元套餐，主要使用里面的 DeepSeek 4.1 Flash。
目前体验下来，国产模型里我个人用得比较顺手的还是 GLM 和 DeepSeek。
虽然它们有时候会出现「雷霆大思考」，在一些简单问题上思考很久，但整体代码能力还是可以的。
这里也分享一个个人经验：思考程度可以先调到「高」，没有特别复杂的任务时，没必要一直开「极高」。
对于独立开发者来说，我觉得没有必要让最贵的模型承担所有工作。
可以让能力更强的模型负责需求分析、方案设计和任务拆解，再交给成本相对较低的模型执行具体任务。
这样既能够控制 Token 成本，也能提高整体开发效率。
结语
这篇文章暂时就写这么多，主要还是想简单记录一下自己从零开始做出海 SaaS 工具站的过程，希望能给同样准备尝试独立开发的朋友提供一些参考。
最近我也在继续学习 SEO 相关的知识。
之前我对 SEO 的理解其实比较浅，以为做好语义化标签、标题和页面结构，就已经差不多了。
真正开始做出海工具站之后，才发现 SEO 还有很多值得深入研究的内容。
比如使用 SEMrush 进行关键词调研、分析搜索量和关键词难度、规划网站内容结构，以及围绕核心关键词和长尾关键词持续优化页面等。
这些工作的最终目的，就是提高网站在搜索引擎中的曝光量。
当用户搜索与你的产品相关的问题时，希望自己的网站能够尽可能出现在搜索结果的靠前位置，吸引用户点击进入，并进一步完成注册、使用甚至付费转化。
不过，这方面我也还在学习和摸索，目前只是刚刚入门。
后续如果有新的实践经验和收获，再继续跟大家分享。