去年下半年我做了一个叫“家里教”的家教接单小程序。它活的时间不长，但整个过程让我把产品从想法推到上线，再眼睁睁看着它停掉，反而想清楚了很多只看文章学不会的东西。
我其实还是有些失落的，但归根结底是自己做得不够好，所以用这篇文章去记录：当时怎么想的、中间踩了什么坑、如果再来一次会怎么做。
一、这件事到底值不值得做
做这个小程序的起因很简单：身边不少同学想找家教兼职，但通过中介要被抽成，在群里发广告又没什么回应。家长那边也不好找人，要么担心信息不靠谱，要么嫌沟通成本高。
我花了大概一周时间，在几个大学生兼职群和家长群里发了一份问卷，最后收回了 200 多份有效回答。
关于问卷，为了量化分析 N=200 份样本，我们采用李克特五点量表 + 权重赋值法的评价体系，最后的数据结论如下：
教员端：超过 70% 的人最在意“能不能快速接到单”，对平台抽成的敏感度反而排第二。
家长端：排第一的顾虑是“不知道这个老师靠不靠谱”，其次是“约面试太麻烦”。
这两条信息后来成了我定义 MVP 功能的基础。
教员端接单诉求分布
家长端选择平台的关键因素
拿到数据之后，我用 Agent 辅助跑了一轮竞品分析，把市面上几个主流家教平台拆了一遍，提炼了它们在审核、匹配、抽佣三个维度的做法，然后输出了两份用户画像卡片。
做完这一步，产品定位就清楚了：做一个轻量的、以“快速匹配”为核心、优先解决信任和效率问题的工具，而不是大又全的平台。
二、把想法变成一张能看懂的图
定好方向之后，我习惯先把业务跑通再写代码。所以在 ProcessOn 上画了完整的业务流程图和功能结构图。
图看起来挺复杂，但如果只看核心链路，其实就是三条线：
1. 教员注册 → 提交资质 → 管理员审核 → 进入接单池
2. 家长发单 → 系统推送给符合条件的教员 → 教员接单
3. 交易完成后双方互评 → 订单归档
整张图里我最花时间琢磨的是审核节点。家教场景下，信任是前置条件，所以审核不能做成事后补救的环节，必须卡在教员进入接单池之前。下面这张图里用红色标出的就是这条关键路径。
三、要砍掉什么，才是最难抉择的
当时只有我一个人在写前后端，时间精力都有限，如果按完整的想法做，至少需要两个月。但委托方在后面缩短了DDL交付期限，从两个月变成了一个月。
天塌了。所以我不得不做减法。我做的决策是：第一阶段只上线教员端和管理后台，家长端暂时用人工沟通替代。
为什么这么选？
教员是供给侧。没有足够的、可接单的教员，家长来了也留不住。
管理员后台是审核心脏，没有它整个业务跑不起来。
家长端的复杂交互可以先绕过，可以用传统的微信群和私聊替代，小程序作为查询平台运营。
这个决策帮我把开发周期从预计的两个月压缩到了三周左右。
四、原型图制作中的感想
很多人觉得画原型就是把页面搭出来、把跳转连上。我做完这版才明白，画原型最花时间的其实是异常流和兜底逻辑。
举个例子：教员申请入驻时，如果上传的证件不清晰怎么办？接单之后临时有事想取消怎么办？家长发布的需求一直没人接，系统要不要自动下架？
这些问题 UI 图上根本看不出来，但产品没想清楚的话，开发一上手就会出问题。
以下是一些原型图的展示：
五、上线之后发生了什么
小程序跑起来之后，前前后后有 120 多个教员注册，完成了50+单交易。数据不大，但足够验证几个假设：
教员端接单意愿很强，问题在于家长端的持续性需求没跟上。
审核机制确实挡住了几个信息不完整、冒充92的人，说明当时把审核做重是对的。
人工辅助家长发单的模式不可持续，我一个人的精力根本应付不了咨询量。
最后停掉的原因也简单：服务器运营成本太高，因为独立开发的缘故，运维、安全等功能都是我来勘误和负责，委托方只提供了一部分的测试反馈，后面学业压力上来之后没时间维护，加上家长端没做起来，接单量始终上不去，继续空转我觉得没有意义，就暂时下线了。
六、如果再来一次，我会怎么做
现在回头看，有三个判断是需要调整的：
第一，MVP 的范围可以再小一点。
当时觉得教员端和管理后台已经是“最小”了，但其实连统计看板、消息通知这些都可以再往后放。功能越少，上线越快，反馈来得越早。
第二，家长端不能完全靠人工。
虽然省了开发时间，但运营成本直接爆了。哪怕做一个最简单的需求发布表单，也比纯人工可持续得多。
第三，上线前就该想好怎么收场。
做这个项目的时候满脑子都是“先跑起来再说”，完全没考虑运维怎么办，也没想过如果跑不起来该怎么体面地关掉。现在觉得，一个有始有终的产品设计，应该包括从出生到下线的完整生命周期。
---
这个小程序现在已经停了，但这段经历留下来的东西比代码本身值钱得多。后面我参与 WERTA 灾情分析工具的时候，很多关于需求取舍和项目节奏的判断，都是从这个项目里长出来的。
感谢看完这篇有点长的复盘。如果你也在做自己的 side project，希望这些踩过的坑能帮你少走一点弯路。