外勤协同 SaaS MVP
把内部外勤派单工具产品化：多租户、角色权限与基础订阅计费一次做对，先卖得出去再谈厚平台。
背景
团队已有单租户内部系统，客户开始询问“能不能我们公司也用一套”。
若继续复制部署，运维与定制会把团队拖死；若直接做大而全平台，又错过销售窗口。
创始人需要在一个销售季内拿出可演示、可签约的多租户版本。
约束
- 必须多租户数据隔离，不能“一个库大家看”
- 首期计费只做席位月订 + 手工开票对接，不做复杂用量计量
- 保留一条客户专属扩展点，但不能分叉成多套代码
真正的难点
产品化的陷阱是把内部特例全做成开关。既要抽出稳定内核（组织、任务、现场回传、权限），又要克制配置项数量，否则销售演示都讲不完。
关键取舍
租户隔离优先于功能堆叠
先完成租户、成员、角色、审计日志，再迁移业务模块。没有隔离与审计，无法对企业客户签约。
配置项白名单制
每个模块只允许少量租户级配置。特例走“扩展脚本/webhook”，禁止为单客改主干分支。
MVP 成功标准写成签约指标
验收不只是功能清单，还包括：完成 3 次完整销售演示路径、支撑 2 家付费试点租户、出一份实施手册。
怎么做的
重做多租户账户与权限；任务派发、现场照片/表单回传、基础报表迁移到新内核。
管理后台支持订阅状态、席位与操作审计；实施侧提供标准初始化清单。
为销售提供演示租户与脚本；上线后按试点反馈排迭代，而不是继续堆内部想要的功能。
可核对的结果
16 周内可对外演示签约销售路径从注册到派单回传可完整走通
2 家付费试点租户落地数据隔离与权限模型通过客户 IT 评审
单客定制分叉被刹住特例走 webhook，主干保持单一版本
实施周期可预期标准租户初始化从“项目制”变成“清单制”
复盘
- 内部工具转 SaaS，第一约束是隔离、权限与计费，不是更多业务按钮。
- 把“销售能讲清楚”当作产品约束，能逼出更干净的信息架构。
- 成功标准要含试点签约，否则 MVP 容易做成另一场内部重构。
技术栈
Next.jsNode.jsPostgreSQL对象存储Stripe/国内支付对接预留