用 Rust 做垂直 SaaS：我在家政 CRM 里做的 MVP 取舍

技术栈：Rust + Leptos + Axum + PostgreSQL
项目代号：Pico-CRM（Housekeeping Edition）
核心思路：不做大而全，先把最值钱的业务主线跑通。

---

一、为什么是家政 CRM，而不是“通用 CRM”？

在家政/到家服务这类业务里，常见的问题不是没数据，而是数据太散、流程太碎：

• 客户信息散落在微信聊天、Excel、纸质记录里
• 订单信息靠人工事后补录，环节断点多
• 派工、排班大量依赖群消息同步，极易出错
• 售后一旦追溯，需求、预约、订单、服务记录往往连不起来

这些问题不致命，但极其消耗运营精力。每天重复发生，却长期缺乏系统承载。

所以 Pico-CRM 的定位从一开始就不是“另一个 CRM 系统”，而是：

优先打通客户到履约的核心闭环，而不是堆功能。

---

二、MVP 只做一条线：客户 → 预约 → 订单 → 排班 → 完工

在 MVP 阶段，我刻意把范围压到最窄，只跑一条业务主线：

1. 客户管理
2. 服务目录
3. 需求/预约单
4. 订单管理
5. 排班管理
6. 商户看板（运营视角）
7. 管理员平台统计（平台视角）

这个顺序不是随便排的，背后逻辑很明确：
先保证每天都在重复发生的动作能被系统承接，再做“锦上添花”的功能。

---

三、为什么用 Rust 全家桶？

技术选型上，我这次特别看重一件事：减少上下文切换成本。

项目整体是：

• Leptos：基于 Rust 的全栈 Web 框架，SSR + Hydration 兼顾首屏与交互
• Axum：轻量、高性能的异步 Web 后端
• PostgreSQL：成熟稳定，适合 CRM 这类强结构化业务数据
• 前后端共享类型定义，接口对齐成本极低

这套组合的好处不是“炫技”，而是：
在个人/小团队开发场景，维护效率远比技术新鲜感重要。

---

四、多租户设计：为什么先“做轻”？

早期我评估过多租户常见方案，比如 每商户独立 schema。
但 MVP 阶段，这在运维、升级、查询上都显得偏重。

当前采用的是：

单库共享表 + merchant_id 逻辑隔离

直接好处有四点：

1. 商户开通路径极短
2. 迁移、版本升级更可控
3. 跨商户统计、分析更容易
4. 排查问题时链路更清晰

等业务规模真正上来，再考虑物理隔离也完全来得及。
MVP 阶段，正确比完美更重要。

---

五、后台最容易踩的坑：不是功能少，而是角色边界不清

Pico-CRM 很早就在系统里明确定义了三个角色：

• admin（平台管理员）
• merchant operator（商户运营）
• worker（服务人员）

为什么这么早就做角色边界？
因为大量后台系统的“看起来是 bug 的问题”，
本质都是权限模型不清晰造成的越权或数据可见性错乱。

经验教训就是一句话：

角色边界定义得越早，后期返工就越少。

---

六、看板先做“每天都会看”的数据

商户看板，MVP 版本优先放这些指标：

• 新增客户
• 需求/预约数量
• 订单数量
• 已完成订单
• 待办事项

不先做“很高级但低频打开”的图表。
原因很简单：对于一线运营人员，高频可用 >> 功能丰富。

---

七、做垂直 SaaS，我当前最深的体感

做得越久，越觉得：

垂直 SaaS 最重要的，不是系统看起来多复杂，而是有没有把业务里最值钱的主线做顺。

真正产生价值的，往往不是“功能数量”，
而是“流程是否连续、关键动作是否被系统正确承接”。

---

八、后续计划

Pico-CRM 目前还在推进中，接下来会继续完善：

• 商户侧运营能力（例如服务人员管理、绩效统计雏形）
• 平台统计能力
• 权限模型进一步细化

如果你也在做家政、到家服务，或者本地生活类 SaaS，欢迎一起交流。
你也可以在评论区留下关键词：CRM。