PATH 01
小项目先行
选一个边界清晰的业务切口，用真实交付判断能力。项目小到可以承受失败，又真实到能看出水平。
Verify · 风险控制
不用相信我们，验证我们
判断一个合作方靠不靠谱，不需要先相信它的承诺。Mindix 提供三条客户可以自己执行的验证路径：小项目先行、与已实施客户沟通走访、 分期付款加里程碑验收。三条路径都不要求客户预付大额资金，也不要求客户接受“先签约再解释”。
三条验证路径
每条路径都写清：怎么操作、客户要投入什么、能验证什么。选一条你最方便执行的即可。
PATH 02
与已实施客户沟通 / 走访
已付过钱的客户不会配合演戏。我们提供可联系的客户，由你自己提问、自己判断。
PATH 03
分期付款 + 里程碑验收
钱按节点付，每一笔都对应可验收的交付物。做不出来，后面的钱不用付。
付款结构：节点、比例、条件
比例是区间，具体数字在合同中按项目规模确定；但节点结构与验收条件不变。
节点 01 · 签约
20—30%
合同生效、项目启动、团队进场
节点 02 · 阶段
按里程碑
阶段交付物通过验收后支付
节点 03 · 验收
90—95%
整体验收通过后的累计支付比例
节点 04 · 质保
5—10%
质保期满、问题闭环后结清
| 节点 | 触发条件 | 客户拿到什么 | 比例 |
|---|---|---|---|
| 签约 | 范围、里程碑、验收标准书面确认 | 项目计划、架构初稿、团队名单 | 20%—30% |
| 阶段 | 阶段交付物通过双方评审 | 可运行的功能、评审记录 | 按里程碑 |
| 验收 | 整体验收标准逐条通过 | 上线系统、验收报告、移交文档 | 累计 90%—95% |
| 质保 | 质保期内问题闭环 | 问题清单闭环记录 | 5%—10% |
比例区间为通常做法，不构成对具体项目的报价承诺；最终以书面合同为准。
案例与走访通道
自有案例需客户书面授权后才能公开。未获授权的项目，我们提供走访而不是编一个故事。
关于案例的说明：目前官网公开的多为行业公开案例（如 Etsy、Enterpret、qubIT），用来说明“团队规模不等于交付上限”，不是 Mindix 自有客户案例。Mindix 自有交付记录在取得客户授权后逐步公开；在此之前，我们提供走访通道。
预约架构诊断 / 申请走访
填写基本信息，我们会在 1—2 个工作日内回复，先判断适不适合，再约时间。
常见质疑，给结构性回答
不给情绪化保证。每个质疑都对应一个机制，客户可以自己检查机制是否存在。
小公司跑了怎么办？
付款结构把风险摊开：签约只付 20%—30%，后续按里程碑支付，不做大额预付；核心交付物与文档在项目过程中持续移交，不等到最后一次性交付。
合同层面约定质保责任与尾款条件（5%—10% 质保后结清）。如果仍然担心，可以先做一个小项目，把单次风险控制在可承受范围内。
分包出问题，谁负责？
Mindix 负责。分包是 Mindix 的内部机制，对客户不构成责任外移。客户只面对 Mindix 一个合同对象，不需要向分包方追责，也不需要协调多方界定责任。
支撑这一点的是架构控制权与验收标准：分包方不能改架构，也不能自证合格。
效果不达标怎么处理？
先看验收标准是否被违反。标准在项目启动时写定，验收时逐条对照，不临时解释。未达标的，由 Mindix 在合同约定范围内承担补救责任：补做、替换方案或按合同约定处理，具体方式在合同中写明。
如果问题源于客户侧关键配合缺失（业务负责人不参与、决策长期不拍板），我们会在过程中书面预警并记录，这类延期不计入 Mindix 的交付责任。
能不能先给一个固定总价？
不建议，也不符合我们的报价逻辑。范围、层数、现有系统状况都会显著影响工作量，未诊断先报价，只能靠加大预留来覆盖风险，对客户并不划算。
我们的做法是先做架构诊断，给出范围、里程碑与报价逻辑，再形成书面报价。诊断本身不绑定后续合作。