ybuild 助力代理商與自由工作者

適合誰

• 為客戶交付軟體的自由工作者與工作室
• 想在設計或行銷業務之外加上「能打造系統」這項能力的代理商
• 任何把「我們幫你打造一套系統」當成服務來轉售的人

ybuild 如何契合

• 用 AI 一次把整套系統打造好——前端與 API 後端
• 把它託管在 ybuild 上，並在客戶自己的網域上線
• 以一個正在運行的應用交付；有版本歷史與當機還原，就不會有半夜兩點的求助電話
• 持續價值：應用跑在平台上，你永遠不必自己去架設客戶的網站

一次真實的交付：從需求訪談到客戶網域上線的應用

週一早上，一位剛又買了兩台廂型車的水電師傅，需要一套辦法來排班派工、指派技師，並且不再把發票丟在群組裡。你沒有給出一份兩週的工期估算，而是做了一次 45 分鐘的需求訪談，把這門生意的名詞和動詞都記下來：工單、技師、客戶、發票——預約工單、指派一位技師、標記完成、寄出發票。這份清單就是你的全部需求規格，同時也是你給 ybuild 的提示詞。

你用大白話把這套系統描述給 ybuild，它就一次把整個全端建好——資料庫表格、登入、大家真正會去點的畫面，以及背後的 API。到了下午，你手上就有一個能用的應用，而不是一張 Figma 示意圖：你可以新增一位真實客戶、預約一張真實工單，而且資料會被保存下來。這裡沒有那種按鈕點了沒反應的半成品展示。

你把它分享出去，透過螢幕分享帶客戶走一遍，並在同一次會議裡就把不對的地方改好——「技師不該看到價格」「幫每張工單加一個照片欄位」「把今天的工單放到首頁」。每一處改動都只是又一句話，而不是又一個開發衝刺。等客戶滿意了，你把他們的網域指向它，它就上線了，託管在 ybuild 上，網址類似 jobs.theircompany.com。

客戶看到的是他們自己的品牌和網址——不是一個測試環境的臨時網址，也不是某個建置工具的商標。你沒有去開伺服器、買主機，也沒有把一個壓縮檔丟給某個工程師，然後對方消失、把客戶晾在一旁。你交付的是一套正在運行的營運系統。這就是全部的工作，而你用一天就做完了。

定價：別再賣工時，賣正在運行的系統

本能反應是按投入來定價——「我不過花了一個下午，那我就按一個下午收費。」這正是陷阱。Clutch 的真實評價數據顯示，代理商的一個網站專案平均約為 66,500 美元，交付週期約九個月。你的客戶不是拿你和你的投入相比；他們是拿你和那個數字相比，也拿你和那一堆他們本來得東拼西湊的按月 SaaS 訂閱相比。為結果定價，而不是為投入定價。

價值定價把費用與業務影響掛鉤——挽回原本流失的預約、結束試算表裡的一團亂、把櫃檯省下的工時還回來——而不是與時鐘掛鉤。把服務產品化的代理商更進一步：固定的價格、清楚界定的範圍、可複製的交付流程，像賣產品一樣賣，而不是給一份量身訂做的報價。而這正是 ybuild 讓一個一人公司也能做到的事，因為建置本身不再是那個過去被拿來「所以要按小時收費」的瓶頸。

真正有效的結構分兩部分：一筆用於設計、建置並上線系統的啟動費——想的是四位數出頭，而不是一張逐項列明的工時單——再加上一份按月的維護方案。因為應用託管在 ybuild 上、跑在客戶自己的網域上，這份按月方案是你實實在在要做的工作：新增畫面、做微調、讓整套系統持續在線、保持最新。網站設計的月費保留合約通常落在每月兩千到一萬美元之間；哪怕是一份不起眼的維護方案，也能把一次性的建置變成持續進帳的收入。

這是一個不動聲色的結構性優勢。你不是在轉售別人平台上的一個席位，也不會陷在半夜替一整排客戶網站打修補的自架泥沼裡。系統跑在 ybuild 上，客戶關係握在你手裡，你交付的每一個應用都會滾成按月收入，而不是在交接那一刻就畫上句點。

先做什麼，以及代理商常在哪裡踩雷

先從一個內部工具入手，而不是一次面向大眾的發布。最穩妥的第一單，是客戶已經在用試算表勉強撐著跑的那套系統——一個小型 CRM、一個工單追蹤器、一套接單加報價的流程。範圍是可知的，價值在他們不用再於分頁之間複製貼上的那一刻就兌現了，而且沒有一個行銷委員會等著評判首頁字體好不好看。拿下這第一套系統，預約網站和客戶入口就會成為向一個已經信任你的客戶輕鬆賣出的第二單和第三單。

代理商踩的第一個雷是範圍蔓延。「它能不能順便把薪資也算了？」——一個下午就是這樣悄悄變成一個季度的。在需求訪談裡就把名詞和動詞的清單寫下來，讓客戶親口確認這就是完整的第一版，把其餘的一切都當作下一個付費里程碑。產品化的範圍是一條保護你利潤的邊界，而不是一個需要你道歉的侷限。

第二個錯誤是因為建置很快就壓低價格。客戶買的是一套能用的系統，以及一個讓它持續運行的人——快是你的利潤空間，而不是你欠客戶的一份折扣。第三個錯誤是承諾量身手寫、你得永遠維護下去的程式碼；交付真正的軟體根本不需要它，而它正是把一門交付生意變成一門半夜兩點救火生意的元兇。

最後一個錯誤是把交付當成一次性買賣。如果你一交接就走人，你就把持續收入和客戶的信任都白白留在桌上。因為應用一直託管在 ybuild 上、跑在客戶的網域上，你本來就是那個讓它保持存活的人——那就為此收費。有版本歷史與當機還原，一次糟糕的改動只是一鍵還原，而不是一場緊急事故，這讓維護方案成為一份從容、高利潤的收入，而不是一個你怕它響起的呼叫器。

常見問題

用這種方式交付客戶應用，我需要會寫程式嗎？

不需要。你用大白話把客戶的系統描述出來——它要保存哪些記錄、需要哪些操作——ybuild 就會把全端應用建好：資料庫、登入、畫面，以及背後的 API。你的工作是需求梳理、品味把關與客戶關係，而不是寫程式或維護程式碼。

做好的應用跑在誰的網域和品牌上？

客戶的。你把他們自己的網域指向這個應用，它就託管在 ybuild 上上線，於是訪客看到的是客戶的品牌和網址——而不是一個測試環境的臨時網址或某個建置工具的商標。你交付的是一個跑在他們網域上、正在運行的產品，而不是一個通往別人平台的連結。

一個我一個下午就做出來的東西，我怎麼撐得起一個像樣的價格？

你定價的對象是這套能用的系統，以及它會持續運行這件事，而不是你花的工時。客戶會拿平均高達數萬美元的代理商專案、以及你正在替代的那一堆 SaaS 工具來當參照。為建置收一筆啟動費，再為改動與保持在線收一份按月維護方案的費用。

上線之後客戶想要改動，會怎麼處理？

每一處改動都只是又一句話，而不是又一個開發衝刺——你把它描述出來，ybuild 就會更新這個正在運行的應用。這正是按月維護方案的核心：你在客戶的網域上持續改進這套系統，而版本歷史讓你可以還原一次糟糕的改動，而不是去救火。

要是應用出狀況，或客戶在半夜兩點打電話來怎麼辦？

應用託管在 ybuild 上，帶有版本歷史與當機還原，所以一次糟糕的改動只是一鍵還原，而不是一台當機的伺服器。你不需要自己架設客戶網站，也不用守著基礎設施，而這正是讓一批已交付的應用成為一門從容的持續收入生意、而不是一門隨叫隨到生意的原因。