第七篇：开始收钱 — 从免费工具到商业 SaaS

July 2, 2026

进入信号：客户主动问「你们怎么收费？」——他准备好给钱了，不是你在追着问。

本篇解决的问题：什么时候该收费？怎么定价？收费了要做什么技术准备（权限、计费、安全）？怎么处理第一个付费客户的定制需求？

---

从「能不能用」到「能收多少钱」

G 发来那条消息后，你意识到时机到了。之前一直免费让客户用，是为了降低试用门槛、快速收集反馈。现在产品方向确认了、代码可维护了、客户也主动问价格了。

但你从来没给 SaaS 产品定过价。怎么定？

---

定价的第一次：别想着一步到位

第一步：搞清楚客户现在花多少钱解决这个问题

你问 G：「你们现在怎么解决对账问题？大概花多少钱？」

G 算了一笔账：

• 每周对账花财务 4 小时 × 时薪 ¥80 = ¥320/周 = ¥1,280/月
• 销售确认差异花约 2 小时/周 = ¥640/月
• 合计每月人力成本约 ¥1,920

你的工具帮他把 ¥1,920 降到约 ¥400（还剩一些需要手动确认的差异）。每个月帮他省了 ¥1,500。

第二步：定价在他省的钱的 10%–30%

定价的铁律：你的价格必须远小于客户省的钱，但他能一眼算出来这个账。

• 10%：¥150/月 → 客户算一下就知道划算，毫不犹豫
• 20%：¥300/月 → 需要想一下，但大概率会买
• 30%+: ¥600+/月 → 需要走审批，决策变复杂

你的第一次定价：¥199/月（约省钱的 13%），包含：

• 3 个财务账号
• 无限制对账笔数
• 飞书 + 企业微信通知
• 标准匹配规则

定价的心理学原则

• 不要只有一个价格：给客户对比项。免费版（50 笔/月）→ 标准版 ¥199/月 → 专业版 ¥499/月（高级匹配规则 + API）。客户会倾向于选中档。
• 年付打 8 折：¥199/月 → ¥1,910/年（相当于 ¥159/月）。锁定客户一年，给自己稳定的现金流。
• 第一个付费客户可以打折：G 是第一个，给他 ¥99/月 的「早鸟价」。他的反馈价值远超这 ¥100 的折扣。

---

技术准备：收费之前必须做好的三件事

免费期间有些事可以糊弄。但一旦收了客户的钱，有些底线必须守住。

1. 权限系统：分清谁能看什么、谁能做什么

以前「管理员」只是个字符串标签，实际没做任何权限控制。现在必须有真正的 RBAC。

model Role {
  id          String       @id @default(cuid())
  name        String       // admin | manager | member | viewer
  permissions Permission[] // 这个角色有哪些权限
}

model Permission {
  id     String @id @default(cuid())
  action String // "reconcile:run" | "reconcile:approve" | "report:export" | "team:manage"
}

model User {
  // ...
  roleId String
  role   Role   @relation(fields: [roleId], references: [id])
}

前端条件渲染 + 后端 API 守卫双保险：

// 后端 API 守卫
export async function requirePermission(req: Request, action: string) {
  const user = await requireAuth(req);
  if (!user.role.permissions.some(p => p.action === action)) {
    throw new ForbiddenError('你没有此操作的权限');
  }
  return user;
}

// 前端条件渲染
{user.can('reconcile:approve') && <ApproveButton />}

注意：永远不要只靠前端隐藏按钮来做权限控制。 API 必须有权限校验——因为任何人打开 DevTools 都能看到和调用你的 API。

2. 计费集成：接了 Stripe 才知道坑在哪

你去 Stripe 注册了账号，接入了订阅。

// app/api/billing/webhook/route.ts
export async function POST(req: Request) {
  const sig = req.headers.get('stripe-signature')!;
  const event = stripe.webhooks.constructEvent(body, sig, webhookSecret);
  
  switch (event.type) {
    case 'checkout.session.completed':
      // 客户付费成功 → 激活订阅
      await subscriptionService.activate(event.data.object);
      break;
    case 'customer.subscription.deleted':
      // 客户取消订阅 → 降级到免费版
      await subscriptionService.downgrade(event.data.object);
      break;
    case 'invoice.payment_failed':
      // 扣款失败 → 发邮件提醒更新支付方式
      await notificationService.notifyPaymentFailed(event.data.object);
      break;
  }
  
  return new Response(null, { status: 200 });
}

踩坑记录：

• Webhook 必须幂等：Stripe 可能因网络重试发多次同一个事件，你的处理逻辑必须能重复执行不出错
• 扣款失败不是 Bug，是常态：客户信用卡过期、余额不足太常见了。友好的重试策略：失败后 3 天发邮件提醒 → 7 天再试 → 14 天降级到免费版
• 测试很重要：Stripe 有 test mode，先把所有状态流转测一遍再上线

如果是中国市场：用支付宝/微信支付接入。方案选型上，LemonSqueezy 或 Paddle 可以处理国际支付和税务，省去自己对接支付宝的麻烦。

3. 数据安全底线

收钱之前还免费，客户对你的安全期望是「应该没问题吧」。收钱之后，客户对你的安全期望变成了「出了问题你要负责」。

最少要做的事：

// CORS 从 * 收紧到具体域名
const corsOptions = {
  origin: ['https://app.yourapp.com'],
  credentials: true,
};

// 强制 HTTPS
// Vercel/Cloudflare 默认已开，但自己部署的话要确认

// JWT Token 管理
// - Access Token 15 分钟过期
// - Refresh Token 7 天过期
// - Token 存在 httpOnly cookie 中（不是 localStorage——防 XSS）

// 密码最少 8 位
// 敏感操作二次确认（删除团队数据要输入团队名确认）
// 生产数据库不对外暴露端口

这些不是高阶安全——这些都是最低标准。做了不会加分，但不做迟早出事故。

---

第一个定制需求：怎么处理？

G 付了钱之后，需求立刻升级了。

「我们公司有一个特殊的审批流程：差异金额 > 5000 要财务经理批，> 50000 要 CFO 批。能不能支持？」

这是典型的「第一个付费客户定制需求」。你的选择：

方案 A：给他定制，代码写死在他 team_id 下

• 快，几个小时就能上线。但以后每个客户都来一套定制，一年后代码就是 if-else 地狱。

方案 B：设计成通用功能，所有客户都能用

• 做成「自定义审批规则」——每个客户自己设阈值和审批人。开发成本是 A 的 3 倍，但 10 个客户里 8 个都可能用到。

你的选择：方案 B，但和 G 商量。

你：「G，审批规则我做成一个通用功能，所有客户都能自定义。这样你需要 2 周上线，但如果只是给你单独做，3 天就能上。你选哪个？」

G：「2 周可以等。做成通用的是对的，以后我们公司业务变化了我们自己也能改。」

这个对话很关键——让客户参与决策，他不仅不着急，还会觉得你在帮他长远考虑。

---

什么时候进入下一阶段？

你的月收入从 ¥0 变成了 ¥199 × 3 = ¥597/月。很少，但这是第一笔真正的 SaaS 收入——不是定制开发的劳务费，是产品本身的订阅收入。

但新的问题开始出现：

• 你每天手动部署 2~3 次。git push → SSH → git pull → npm run build → pm2 restart，每次 5 分钟。一天光部署就花 20 分钟。
• 上周五晚上你出门了，G 发消息说系统 502。你在手机上没法修，等到回家才重启服务。G 等了一个半小时。
• 你开始想：这个部署流程能不能自动化？能不能让客户 24 小时都能用到你的服务？

进入下一阶段的信号：以下任一——

• 你开始觉得「部署」本身在浪费时间
• 出过一次生产事故，客户在等你修复，但你不在电脑前

这是第八篇的内容——上云。

---

本篇总结

做了什么	关键决策
定价 ¥199/月（省钱的 13%）	基于客户现有成本定价
RBAC 权限系统	角色 + 权限 + API 守卫
Stripe 计费集成 + Webhook	订阅、扣款失败、降级流程
CORS/HTTPS/JWT 安全底线	收费后必须做
审批规则做成通用功能	不硬编码定制需求

当前系统形态： 有 RBAC、有计费、有安全底线的可商用单体应用。3 个付费客户，MRR ¥597。数据隔离通过 Prisma 中间件保障。

本月账单：$0（Supabase 免费层 500MB 即将不够）。收入 ¥597/月。

如果是 ToC： 这个阶段定价更低（$9.99/月），但客户量级不同——你需要 100 个付费用户才能达到同样的收入。ToC 的挑战是获客，ToB 的挑战是每个客户的定制和服务。

---

下一步

部署开始浪费你的时间——进入第八篇：上云，CI/CD 与自动化部署。

---

为什么要聊股权？

因为合伙人分道扬镳的第一大原因不是「产品做失败了」，是「当初分钱没分清楚」。SaaS 创业很少一个人走完全程，总要有联合创始人、早期员工、天使投资人。股权怎么分，决定了你的公司能走多远。

本篇用最直白的方式讲清楚：占股百分比到底意味着什么、怎么分、最常见的坑是什么。

---

一、股权到底是什么？

股权不是「这张饼有多大」——是你在这张饼里能切走多少。

公司值 ¥10,000,000，你占 60% → 你的股份值 ¥6,000,000。公司值 ¥0，你占 90% → 你的股份还是 ¥0。

所以股权的核心是两件事：「你拿多少」和「你能不能让这张饼变大」。

你占	意味着
100%	你一个人说了算。赚 100 万你拿 100 万。但公司做不大的概率极高——因为你一天只有 24 小时，你的能力有上限
67%+	绝对控制权。重大事项（修改章程、增资、合并、解散）你一个人就能决定
51%+	相对控制权。日常经营决策（选董事、定薪酬、年度预算）你说了算
34%+	否决权。重大事项你可以一票否决——你阻止不了别人推动，但你能阻止别人胡来
10%+	提议召开临时股东会的权利。有话语权的基础门槛
低于10%	被动投资者。对公司决策几乎没有实质影响力。只能选择「跟着走」或「卖掉走人」

所以「占股多少」不是越少越好、也不是越多越好。而是在「能掌控方向」和「给团队足够激励」之间找一个平衡。

---

二、典型的股权分配模型

场景一：两个人合伙

最经典的坑：50-50。

「我俩是兄弟，一人一半。」——半年后因为一个决策意见不合，谁也说服不了谁，公司停滞。

正确做法：必须有一个人占 > 50%。 不是不信任对方，是公司需要一个人负最终责任。哪怕 51-49 也行。多出来的 2% 不是你的优越感——是「当意见无法统一时，由我来拍板，但我对结果负责」。

参考比例：

• 两个人都是全职、技能互补：60-40 到 70-30 之间
• 一个人出核心技术/idea + 全职，一个人晚加入 6 个月：75-25
• 一个人只出钱不出力：最多 20%，剩下的 80% 给出力的人

---

场景二：三个人合伙

角色	参考比例	理由
CEO / 产品负责人	45-55%	承担最大责任、最长时间投入
CTO / 技术负责人	20-30%	核心技术的壁垒
COO / 运营或销售负责人	15-25%	把产品卖出去的能力

三个人最怕的两种分法：

❌ 均分 33-33-33。三个人意见不合时永远没有最终决定者。有一家公司在 33-33-33 下运营了 2 年，最后因为「要不要做海外市场」扯了 3 个月，错过窗口期。

❌ CEO 只拿 35%，另外两个人各拿 32.5%。 CEO 没有绝对控制权，重大事项需要拉拢一个人。这会让 CEO 花大量时间在「内部政治」上，而不是做产品。

✅ CEO 拿 50-55%，给自己留出绝对控制权的空间。剩下的按贡献分。

---

场景三：有早期员工/顾问

不要给早期员工股权——给他们期权。

股份 vs 期权的区别：

	股份	期权
含义	你已经是股东了，现在就有所有权	你有权利在未来以约定价格购买股份
什么时候给	联合创始人、投入巨大的早期成员	早期员工、顾问、兼职贡献者
典型比例	5-30%	0.1-2%
风险	拿了就走是对公司最大的伤害	不干了就自动失效

早期员工的期权怎么定？

• 第 1 号员工（第 5 个加入的人）：0.5-2%
• 第 2-5 号员工：0.2-1%
• 第 10 号以后：0.05-0.2%
• 顾问（每月花 5-10 小时）：0.1-0.5%

---

三、Vesting（分期兑现）——股权分配里最重要也最容易被忽略的词

Vesting 的意思是：你的股份不是一次性全给你，是分 4 年慢慢给你。

为什么需要 Vesting？因为如果没有它，你的联合创始人拿到 30% 股份后，干了 3 个月说「太累了不想干了」——他的 30% 还在，你赶不走他，也不能收回。你一个人扛下所有工作，他躺在 30% 上等你把公司做大。

标准 Vesting 条款：

总授予期：4 年
Cliff：1 年（干满 1 年才能拿到第一笔，即 25%）
之后：按月兑现（每干满 1 个月拿到 1/48）

举例：你给 CTO 20% 股份，4 年 vesting，1 年 cliff。

• 他干到第 6 个月走人：0%（没到 cliff，什么都没有）
• 他干到第 13 个月走人：5%（刚到 cliff，拿到 25%，即 20% × 25% = 5%）
• 他干到第 25 个月走人：约 10.4%（25 个月 × 1/48 × 20%）
• 他干满 4 年：20%

Vesting 对创始人自己也适用。 你自己拿 60%，也应该 4 年 vesting。这不是不自信——这是向团队证明「我也是长期绑定的」。

---

四、融资稀释——每融一轮，你的股份就少一点

很多创始人犯的最大的数学错误：「我现在 60%，融完资还是 60%。」

不。每融一次资，你的股份都会被稀释。

阶段	创始人	天使投资人	A 轮投资人	期权池	总估值
创立	100%	—	—	—	¥0
天使轮（融 ¥500K，估值 ¥2.5M）	80%	20%	—	—	¥2.5M
A 轮（融 ¥5M，估值 ¥20M）	60%	15%	20%	5%（预留）	¥20M

你从 100% 变成了 60%。但 60% × ¥20M = ¥12M，远大于 100% × ¥0。

这个认知是第一道坎。太多创始人因为「不舍得稀释」而拒绝融资，最后死于现金流断裂。被稀释不可怕，饼不变大才可怕。

---

五、五个最常见的坑

坑一：没签书面协议

「我们认识十年了，不用签。」

这句话的结局有 90% 的概率是吵架。认识十年 = 你觉得他应该理解你 = 他同样觉得你应该理解他 = 矛盾爆发时会比陌生人更伤人。

永远签书面协议，哪怕只有一页纸，写明：谁占多少、怎么 vesting、怎么退出。

坑二：退出机制没说清楚

联合创始人要退出，他的股份怎么处理？

写清楚：「公司有权以最近一轮估值的 80% 回购其已归属股份。未归属部分自动作废。」

不写清楚的结果：你公司估值 ¥5M，他说他的 20% 值 ¥1M。你说只值 ¥300K。谈了半年没谈拢。期间投资人不敢进来——因为股权结构不稳定。

坑三：按出钱分股

「我出了 ¥100K，他出了 ¥50K。所以我 67%，他 33%。」

这个分法的问题是：你忽略了「出力的价值」。

如果你们两个都全职，但一个人出了更多钱——给投资部分额外的股份（比如多 5-10%），剩余部分按出力分配。不要把「出钱」和「出力」混在一个比例里。

坑四：没有期权池预留

你创立时把 100% 分光了。后来想招一个厉害的 VP，发现没有股份可以给他。

建议：创立时就预留 10-15% 的期权池。 这部分从创始人份额里出，放在一个「期权池」里，由创始人代持。以后每招一个核心员工，从池子里分。

坑五：投资人要了太多

天使投资人：「我投 ¥1M，要 40%。」

你迫切需要这笔钱。但你算一下：天使轮就被拿走 40%，后面 A 轮再被拿走 25%，你自己连 40% 都不剩。你的动力会断崖式下降。

融资铁律：任何一轮被稀释不要超过 25%。 天使轮控制在 15-20%，A 轮 20-25%。给自己后面的融资留余地。

---

六、一个极简的股权分配速查表

情景	创始人/CEO	联合创始人	早期员工（期权）	天使投资人	期权池预留
Solo 创始人，无团队	100%	—	—	—	—
2 个联合创始人，全职	55-65%	35-45%	—	—	—
2 个联合创始人 + 1 个兼职技术	50-55%	25-30%	3-5%（期权）	—	10%
2 个联合创始人 + 天使轮 ¥500K	45-50%	20-25%	5%	15-20%	10%
3 个联合创始人 + 天使轮	35-45%	各 15-20%	5%	15-20%	10%

注意：这些是参考值，具体数字取决于每个人的实际投入（时间、资金、技术壁垒、行业资源）。没有「标准答案」，但有不合理的答案——比如 50-50 和 33-33-33。

---

七、一个自测清单

分股权之前，问自己五个问题：

1. 如果联合创始人明天退出，公司能继续运营吗？ ——如果不，你的股权分配给他的太多了
2. 如果公司 3 年后值 ¥50M，你手上的股份值 ¥25M，你对这个数字满意吗？ ——如果不，你现在就要调整比例
3. 有没有人拿到了股份但还没开始出力？ ——如果有，他应该有 vesting。没到 cliff 之前一分都不给
4. 如果有人只出钱不出力，他的股份是多少？ ——超过 20% 就太多了
5. 你们的协议里写清楚退出机制了吗？ ——如果没写，今天写完。写在一张纸上也算

---

最后的话

股权分配最怕的不是算错数字。是在感情最好的时候，不谈最伤感情的事。

创业第一天谈股权，你们还是兄弟。创业一年后再谈股权，你们可能已经是仇人了。

在签股权协议之前，先把这篇文章发给你的合伙人看。两个人一起看完，一起聊：「你觉得这个比例公平吗？」「如果有一天你要走，你希望怎么处理？」

这些对话越早发生，你们的合作越长久。

---

其他索引：本系列第七篇《开始收钱》讲了 SaaS 定价策略和商业模式，第九篇《合伙人分润》讲了硬件团队的分钱方式。本篇是这些文章的底层框架——在分钱之前，先搞清楚公司是怎么被「拥有」的。