ybuild 助力代理商与自由职业者

适合谁

• 为客户交付软件的自由职业者与工作室
• 想在设计或营销业务之外加上"能造系统"这项能力的代理商
• 任何把"我们帮你造一套系统"作为服务来转售的人

ybuild 如何契合

• 用 AI 一次性构建整套系统——前端和 API 后端
• 把它托管在 ybuild 上，并在客户自己的域名上上线
• 以一个正在运行的应用形式交付；有版本历史和崩溃恢复，就不会有凌晨两点的求助电话
• 持续价值：应用运行在平台上，你永远不必自己去托管客户的网站

一次真实的交付：从需求沟通电话到客户域名上线的应用

周一上午，一位刚又买了两辆货车的水管工，需要一套办法来排班派工、给技师分配任务，并且不再把发票丢在群聊里。你没有给出一份两周的工期估算，而是做了一次 45 分钟的需求沟通电话，把这门生意的名词和动词都记下来：工单、技师、客户、发票——预约工单、派一位技师、标记完成、寄出发票。这份清单就是你的全部需求说明，同时也是你给 ybuild 的提示词。

你用大白话把这套系统描述给 ybuild，它就一次性把整个全栈搭好——数据库表、登录、人们真正会去点的界面，以及背后的 API。到了下午，你手上就有一个能用的应用，而不是一张 Figma 效果图：你可以添加一位真实客户、预约一个真实工单，而且数据会被保存下来。这里没有那种按钮点了没反应的半成品演示。

你把它分享出去，通过屏幕共享带客户走一遍，并在同一次会议里就把不对的地方改好——"技师不该看到价格""给每个工单加一个照片字段""把今天的工单放到首页"。每一处改动都只是又一句话，而不是又一个开发迭代周期。等客户满意了，你把他们的域名指向它，它就上线了，托管在 ybuild 上，地址类似 jobs.theircompany.com。

客户看到的是他们自己的品牌和网址——不是一个测试环境的临时地址，也不是某个搭建工具的 logo。你没有去开服务器、买主机，也没有把一个压缩包丢给某个开发者，然后对方消失、把客户晾在一边。你交付的是一套正在运行的业务系统。这就是全部的活儿，而你用一天就做完了。

定价：别再卖工时，卖正在运行的系统

本能反应是按投入来定价——"我不过花了一个下午，那我就按一个下午来收费。"这正是陷阱。Clutch 的真实评价数据显示，代理商的一个网站项目平均约为 66,500 美元，交付周期约九个月。你的客户不是拿你和你的投入作比较；他们是拿你和那个数字作比较，也拿你和那一堆他们本来要东拼西凑的按月 SaaS 订阅作比较。为结果定价，而不是为投入定价。

价值定价把费用和业务影响挂钩——挽回原本流失的预约、结束表格里的一团乱麻、把前台省下的工时还回来——而不是和钟表挂钩。把服务产品化的代理商更进一步：固定的价格、清晰界定的范围、可复制的交付流程，像卖产品一样卖，而不是给一份量身定制的报价。而这恰恰就是 ybuild 让一个一人公司也能做到的事，因为构建本身不再是那个曾经被用来"所以要按小时收费"的瓶颈。

真正有效的结构分两部分：一笔用于设计、构建并上线系统的启动费——想的是四位数出头，而不是一张按项列明的工时单——再加上一份按月的维护计划。因为应用托管在 ybuild 上、跑在客户自己的域名上，这份按月计划是你实实在在要做的活儿：新增界面、做微调、让整套系统持续在线、保持更新。网站设计的月费保留合约通常在每月两千到一万美元之间；哪怕是一份不起眼的维护计划，也能把一次性的构建变成持续进账的收入。

这是一个不动声色的结构性优势。你不是在转售别人平台上的一个席位，也不会陷在半夜里给一整架客户网站打补丁的自托管泥潭里。系统跑在 ybuild 上，客户关系握在你手里，你交付的每一个应用都会滚成按月收入，而不是在交接那一刻就画上句号。

先造什么，以及代理商常在哪里踩坑

先从一个内部工具入手，而不是一次面向公众的发布。最稳妥的第一单，是客户已经在用表格勉强凑合运行的那套系统——一个小型 CRM、一个工单跟踪器、一套接单加报价的流程。范围是可知的，价值在他们不用再在标签页之间复制粘贴的那一刻就兑现了，而且没有一个营销委员会等着评判首页字体好不好看。拿下这第一套系统，预约网站和客户门户就会成为向一个已经信任你的客户轻松卖出的第二单和第三单。

代理商踩的第一个坑是范围蔓延。"它能不能顺便把工资也算了？"——一个下午就是这样悄悄变成一个季度的。在需求沟通电话里就把名词和动词的清单写下来，让客户亲口确认这就是完整的第一版，把其余的一切都当作下一个付费里程碑。产品化的范围是一条保护你利润的边界，而不是一个需要你道歉的局限。

第二个错误是因为构建很快就压低价格。客户买的是一套能用的系统，以及一个让它持续运行的人——快是你的利润空间，而不是你欠客户的一份折扣。第三个错误是承诺量身手写、你得永远维护下去的代码；交付真正的软件根本不需要它，而它恰恰就是把一门交付生意变成一门凌晨两点救火生意的元凶。

最后一个错误是把交付当成一锤子买卖。如果你一交接就走人，你就把持续收入和客户的信任都白白留在了桌上。因为应用一直托管在 ybuild 上、跑在客户的域名上，你本来就是那个让它保持存活的人——那就为此收费。有版本历史和崩溃恢复，一次糟糕的改动只是一键回滚，而不是一场紧急事故，这让维护计划成为一份从容、高利润的收入，而不是一个你害怕它响起的传呼机。

常见问题

用这种方式交付客户应用，我需要会写代码吗？

不需要。你用大白话把客户的系统描述出来——它要保存哪些记录、需要哪些操作——ybuild 就会把全栈应用搭好：数据库、登录、界面，以及背后的 API。你的工作是需求梳理、品味把关和客户关系，而不是写代码或维护代码。

做好的应用跑在谁的域名和品牌上？

客户的。你把他们自己的域名指向这个应用，它就托管在 ybuild 上上线，于是访客看到的是客户的品牌和网址——而不是一个测试环境的临时地址或某个搭建工具的 logo。你交付的是一个跑在他们域名上的正在运行的产品，而不是一个通往别人平台的链接。

一个我一个下午就做出来的东西，我怎么撑得起一个像样的价格？

你定价的对象是这套能用的系统，以及它会持续运行这件事，而不是你花的工时。客户会拿平均高达数万美元的代理商项目、以及你正在替代的那一堆 SaaS 工具来作参照。为构建收一笔启动费，再为改动和保持在线收一份按月维护计划的费用。

上线之后客户想要改动，会怎么处理？

每一处改动都只是又一句话，而不是又一个开发迭代周期——你把它描述出来，ybuild 就会更新这个正在运行的应用。这正是按月维护计划的核心：你在客户的域名上持续改进这套系统，而版本历史让你可以回滚一次糟糕的改动，而不是去救火。

要是应用出故障，或者客户在凌晨两点打电话来怎么办？

应用托管在 ybuild 上，带有版本历史和崩溃恢复，所以一次糟糕的改动只是一键回滚，而不是一台宕机的服务器。你不需要自己托管客户网站，也不用守着基础设施，而这正是让一批已交付的应用成为一门从容的持续收入生意、而不是一门随叫随到生意的原因。