说得出"这个不做"
需求评审时如果判断某功能投入产出不成立，我们会明确说不做，并说明理由。宁可少签一单，不做注定烂尾的功能。
我们是谁
从"接外包"到
"做交付"
过去几年，我们接过大量别人做了一半的项目。烂尾的原因几乎都一样：需求没写清、进度不透明、交付没有验收标准。
所以我们把公司改小、把流程改重。团队里没有专职售前，第一个跟你聊的人就是后面负责交付的人。报价单上每一行都能对应到一段可以验收的功能。
这套做法让我们做不快大项目，但很少做砸项目。
现在的样子
全职交付工程师18 人
平均从业年限7.4 年
同时在建项目上限12 个
项目按期交付率91%
上线后 90 天留存96%
我们刻意控制同时在建的项目数量。超过 12 个，交付质量就会开始掉——这是被验证过的。
一路走来
三次转向，每次都砍掉一半业务
2019
从定制开发起步
做企业官网、小程序、内部管理系统。什么单都接，什么技术都试。
2021
第一次砍：只做有数据流的系统
放弃纯展示类项目。开始专注"设备 → 数据 → 决策"这条链路，第一个工业客户上线。
2023
第二次砍：不接纯人力外包
不再按人头计价。改为按里程碑与验收结果结算，开始承担交付责任。
2024
第三次砍：AI 只做能验收的部分
拒绝"AI 概念验证"类项目。每个 AI 能力必须绑定一个可量化的业务指标，否则不做。
2026
交付网络 3.0
把需求、交付、运维三段流程标准化，每个项目公开进度快照，客户随时可查。
做事方式
四条不太讨喜的规矩
这些规矩让我们丢过单，但也让我们很少有客户在验收时翻脸。
报价单能逐行对应功能
没有"技术咨询费""综合服务费"这类模糊条目。每一行钱都能指到一个能演示的东西。
进度不靠汇报，靠环境
每两周给你一个能打开的地址。看不到东西的"完成 80%"，我们不写进周报。
交接必须能独立运行
交付包含仓库、部署脚本、接口文档与一次实操演练。拿走后你的团队能自己改，才算交付完成。
0
团队成立年份
0
全职交付工程师
0
项目按期交付率
0
上线 90 天留存