PaxLee
PaxLee学无止境
返回列表
合伙人闹掰之后:分家复盘
小团队合伙人冲突创业复盘分家框架团队管理

合伙人闹掰之后:分家复盘

发布于 2026年7月17日9 min read

从两个合伙人走向分家,我总结了一套可执行的清算、切割与重建框架。不扯感情,只讲步骤。

合伙人闹掰之后:分家复盘

两年前,我和一个朋友合伙做了个生成器 App。我负责产品与运营,他负责技术实现。我们见面不多,但远程配合默契,产品上线后直接爆火了。

然后崩了。

原因是什么至今我也不是很明白

那段时间我一边恢复服务,一边想:如果当初有更清晰的退出机制,是不是能体面一点?这篇文章就是我事后整理的“分家行动框架”,希望给同样在合伙路上挣扎的独立开发者一点参考。


第一层:清算——把「我们的」变成「你的」和「我的」

闹掰之后第一件事不是追责,而是明确账目。感情已经破了,账目不能再烂。

1.1 静态资产清单

列出所有共同资产,按类型分类:

类别示例项目归属判断依据
代码仓库GitHub / GitLab 私有库谁写的?是否使用了对方的第三方服务 API Key?
域名与服务器阿里云 / AWS 账号谁付费?注册在谁名下?
App Store / 应用商店账号Apple Developer / Google Play归属法人还是个人?
设计素材与品牌Logo、UI 文件、商标设计师谁雇的?
用户数据邮箱、设备 ID、购买记录法律上属于公司还是个人?
收入与支出付费订阅、广告收入是否存在未分配利润?

示例:我们的 App 代码是我一个人写的,但使用了合伙人购买的 Firebase 服务。清算时,他要求我将所有代码从他账号下的 Firebase 项目解绑。我花了两周迁移到自己的 Firestore 实例,期间 App 不可用。

1.2 动态价值评估

静态资产好清,动态价值难算。特别是用户量、品牌认知、未来的收入预期。我的做法是:只算已发生成本 + 合理利润,不算未来收益。

  • 已发生成本:服务器费用、设计外包费用、App Store 年费、API 调用费用。
  • 合理利润:如果有过收入,按贡献比例分配。如果没有,就按投入时间折价补偿。

这样双方都能接受。如果一方非要算“未来价值”,那就只能找第三方估值,费钱费力。


第二层:切割——让分开之后的系统还能独立运行

分割资产只是第一步,更重要的是确保分开后双方能继续各自的事。

2.1 代码与基础设施切割

核心原则:你的代码你可以带走,但不能破坏我的。

  • 把公共仓库分叉(fork),各自保留完整提交历史。
  • 从对方拥有所有权的服务(如数据库、CDN、支付网关)中完全解绑。
  • 删除共同使用的 API Key,换为自己的。
  • 域名不能共享,协商归一方,另一方重新注册类似域名(如果不想放弃品牌)。
// 示例:从 Firebase 项目迁移到自己的项目
// 1. 在 Firebase 控制台创建新项目
// 2. 导出旧 Firestore 数据(建议用 gcloud 命令行)
// gcloud firestore export gs://my-bucket/backup
// 3. 在新项目中导入数据
// gcloud firestore import gs://my-bucket/backup
// 4. 更新客户端配置
const firebaseConfig = {
  apiKey: "YOUR_NEW_API_KEY",
  authDomain: "your-new-project.firebaseapp.com",
  projectId: "your-new-project"
};

2.2 用户与品牌切割

  • 发一封正式的“通知邮件”给核心用户(如果双方同意)。
  • App 内公告:提示 App 所有权变更,用户数据迁移情况。
  • 社交媒体与官网:交替声明或静默移除对方信息。

这一步最难的是情绪管理。不要公开撕逼,不要曝光内部细节。用户不在乎你们谁对谁错,他们只关心 App 还能不能用。


第三层:重建——用一堵墙代替一张桌子

分开之后,最忌讳的是还想着“以前要是怎样就好了”。我的做法是立刻启动新产品线或新功能,把注意力转移到创造上。

  • 重新规划技术架构,避免再次与合伙人绑定。比如我后来把关键服务从第三方托管改为自己承包小型 VPS,减少单点依赖。
  • 写一份《合伙人分家行动清单》,贴在文档里,下一次合作直接拿出来谈。

下面是我现在每次合作前都会过一遍的清单——看似繁琐,但节省了后续无数吵架时间。


合伙人分家行动清单(可执行版)

合作前(预防)

  • 签署书面协议,明确股份、分工、退出条件。
  • 约定争议仲裁方式:谁调解?谁拍板?是技术占优还是业务占优?
  • 资产归属白纸黑字:代码、域名、账号、数据。
  • 建立“分手条款”:一方退出时,回购价格计算方法(比如按照投入成本或最近 6 个月净利润的 3 倍等固定公式)。

闹掰时(应对)

  • 立即冻结公共账户和 API Key,防止单方面破坏。
  • 启动静态资产清单与动态价值评估。
  • 双方约定三天冷静期,期间只交换书面提案。
  • 确定一位共同信任的第三方作为见证人或调解人(不要律师,太贵;可以是双方都认可的同行)。

分开后(重建)

  • 24 小时内恢复核心服务(至少让老用户能用)。
  • 用户通知:坦诚、简洁、不带情绪。
  • 技术解耦:确保对方无法再访问你的系统。
  • 心理重建:给自己一星期放空,之后立刻开始新的 mini 项目。

一些不一定对但真切的反思

1. 不要和价值观不同的人合伙。技术能力可以互补,但面对“赚钱 vs 产品”这种根本问题必须一致。我们的分歧表面是功能优先级,本质是对商业模式容忍度的差异。

2. 法律文档比兄弟情谊可靠。花几千块请律师写一份《股东协议》和《退出条款》,比闹掰后花几万打官司划算得多。

3. 分家是创业的必修课。以后再合作,我会把“如何分手”写进第一封邮件。这不冷漠,这是对双方时间的尊重。

4. 别把个人情感和工作关系混在一起。我和那位朋友曾经一起吃过很多顿饭,但合作结束后,现在连朋友圈点赞都没有了。这很遗憾,但也许这才是正常。


最后,如果这篇文章能让你避免一次狼狈的分家,或者在你已经闹掰之后帮上一点忙,那我写它就值了。

PaxLee