用 Rust 做垂直 SaaS：我在家政 CRM 里做的 MVP 取舍
这段时间我在做一个项目：Pico-CRM（Housekeeping Edition）。 它不是通用 CRM，而是专注在家政/到家服务场景的轻量 CRM。 技术栈：Rust + Leptos + Axum + PostgreSQL。
很多人做 SaaS，一上来就想“平台化”“大而全”。 但我这次反过来：先把最值钱的业务主线跑通，再谈扩展能力。
一、为什么是家政 CRM，而不是“通用 CRM”？
在家政/到家服务这类业务里，常见问题不是没数据，而是数据太散：
- 客户信息散在微信、表格、聊天记录
- 订单靠人工补录，流程断点多
- 派工和排班大量依赖群消息同步
- 售后追溯时，需求 → 预约 → 订单 → 服务记录经常断链
所以我做 Pico-CRM 的目标很明确： 先打通客户到履约的核心闭环，而不是堆功能。
二、MVP 只做一条线：客户 → 预约 → 订单 → 排班 → 完工
当前阶段，我优先做这些模块：
- 客户管理
- 服务目录
- 需求/预约单
- 订单管理
- 排班管理
- 商户看板（运营视角）
- 管理员平台统计（平台视角）
这个顺序背后的逻辑是： 先保证每天都在发生的动作能被系统承接，再做“锦上添花”。
三、技术栈为什么选 Rust 全家桶？
我这次比较看重一件事：技术栈统一，减少上下文切换成本。
- Leptos：SSR + Hydration，前端交互和首屏兼顾
- Axum：服务端 API 与业务编排
- PostgreSQL：稳定、成熟，适合 CRM 这类结构化业务数据
- 前后端共享类型，减少接口对齐成本
这套组合的好处不是“炫技”，而是： 在小团队/独立开发场景下，维护效率更高。
四、多租户我为什么先“做轻”？
一开始我也评估过常见方案：每个商户独立 schema。 但对 MVP 来说，这个方案在运维和演进上都偏重。
我当前选择是：
- 单库共享表
- 通过
merchant_id做逻辑隔离
这个选择的现实收益非常直接：
- 商户开通路径更短
- 迁移和版本升级更可控
- 跨商户统计更容易做
- 出问题时排查链路更清晰
等业务规模上来，再考虑更重的物理隔离方案也不迟。
MVP 阶段，正确比完美更重要。
五、后台系统最容易踩坑的点：不是功能少，而是角色边界不清
在 Pico-CRM 里，我会明确三类角色：
adminmerchant operatorworker
为什么这么早就做角色边界？ 因为后台系统后期很多“看起来是 bug 的问题”，本质都是权限模型不清导致的。
我的经验是： 角色边界早定义，能少掉很多返工。
六、看板先做“每天会看”的数据
商户看板我优先放的是这些指标：
- 新增客户
- 需求/预约数量
- 订单数量
- 已完成订单
- 待办事项
我刻意不先做“很高级但低频打开”的功能。 因为对于一线运营来说，高频可用 > 功能丰富。
七、做垂直 SaaS，我当前最强的体感
越来越觉得，垂直 SaaS 最重要的不是系统看起来多复杂，而是：
有没有把业务里最值钱的主线做顺。
很多时候，真正产生价值的不是“功能数量”，而是“流程是否连续”。
八、后续会继续做什么？
Pico-CRM 还在持续推进，后面会继续完善：
- 商户侧运营能力
- 平台统计能力
- 权限模型细化
如果你也在做家政、到家服务，或者本地生活类 SaaS，欢迎交流。
你也可以评论区留一个关键词：CRM。
标签建议
#Rust #Leptos #Axum #PostgreSQL #CRM #SaaS #家政行业 #到家服务 #垂直SaaS #独立开发
