LovisMind

第 01 章

从零到上线：用 AI 做一个能收款的 SaaS

一条完整的 vibe coding 流水线：先补齐前端、后端、数据库、认证、Git、API、环境变量这些基础概念；再按「规划 → 参考图做界面 → 逐功能实现 → 人工自检 → AI 代码审查 → 提交」的循环推进，最后接入数据库、支付、安全扫描、法律页面与自定义域名。

From Zero to a Paid SaaS: The Full Vibe-Coding Loop

A complete pipeline: first the vocabulary (frontend, backend, database, auth, Git, APIs, environment variables), then the loop — plan, build the UI from references, implement one feature at a time, check it yourself, run an AI code review, commit — and finally database, payments, security scanning, legal pages and a custom domain.

首发于 2026.10.16中 / EN
技术教程ai-codingsaasworkflowcode-reviewdeployment
语言
字号
目录
篇内目录

这一篇在讲什么

这门课从一个空文件夹开始，做一个可以收款的 AI 简历生成器——参考的对象是 reszy.ai，一个据作者引用的 Stripe 数据、月收入约 25 万美元的产品。课程不会复刻整个产品，只做核心：用 AI 生成简历内容，以及如何对它收费。

作者反复强调的重点不是最终界面：AI 每次生成的结果都不一样，照抄成品没有意义，要学的是流程。 他把流程总结成一个循环：

  1. 规划项目（新手最常跳过、代价最大的一步）；
  2. 根据规划做界面，必须给参考图；
  3. 把项目拆成功能（认证、仪表盘、数据库……）；
  4. 一次只做一个功能；
  5. 做完先自己点一遍（人工自检）；
  6. 让 AI 做代码审查（因为 AI 一次会改几十上百个文件，人看不过来）；
  7. 有问题就修，功能完成就提交，然后进入下一个功能。

最后一步是部署与域名——但作者故意把部署放在很前面，理由见下文。

时间轴

时间内容
2:44工具选择：Claude、Codex、Cursor、VS Code、Node.js；三种使用 AI 的方式
9:41从零建一个 Next.js 项目，跑起来，第一次改页面
19:47基础概念：前后端、数据库、认证与授权、Git/GitHub、API、环境变量
37:20部署：连接 GitHub，提交即自动重新部署
52:27规划：分析竞品、提取核心功能、plan mode 访谈、生成 PLAN.md
1:10:55界面：Pinterest 参考图、生成素材、假数据搭完整 UI
1:28:42代码审查：创建分支与 PR、CodeRabbit 扫描、一次修完、合并
1:40:26后端：Neon 数据库、认证、.env、生产环境变量与域名
2:01:40支付：Polar 沙盒、产品与 token、webhook 校验、测试卡
2:17:30深度安全扫描与漏洞修复
2:22:08法律页面：服务条款与隐私政策
2:25:29域名：购买、CNAME 配置、生效

先补齐六个概念

作者认为，只会对着 AI 说「给我做个 App」的人，最大的问题不是不会写代码，而是听不懂 AI 在说什么。以下六个概念足够支撑整门课。

前端与后端

  • 前端：你看到并操作的部分——按钮、文字、图片、表单、动画。
  • 后端：你看不到、但让一切运转的逻辑——校验邮箱是否存在、核对密码、发通知、处理支付、保存数据。

两者都有，就叫全栈。

数据库

存放并组织数据的地方。用表、行、列来组织，而不是随便堆。社交应用存帖子和消息，电商存商品和订单，本课存用户与简历。类型有很多，本课用 Postgres。

认证与授权

  • 认证（authentication）：你是谁。邮箱登录、Google 登录、Apple 登录，回答的是身份。
  • 授权（authorization）：你能做什么。普通用户只能买东西，管理员能上架、下架、改价——这是权限。

这两个词经常被混用，区别就在这里。

Git 与 GitHub

  • Git 跑在本地，记录代码的每一次变化，让你能回到之前的版本。每次保存点叫 commit。
  • GitHub 把代码存到网上，用于协作，也用于防止本地丢失（作者举的例子：笔记本掉进海里，项目还在 GitHub 上）。

API 与 API Key

API 让一个应用和另一个服务对话。做支付时，你的应用和 Stripe 之间就隔着这样一个接口；做天气应用时，你的应用和天气服务之间也是。API Key 是应用表明身份的密钥。

环境变量与 .env

环境变量是应用运行需要的值：API key、数据库地址、各种密钥。它们放在 .env 文件里，与代码分开；.env 会被 .gitignore 忽略，不会推到 GitHub——一旦推上去，所有人都能看到你的密钥。

环境搭建

需要三样东西：VS Code、Node.js，以及一个 AI 订阅（作者说 20 美元/月足够起步）。

三种使用 AI 的方式

  1. 终端里：最不推荐给新手，界面不友好；
  2. 桌面应用：很友好，但看不到生成的文件和代码；
  3. VS Code 插件（本课采用）：既能对话，又能看到文件、改代码、跑终端。

第三种方式的好处是「看得见」：即使不懂技术，看着文件结构逐渐长出来，也会慢慢熟悉。

建项目

在桌面建一个空文件夹，拖进 VS Code。然后让 AI 建一个 Next.js 项目：

npx create-next-app@latest .

末尾的点表示「在当前目录生成」。全部选默认即可。生成后：

npm run dev

打开 localhost:3000，能看到默认页面。接着让 AI 改一版：

这个项目现在是 Next.js 的初始模板，没有任何逻辑。
帮我做一个漂亮的落地页，就当我们在做 Instagram 那样的社交应用，
现在只要设计，不要太复杂，我只是测试一下。

页面会实时更新。作者提醒：紫色系、emoji 当图标、到处是同一套组件，基本就是「AI 生成感」的特征，后面会专门解决。

尽早部署：为什么不等做完再上线

大多数教程把部署放在最后。作者反过来，在写任何业务逻辑之前先部署：

建应用和在互联网上真正可访问是两件事。前者跑在你的笔记本上，后者需要部署。

两步部署

  1. 在 GitHub 新建仓库，把本地代码推上去（不知道命令就把 GitHub 给的命令贴给 AI，让它执行）；
  2. 在 Cloudways Velocity 里连接 GitHub、选中仓库、点部署。

平台会自动识别 Next.js，几分钟后给出一个临时域名。这时你已经有可以发给朋友的地址了。

自动部署才是关键

平台监听仓库，每次 commit 都会自动重新部署。于是：

把应用名字改一下，别叫 Momento 了；配色也换掉，
不要紫色和粉色，换成 Spotify 那种绿色。

AI 改完、提交、推送，线上几分钟后就更新。作者把这称为「提交即上线」。

部署失败时，日志会显示在平台上。处理方式不是自己啃日志，而是整段复制给 AI：

我用 Cloudways Velocity 部署，日志如下，失败了，帮我看看。

平台还提供应用监控、日志与部署历史，可以回滚到之前的版本。作者强调：对独立开发者来说，这相当于省掉了半个 DevOps。

规划：让 AI 采访你，而不是替你猜

先从竞品提取核心功能

作者让 AI 分析目标网站，只要核心功能，不要 nice-to-have：

这是一个我很喜欢的 AI 简历生成器 SaaS，我想做一个简化版。
请分析整个网站，列出它有哪些功能，给我一份可以做第一版的核心功能清单。
不要包含锦上添花的功能。另外给我一份定价方案，整理成一个可以直接复制的清单。

得到的六项功能是：登录与简历仪表盘（增删改查）、简历编辑器、AI 内容生成、导出 PDF、额度/升级、定价页。

plan mode 的访谈式提示词

新手最大的错误是直接说「帮我做」，没被说到的细节全靠 AI 猜——比如 Pro 版定 50 还是 10 美元、要不要免费试用。解决办法是让 AI 采访你：

你现在的任务不是写代码或搭脚手架，而是对我即将描述的项目做访谈。分批提问，覆盖每一个细节与决策。

然后把项目描述、核心功能、技术栈一起贴进去：

我想做一个 AI 简历生成器，核心功能如下：……
技术栈：Next.js，已经部署在 Cloudways；后端全部用 Neon，
包括 Postgres、存储和认证。

作者强调：技术栈必须写进规划，否则 AI 可能选一堆你没听过的技术。

plan mode 会分几轮提问，每题有推荐选项。作者的提醒与另一门课一致：不要无脑点推荐，真正要卖的产品要逐条读，因为不同选项会改变产品形态与成本。

PLAN.md 与 AGENTS.md

规划完成后，让它存成文件：

把整份计划详细写进 PLAN.md。

项目里通常有三个说明文件：

文件读者作用
README.md人项目是什么、怎么启动
PLAN.md人和 AI这个项目要做什么、架构与决策
AGENTS.mdAI必须遵守的规则，如「永远用 Tailwind」「每次改动都提交」

AGENTS.md（以前 Claude 专用的 CLAUDE.md 已并入）会在每次会话开始时自动载入上下文。所以「永远用某某技术」这类规则写一次就够，不用每轮重复。

界面：参考图 + 假数据

为什么必须给参考

不给参考，AI 会产出「一眼 AI」的界面：emoji 当图标、到处是同样的卡片、浮夸动画。作者的做法是每次项目都先去 Pinterest 搜 website design（或 mobile app design），挑一张真正喜欢的图存进 design/ 文件夹，然后：

读我的 PLAN.md，理解我要做的产品，然后帮我做落地页。
我附了一张 UI 参考图，请从中获取灵感。
首屏做一个动画；视频参考我也附上了，用 Higgsfield MCP 生成，
可以先出图再让它动起来。

素材怎么来

  • 图片：让 Claude 直接生成，或用 GPT / Gemini 免费生成；
  • 视频：用 Higgsfield 的 MCP（付费，作者每月约 60 美元），在编辑器里直接出图再转视频；
  • 参数建议：视频 1080p、10–12 秒即可，4K 会烧掉大量额度。

作者明确说：第一次生成不满意很正常，继续给参考、继续跟进。他看到很多人两三次没得到好结果就断言「AI 做不出好东西」，问题往往在于参考给得不够、描述不够具体。

先用假数据把整个 UI 搭完

作者的固定做法：在接后端之前，把落地页 + 登录页 + 仪表盘全部用硬编码假数据搭出来。

除了落地页，把用户真正使用的仪表盘也做出来，
包括生成简历等功能。现在只用假数据，不要接认证、数据库或 AI，
全部用硬编码模拟。

好处是能立刻看到产品最终的样子；等界面定稿，再让 AI 把假数据换成真实数据。替换数据源比返工界面便宜得多。

代码审查：人看不过来，就让工具看

界面完成后，AI 一共改了 43 个文件。作者说得很直白：逐行 review 是不可能的，而且越往后文件越多，两三百个改动很常见。

流程是标准的 pull request：

  1. 新建分支（状态栏 → create branch），命名如 ui-design；
  2. 暂存全部改动，让 AI 生成 commit message，提交；
  3. 发布分支，在 GitHub 上创建 pull request；
  4. 让 CodeRabbit 自动审查。

CodeRabbit 会给出：本次提交的摘要、按类别整理的变更（仪表盘 / 账户计费 / 简历编辑 / UI / 后端）、以及按严重程度分级的问题。最有价值的是它为每个问题附带的修复提示词——复制粘贴给 AI 就能改，不用截图或重新描述。

多个问题可以一次性修完：在问题列表上方有「一次修复全部」的提示词，贴给 AI，它改完再提交到同一分支，然后合并 PR、切回主分支同步。

作者对这一步的总结值得记住：未来的工作不是写代码，而是审查代码、保证它的安全。

后端：Neon 一把接完

Neon 提供 Postgres、认证、存储、实时、函数、AI Gateway。建项目时勾选需要的能力，它会生成一段给 AI 的接入说明。

关键是说清「现状 + 目标」：

这个项目现在的数据全是硬编码的假数据，
我想用 Neon 作为整个后端平台，把这些数据换成真实数据。
这是 Neon 给的接入说明。

AI 会自己写 .env、建表、接认证。遇到不确定的控制台界面——比如一堆 URL 不知道该复制哪个——截图发过去问：

这是我在 neon.com 看到的界面，这些值需要复制到代码里吗？
需要的话告诉我，我提供给你。

作者说这套「截图 + 问」的办法，他在上架 App Store 时用了很多次，非常有效。

验证要落到数据库：Google 登录一次、邮箱注册一次，然后去 Neon 的认证面板看新用户是否出现、表里是否真的有数据。

上线前的两件事

  1. 把生产域名加入认证的可信域名（截图问 AI 让它配置即可）；
  2. 把 .env 里的变量逐个加到托管平台的环境变量，并重新部署——否则线上还是旧值。

作者多次强调环境变量要「标为 sensitive」，避免在控制台明文显示。

支付：Polar 与 webhook

支付是作者认为「几乎所有教程都不讲」的部分。他用 Polar（Stripe、Lemon Squeezy 也是同类选项），并强调先用 sandbox 环境测试，不花真钱。

步骤可以全部让 AI 给：

我的应用基本能用了，只差支付。我想用 Polar，但我没用过。
截图是沙盒界面，请给我一步步的操作步骤，不要过度解释。

大致流程：

  1. 在沙盒里新建产品：名称、按月订阅、9 美元；
  2. 复制 product ID；
  3. 在设置 → developers 里创建 access token；
  4. 把 product ID 与 token 写进 .env；
  5. 运行它给的命令获取 webhook secret，终端要保持运行；
  6. 删掉演示用的计费逻辑；
  7. 告诉 AI「四步都做完了」，让它完成接入。

webhook 是什么

作者用一句话解释：某个事件发生时，系统自动发出来的一条消息。

用户付款成功，Polar 会发一条「用户已付款」的事件给你的后端；你的后端据此给这个用户开通权限。

为什么需要 secret？因为不能谁发来的事件都信。如果没有校验，任何人都可以伪造一条「我付款了，请给我权限」。secret 用来确认事件确实来自 Polar——这是安全上的关键一步。

测试与上线

沙盒测试卡：卡号填一长串 42，有效期选未来任意日期，CVC 随便填。付款成功后应跳转到成功页，账户升级、额度到账。

上线时把同样三样东西（product ID、access token、webhook secret）从正式环境（而不是沙盒）取出，加到托管平台的环境变量里。

深度安全扫描

CodeRabbit 的 AI Deep Scan 不只扫描当前 PR，而是整个代码库，包括多年没动过的旧代码，还可以定时执行（例如每周一上午）。

作者为了验证它确实有效，另建了一个仓库，故意植入一批漏洞，然后跑深度扫描：结果是 8 个高危、2 个中危、1 个低危，涵盖 IDOR、授权绕过、XSS、OAuth 配置错误、注入等。

每条发现都能看到具体代码行，可以直接修复、生成工单、忽略，或者分享给 AI 与队友。

为什么必须做这一步：AI 生成代码时不会主动考虑安全，尤其是你自己一边写一边改的时候，几乎不可能逐条检查这类问题。

法律页面

服务条款与隐私政策是上线必需品，无论网站、游戏还是手机应用。作者的做法仍是提示词：

根据我的整个代码库，为我的应用生成服务条款，放在 /terms 页面。

隐私政策同理，放在 /privacy。生成后必须人工替换占位符：法律实体名称、地址、联系方式等，AI 猜不到。最稳妥的做法是把这些真实信息一次性提供给 AI，让它统一替换。

作者提到，他用同一套提示词生成的页面，第一次提交 App Store 就被苹果接受。

域名

  1. 在 Cloudflare（作者推荐，价格较低）买域名，按价格排序挑选；
  2. 回 Cloudways 的项目，进入 domain management，添加 www.你的域名；
  3. Cloudways 会给出一条 CNAME 记录（name 与 host name）；
  4. 到 Cloudflare 的 DNS records 添加两条 CNAME：一条 name 为 @，一条为 www，target 填 Cloudways 给的值；
  5. 关闭代理（选 DNS only），否则证书与解析可能出问题；
  6. 等待生效，几分钟到 24 小时不等。

理解检验

1. 为什么作者把部署放在写业务代码之前，而不是最后？

参考答案：部署一次之后，每次 commit 都会自动重新部署，于是「线上可访问」从项目末尾的一次性动作变成了贯穿全程的反馈回路：每做一个功能，都能立刻在真实地址上看到结果，而不必等到最后才发现环境、域名或构建问题。另一门同主题的课程给出相同做法，并指出本地能跑不等于线上能跑，越早暴露环境差异越省事。

2. 「让 AI 采访你」的规划方式解决了什么问题？

参考答案：直接描述需求时，所有没被说到的细节都由 AI 猜测——Pro 版定价、是否免费试用、功能边界都可能与预期不符。「采访我」把 AI 变成提问者，分批追问每个决策，把隐含假设显式化。作者强调要逐条读问题而不是全选推荐项，因为不同选项会改变产品形态与成本；规划还要写清技术栈，否则 AI 可能选用你没听过的技术。

3. 为什么界面阶段要用硬编码假数据，而不是直接接后端？

参考答案：假数据能让落地页、登录页、仪表盘立刻全部成型，快速验证布局与交互，不受后端进度阻塞；界面定稿后再替换数据来源，改动集中在数据层而不是重做 UI。作者的原话是「先用假数据把整个 UI 搭完，之后让 AI 删掉假数据、接上后端」。

4. CodeRabbit 这类代码审查工具，在 AI 编程流程里承担什么角色？为什么不能靠人工 review？

参考答案：AI 一次会生成几十到几百个文件的改动，人逐行审查既不现实也容易漏。代码审查工具在 PR 上自动扫描，给出摘要、按类别整理的变更、按严重程度分级的问题，并为每个问题附带可直接粘贴给 AI 的修复提示词；深度扫描还能覆盖整个代码库与历史代码。作者据此提出：未来的工作重心从写代码转向审查与保证安全。

5. webhook 的 secret 是做什么用的？如果没有它会怎样？

参考答案：webhook 是事件发生时系统自动发出的消息，例如用户付款后支付平台通知后端「该用户已付款」。secret 用于验证这条消息确实来自支付平台。没有校验，任何人都可以伪造「我付款了」的请求，从而免费获得付费权限。所以后端必须校验签名，而不能相信任意来源的事件。

6. 上线前为什么既要把环境变量加到托管平台，又要重新部署？

参考答案：.env 只在本地生效，托管平台运行的是另一份环境；不把变量加到平台上，线上代码读不到数据库地址、密钥等值，功能会失败或报错。而修改环境变量后，已运行的实例仍持有旧值，必须触发一次新的部署才会重新读取。作者在部署失败、添加密钥后重新部署的环节反复演示了这一点。

与前后内容的关系

这一篇是完整的入门闭环：概念补齐 → 环境 → 部署 → 规划 → 界面 → 代码审查 → 后端 → 支付 → 安全 → 法律 → 域名。

同书的另外两篇可以对照阅读：一篇把流程抽象成五步与三条不能省的原则（版本管理、让 AI 自测、人工验证），适合当作检查清单；另一篇以真实 SaaS 项目展示规划访谈、参考图界面、Neon 后端、Stream 实时通信与 Sentry 自动修复，更侧重「每一步怎么验证」。三篇合起来，正好覆盖「流程骨架」「交付原则」「实战细节」三层。

What this walkthrough covers

It starts from an empty folder and ends with a chargeable AI resume builder — modelled on reszy.ai, which the author cites as a Stripe-verified product doing around $250k a month. The course does not rebuild the whole thing; it keeps the core: generating resume content with AI, and charging for it.

The point is not the finished interface. Every AI run produces a different result, so copying the output is useless — the workflow is what transfers. The loop:

  1. Plan the project — the step beginners skip, and the most expensive one to skip.
  2. Design the UI from the plan, with visual references.
  3. Break the product into features (auth, dashboard, database, …).
  4. Build one feature at a time.
  5. Click through it yourself (manual check).
  6. Run an AI code review — AI touches dozens or hundreds of files at once, and no human can read all of them.
  7. Fix, commit, move to the next feature.

Deployment and domain come last in a normal course, but the author deploys almost first — for a reason explained below.

Timeline

TimeTopic
2:44Tools: Claude, Codex, Cursor, VS Code, Node.js; three ways to use an AI agent
9:41Create a Next.js app, run it, change the page for the first time
19:47Concepts: frontend/backend, database, auth vs authorization, Git/GitHub, API, env vars
37:20Deployment: connect GitHub; every commit redeploys
52:27Planning: analyse a competitor, extract core features, plan-mode interview, PLAN.md
1:10:55UI: Pinterest references, generated assets, the whole app with fake data
1:28:42Code review: branch and PR, CodeRabbit, fix in one prompt, merge
1:40:26Backend: Neon database, auth, .env, production variables and domain
2:01:40Payments: Polar sandbox, product and token, webhook verification, test card
2:17:30Deep security scan and fixes
2:22:08Legal pages: terms of service and privacy policy
2:25:29Domain: buy, configure CNAME, wait for propagation

Six concepts worth twenty minutes

The author's view: people who only say "build me an app" are not blocked by syntax, they are blocked by not understanding what the AI is talking about. Six ideas are enough.

Frontend and backend

  • Frontend: what you see and touch — buttons, text, images, forms, animation.
  • Backend: what you do not see but makes everything work — checking whether an email exists, verifying a password, sending notifications, processing payments, saving data.

An application with both is full-stack.

Database

A place to store and organise data, using tables, rows and columns rather than random piles. A social app stores posts and messages; an e-commerce app stores products and orders; this project stores users and resumes. There are many kinds; this course uses Postgres.

Authentication and authorization

  • Authentication: who you are — email, Google or Apple sign-in.
  • Authorization: what you are allowed to do — a normal user can buy; an admin can add, delete, discount or mark items out of stock.

The words are often confused; the distinction is identity versus permission.

Git and GitHub

  • Git runs locally and records every change, so you can return to an earlier version. Each saved checkpoint is a commit.
  • GitHub stores the code online — for collaboration, and so a lost laptop does not mean a lost project.

API and API key

An API lets one application talk to another service. Implementing payments means your app talks to Stripe through one; a weather app talks to a weather service through one. An API key is the secret that identifies your application when it makes those calls.

Environment variables and .env

Environment variables are the values your app needs to run: API keys, database URLs, secrets. They live in a .env file, separate from the code, and .env is listed in .gitignore so it is never pushed to GitHub — pushing it would expose every secret.

Environment setup

You need VS Code, Node.js, and an AI subscription ($20/month is enough to start).

Three ways to use the agent

  1. In the terminal — least beginner-friendly.
  2. Desktop app — friendly, but you never see the files or code generated.
  3. VS Code extension — the course's choice: chat, see files, edit code, run the terminal in one place.

The third option's advantage is visibility. Even without a technical background, watching the file tree grow builds familiarity.

Create the project

Make an empty folder on the desktop and drag it into VS Code, then ask the agent to scaffold Next.js:

npx create-next-app@latest .

The trailing dot means "generate in the current folder". Accept the defaults, then:

npm run dev

Open localhost:3000 and the default page appears. Then make the first edit:

This is a fresh Next.js template with no logic.
Build me a nice landing page — pretend we are building a social app like Instagram.
Just the design for now, keep it simple; I am only testing.

The page updates live. The author notes the tell-tale signs of an "AI-generated" design: purple palettes, emoji instead of icons, the same components everywhere. That is what the UI section fixes.

Deploy early — why not wait until the end

Most tutorials deploy last. This one deploys before any business logic:

Building an application and making it available on the internet are two different things. The first runs on your laptop; the second needs a deployment.

Two clicks

  1. Create a GitHub repository and push the local code (if unsure of the commands, paste GitHub's snippet into the agent and have it run them).
  2. In Cloudways Velocity, connect GitHub, choose the repository, and deploy.

The platform detects Next.js and returns a temporary URL within minutes — something you can already send to a friend.

Auto-deploy is the real win

The platform watches the repository and redeploys on every commit:

Rename the app — not Momento; change the palette too.
Nothing purple or pink; use a green like Spotify.

The agent edits, commits, pushes; production updates a few minutes later. The author calls this "commit to live".

When a deployment fails, the logs appear in the platform. Do not read them alone — paste them:

I deployed with Cloudways Velocity and it failed. Here are the logs. Help me out.

The platform also provides monitoring, logs and deployment history, so you can roll back to a working version. For a solo developer, the author argues, this replaces a good part of a DevOps role.

Planning: let the AI interview you

Extract core features from a competitor

Ask for the core only:

This is an AI resume builder SaaS I like, and I want a simplified version.
Analyse the whole site, list its features, and give me the core features
I should build for version one. No nice-to-haves.
Also give me a pricing plan as a single list I can copy.

Six features came back: sign-in and a resume dashboard (create, edit, duplicate, delete), a resume editor, AI content generation, PDF export, credits/upgrade, and a pricing page.

The interview prompt

The beginner mistake is saying "build it" and letting the AI guess every detail — the Pro price, whether there is a free trial, which features are in scope. The fix is to make the AI interview you:

Your job right now is not to write code or scaffold. It is to interview me about the project I am about to describe. Ask in batches and cover every detail and decision.

Then paste the description, the core features, and the stack:

I want to build an AI resume builder. Core features: ...
Stack: Next.js, already deployed on Cloudways; the whole backend on Neon,
including Postgres, storage and authentication.

The stack must be stated. Otherwise the AI may pick technologies you have never heard of.

Plan mode asks several rounds of questions, each with a recommended option. The same warning appears as in the other courses: do not blindly accept the recommendations. In a product you intend to sell, each choice changes shape and cost.

PLAN.md and AGENTS.md

Persist the plan:

Write the full plan into PLAN.md.

A project usually ends up with three documentation files:

FileReaderPurpose
README.mdHumansWhat the project is, how to start it
PLAN.mdHumans and AIWhat is being built, architecture and decisions
AGENTS.mdAIRules to always follow, e.g. "always use Tailwind", "commit every change"

AGENTS.md (which absorbed Claude's older CLAUDE.md) is loaded into context at the start of every session, so rules like "always use this stack" are written once, not repeated in every chat.

UI: references, then fake data

Why references are mandatory

Without a reference, the output looks AI-generated: emoji icons, identical cards, flashy animation. The routine is to search Pinterest for website design (or mobile app design), save a screenshot you actually like into a design/ folder, then:

Read my PLAN.md and understand the product, then build the landing page.
I attached a UI reference — get inspired by it.
Animate the hero section; the video reference is attached too.
Use the Higgsfield MCP to generate it: image first, then animate.

Where assets come from

  • Images: Claude, or free generation in GPT / Gemini.
  • Video: Higgsfield's MCP (paid; the author pays about $60/month), generating in the editor.
  • Sensible settings: 1080p, 10–12 seconds. 4K burns credits fast.

The author is explicit: the first generation is rarely right; keep adding references and keep following up. Many people give up after two or three prompts and conclude that AI cannot design — usually the references were too thin.

Build the entire UI on fake data

Before touching the backend, build the landing page, the sign-in page and the dashboard with hardcoded data:

Besides the landing page, build the dashboard users actually use,
including generating resumes. Use fake data only for now;
do not implement auth, database or AI yet — simulate everything with hardcoded data.

The payoff: you see the finished product immediately, and once the design is settled you ask the AI to delete the fake data and connect the real backend. Swapping the data layer is far cheaper than redoing the interface.

Code review: when no human can read the diff

After the UI, the agent changed 43 files. The author is blunt: line-by-line review is impossible, and it only gets worse — two or three hundred changed files is normal.

The flow is a standard pull request:

  1. Create a branch (ui-design) from the status bar.
  2. Stage everything, let the AI write the commit message, commit.
  3. Publish the branch and open a pull request on GitHub.
  4. Let CodeRabbit review it.

CodeRabbit returns a summary, a change stack grouped by area (dashboard, account and billing, resume editing, UI, backend), and issues graded by severity. The most useful part is that every issue ships with a ready-to-paste fix prompt — no screenshots, no re-describing.

Multiple issues can be fixed in one pass: a "fix all" prompt at the top of the findings list goes to the agent, it commits to the same branch, then you merge the PR and sync the main branch.

The author's summary of this step is worth keeping: the future of the job is not writing code, it is reviewing and securing it.

Backend: Neon in one pass

Neon provides Postgres, auth, storage, realtime, functions and an AI gateway. Create a project with the capabilities you need and it produces setup instructions for an agent.

The key is to state present and target together:

All the data in this project is hardcoded fake data right now.
I want to use Neon as the entire backend and replace it with real data.
Here are the instructions Neon gave me.

The agent writes .env, creates tables and wires auth. When a console screen is confusing — a wall of URLs, which one to copy — screenshot it and ask:

This is what I see in neon.com. Do I need to copy any of these values into the code?
If so, tell me and I will provide them.

The author says this screenshot-and-ask habit carried him through publishing an app to the App Store.

Verification happens in the database: sign in with Google once, register with email once, then check Neon's auth panel for the new users and confirm the tables actually contain rows.

Two things before launch

  1. Add the production domain to the auth provider's trusted domains (screenshot it and let the agent configure it).
  2. Copy every .env value into the hosting platform's environment variables and redeploy — otherwise production keeps running on old values.

Mark secrets as sensitive so they are masked in the console.

Payments: Polar and webhooks

Payments are, the author notes, the part almost every tutorial skips. He uses Polar (Stripe and Lemon Squeezy are the alternatives) and starts in sandbox so no real money moves.

The console steps can also come from the agent:

Everything in my app works except payments. I want to use Polar but I have never used it.
The screenshot is the sandbox. Give me the steps in order, in simple terms, without over-explaining.

Roughly:

  1. Create a product in sandbox: name, recurring subscription, $9.
  2. Copy the product ID.
  3. Create an access token under settings → developers.
  4. Put the product ID and token into .env.
  5. Run the command it gives you to obtain the webhook secret; keep that terminal running.
  6. Remove the demo billing logic.
  7. Tell the agent "all four steps are done" and let it finish the integration.

What a webhook is

One sentence: an automated message sent when something happens.

A user pays, Polar sends a "user paid" event to your backend, and your backend grants access.

Why the secret? Because you cannot trust events from anyone. Without verification, anyone could forge "I paid, give me access". The secret proves the event really came from Polar — a security step, not a formality.

Test, then go live

Sandbox test card: a long string of 42s, any future expiry, any CVC. A successful payment should redirect to the success page, upgrade the account and add credits.

For production, take the same three values (product ID, access token, webhook secret) from the live Polar account rather than the sandbox, and add them to the hosting environment variables.

Deep security scan

CodeRabbit's AI Deep Scan looks at the entire codebase, not just the current PR, including code nobody has touched in years, and it can be scheduled (every Monday at 10 a.m., for example).

To prove it works, the author created a separate repository, had the agent plant vulnerabilities, and ran a deep scan: eight high-severity issues, two medium, one low — covering IDOR, authorization bypass, XSS, broken OAuth configuration, injection and more.

Each finding points at the exact line and can be fixed, turned into a ticket, dismissed, or handed to an AI agent or teammate.

Why this step is non-negotiable: AI does not think about security while generating code, and nobody reviewing their own live-coded changes catches IDOR or auth bypass by eye.

Terms of service and a privacy policy are required to launch, whether a website, a game or a mobile app. The method is again a prompt:

Based on my whole codebase, generate terms of service for my app at /terms.

Privacy policy at /privacy, same pattern. Afterwards replace the placeholders by hand: legal entity name, address, contact details. The AI cannot guess them; feed it the real values once and have it substitute them.

The author notes that an App Store submission built with these exact prompts was accepted on the first try.

Domain

  1. Buy a domain at Cloudflare (the author's recommendation; typically cheaper), sorted by price.
  2. In Cloudways, open the project → domain management, add www.yourdomain.
  3. Cloudways returns a CNAME record (name and host name).
  4. In Cloudflare DNS records, add two CNAMEs: one with name @, one with www, both targeting the Cloudways value.
  5. Turn the proxy off (DNS only), or certificates and resolution may misbehave.
  6. Wait — minutes, sometimes up to 24 hours.

Check your understanding

1. Why does the author deploy before writing business logic instead of at the end?

Reference answer: Once deployed, every commit redeploys automatically, so "live on the internet" stops being a one-off step at the end and becomes a feedback loop throughout. Each feature can be seen at the real URL immediately, and environment, domain or build problems surface early instead of at launch. A companion course on the same theme makes the same choice and notes that working locally does not imply working in production — the sooner that gap shows, the cheaper it is.

2. What does the interview-style planning prompt solve?

Reference answer: When you describe requirements directly, every unstated detail is guessed by the AI — the Pro price, whether there is a free trial, which features are in scope. The interview prompt turns the AI into a questioner that asks in batches and makes implicit assumptions explicit. The author stresses reading each question rather than accepting every recommendation, because choices change the product's shape and cost, and stresses stating the stack so the AI does not pick unfamiliar technologies.

3. Why build the UI on hardcoded fake data instead of wiring the backend first?

Reference answer: Fake data fills the landing page, sign-in page and dashboard immediately, letting layout and interaction be validated without waiting on the backend. Once the design is settled, the change is confined to replacing the data source rather than redoing the interface. The author's phrasing: build the whole UI with fake data, then have the AI delete it and connect the backend.

4. What role does a tool like CodeRabbit play in an AI coding workflow, and why can't manual review replace it?

Reference answer: An AI can change dozens to hundreds of files in one pass, which no human can read line by line without missing things. The review tool scans the pull request automatically, returning a summary, a categorised change stack, issues graded by severity, and a ready-to-paste fix prompt per issue; a deep scan additionally covers the whole codebase and legacy code. Hence the author's claim that the job is shifting from writing code to reviewing and securing it.

5. What is the webhook secret for, and what happens without it?

Reference answer: A webhook is an automatic message emitted when an event occurs — for example, the payment provider telling the backend that a user has paid. The secret verifies that the message really came from the provider. Without verification, anyone could forge "I paid" and obtain paid access for free, so the backend must verify the signature instead of trusting arbitrary sources.

6. Why must environment variables be added to the hosting platform and followed by a redeploy?

Reference answer: .env only affects the local machine; production runs with a different environment. Without adding the variables there, the deployed code cannot read the database URL or secrets and the feature fails. And after changing environment variables, the running instance still holds the old values until a new deployment reads them again — which is why the author redeploys after adding keys.

How it connects

This note is the complete beginner loop: concepts → environment → deployment → planning → UI → code review → backend → payments → security → legal → domain.

The other two notes in this book are contrasts. One distils the workflow into five steps and three non-negotiables (version control, letting the AI self-test, manual acceptance), useful as a checklist. The other walks a real SaaS project through interview planning, reference-driven UI, Neon backend, Stream realtime and Sentry's automated fixes, with more emphasis on how each step is verified. Together they cover the skeleton, the principles, and the practical detail.

来源