重寫還是沿用——兩條分岔的路,一個歸屬權的抉擇

重寫還是沿用:獨立開發者的「託管」法則

「自建還是購買」是軟體界最古老的爭論,多年來它不過是一道無聊的算術題:如果買授權比請工程師還貴,那就自己寫。AI 把這筆帳徹底打破了。當一個獨立開發者能用週末做出過去要一整個季度才能完成的東西時,沿用的成本理由——用一個函式庫、一個 SaaS 工具、一個開源專案——悄悄就不再是決定因素了。 取而代之的是一個更安靜的問題:當事情真正關鍵的關頭,這東西歸誰管? 這不再是成本問題,而是「託管」問題——而在現實中,真正決定你這一人的公司能不能活過第三年的,恰恰就是它。 重寫變便宜了,但「託管」沒有 這是大多數獨立開發者忽略的不對稱。AI 壓垮的是編寫程式的前期成本,但對擁有程式碼的持續成本幾乎毫無影響。這個數字業界已經知道幾十年了,而且從沒變過:軟體總持有成本的 50–80% 是維護——修 bug、打安全修補、升級依賴,以及在振奮人心的第一版之後、年復一年讓這東西活下去的那些瑣碎水滴。Gartner 把 IT 預算花在維護現有系統上的比例定在 55–80%;IEEE 的數字是 60–80%。 所以重寫是開始便宜,但你得永遠擁有它。第一次提交幾乎免費。第一千次提交——四年後、深夜十一點、某個你 fork 過的函式庫已經走鐘、原作者早已棄坑——才是真正的帳單所在。 沿用今天便宜,但依賴會回過頭來擁有你 鏡像的另一面同樣危險。當你沿用時,你把維護外包了——同時把鑰匙交給了別人。供應商的路線圖變成了你的路線圖,他們的漲價變成了你的成本,他們那封「我們即將終止這項產品」的電子郵件變成了你的緊急事故。 這不是假設。資料說得毫不含糊:Flexera 報告指出,47% 的企業把資料遷移列為更換供應商的重大障礙。 這個「47%」就是那個臨界點——你自由做出的一個選擇,硬邦邦地凝固成了一個你不把系統扯碎就離不開的處境。託管權不是在一個戲劇性的瞬間失去的,它是在「先用這個湊合一下」和「我們已經不敢搬走了」之間的縫隙裡,悄悄丟失的。 陷阱在於只按建置成本定價 舊爭論的雙方犯的是同一個錯:他們只給第一版定價。「自建還是購買」的計算機拿最初的開發成本去比第一年的訂閱費,這是錯的座標軸。 該算的是持有成本。你重寫的東西,開始便宜、永遠要養——維護、升級、依賴走鐘、安全修補、你自己選擇的鎖定,以及搭別人路線圖便車的複利。你沿用的東西,今天便宜、明天擁有你。誠實的比較不是建置成本對購買價格,而是:我是在租便利,還是在為一個我無法外包的東西付「託管費」? 重寫是開始便宜,但你得永遠擁有它;沿用是今天便宜,但依賴會擁有你。一座你養不起的護城河,根本不是護城河。 託管法則:沿用「日用品」,重寫「護城河」 這個決策不是把「自建還是購買」當成身分——「我是個 builder」或「我只買 SaaS」。它是一條只有一個軸的託管法則: 沿用一切「日用品」。 那些無差別的管路活——有健康的可替代市場、因為大家講同一種標準所以切換成本低、長年以來做著同一件無聊事的那些東西。如果明天有三個供應商能頂替它、而你幾乎察覺不到,那你就一件都不該擁有。別重寫它。付訂閱費,把注意力留給真正要緊的事。 只重寫「護城河」。 那一兩樣就是你的產品的東西——競爭對手不可能透過訂閱你用的同一個 SaaS 就複製走的那部分。那才是唯一值得付永遠維護帳單的東西,因為只有它的維護本身就是這門生意。 還有第三種失敗:那個「非我親手建不可」的反射 這個框架裡的反派不是 SaaS,也不是開源,而是 「非我親手建不可」症候群——那種因為「重寫現在感覺像是進展、擁有它感覺像是掌控」就沉沒時間去重寫無差別管路的習慣。獨立開發者最稀缺的資源不是錢,而是注意力,攤在一條只會不斷變長的維護戰線上。每一個花在重新實作某樣 20 美元/月工具早就做好的功能上的小時,都是沒花在護城河上的小時。 這個檢驗不舒服,但很簡單:如果你完全停止做這件事,傷到的是你的生意,還是你的自尊? 日用品活通常只傷後者。 獨立開發者版的法則 對一人產品團隊來說,這條法則收縮成一條你真正能執行的規則: 是日用品嗎? 買它,或者用維護者最健康的那個開源專案——並且確認你能脫身。如果你說不出你的退場路徑,那你就沒有這個選擇的託管權,是供應商在託管你。 是護城河嗎? 自己建——並且清楚那筆維護帳單是真實的、而且永遠是你的。每年約占建置成本 15–25% 是持續開銷的大致數字。如果這筆帳單聽起來養不起,那說明它不是護城河,而是興趣。 中間的模糊地帶呢? 那才是 AI 真正改變的地方。過去真的要自己建的活——膠水程式碼、內部工具、整合——現在便宜到可以重寫,於是「肯定要買」的清單變短了。但「開始便宜」仍然不等於「養得起」。在事物被證明處於核心之前,預設沿用,然後才重寫。 重點不是獨立開發者應該什麼都重寫、或什麼都買。而是這個問題變了。二十年前你問「自建和買授權各要多少錢」,現在誠實的問題是 「我願意成為什麼東西的託管人,又願意租用什麼東西?」 ——而大多數獨立開發者,在大多數時候,租的東西遠比他們意識到的多,而真正要緊的東西,他們一件都沒在託管。 這條法則有兩個值得接著讀的鄰居:〈Vibe Coding 的隱藏成本〉是同一筆「擁有成本」從另一個方向找上你,而〈何時該信任一個開源套件〉則是你收下一份得自己維護的依賴之前,該做的盡職調查。 Sources Gartner——IT 維護支出:組織約把 55–80% 的 IT 預算花在維護現有系統上(持有成本占比基準,廣泛見於 Gartner 的 IT 關鍵指標研究)。 IEEE Computer Society——軟體維護約占軟體全生命週期成本的 60–80%。 Standish Group——CHAOS Report:約 69% 的軟體專案交付部分價值或毫無價值(說明為何每次重寫都應視作一次下注,而非必然)。 Flexera——State of the Cloud:47% 的企業把資料遷移列為更換供應商的重大障礙(「託管硬化成鎖定」的證據)。 Keyhole Software/業界 TCO 基準——持續維護約占初始建置成本每年 15–25%。 關於確定性:「50–80% 維護占比」是持久的業界基準(Gartner/IEEE/ISBSG 發布了相互重疊的區間),而非單一具名研究的精確數字——請把它當作方向性區間,而非精確點位。Flexera 的 47% 與 Standish 的 69% 均來自具名的原始報告。