這個德國程序員把開源代碼賣了3年，才發現客戶真正要的不是技術

2019年，德國開發者Ingo Steinke的Shopware插件下載量突破1.5萬次，但收入幾乎為零。他花了18個月才明白：客戶買的從來不是代碼本身，而是"能自己掌控生意"的幻覺。

「快餐式建站」的陷阱：為什么一鍵安裝永遠不夠

軟件即服務（SaaS）像極了快時尚和平板家具。注冊、付款、導入數據、改改顏色——聽起來像是30分鐘搭好一個網站。Steinke見過太多人在這個環節栽跟頭，包括他自己早期的客戶。

「即使我們開發者把后臺做得像DJ臺一樣酷炫，你還得自己選音樂。」這是他在技術博客里寫的原話。花哨的儀表盤解決不了核心問題：你的業務邏輯、你的內容策略、你的履約流程，這些都沒法一鍵生成。

Steinke的親身經歷很有代表性。他的個人博客Open-Mind-Culture.org最初只是WordPress開發的測試環境，粉絲店則跑著他自己的Shopware主題和擴展。這些"小項目"讓他以真實店主身份體驗主機、支付、物流——不是作為外包商，而是作為承擔庫存風險的人。

這種雙重身份讓他發現了一個行業潛規則：技術供應商和客戶之間存在巨大的認知斷層。

客戶以為買的是"開箱即用"，開發者賣的是"可擴展架構"。兩邊說的根本不是同一種語言。Steinke的一個客戶曾要求他"簡單改一下"結賬流程，結果牽動了稅務計算、庫存同步、郵件模板、第三方物流API——所謂"簡單"背后是一整周的逆向工程。

從免費開源到付費咨詢：1.5萬次下載教會他的事

Steinke的開源履歷很漂亮。Shopware插件、npm包、代碼編輯器擴展，技術社區里他的名字出現頻率不低。但下載量和賬單數字長期倒掛——1.5萬次下載帶來的直接收入，還不夠支付他回復issue的時間成本。

轉折點發生在2021年。一個中型時尚零售商找到他，不是要插件，而是要"一個能聽懂我們庫存規則的人"。對方已經試過Shopify和WooCommerce，都被復雜的德國稅務規則卡住了。Steinke花了三周寫定制代碼，收費是他之前一年開源收入的三倍。

「那時候我才意識到，客戶愿意為'理解業務'付溢價，而不是為'懂技術'。」他在回顧這段經歷時寫道。

這個認知徹底改變了他的接單策略。以前他在作品集里堆技術棧：Kubernetes集群、原生WordPress主題、Intershop集成。后來他改成展示"我吃過客戶賣的水果"——字面意義上的。他給一家在線藥房做開發時，真的下單買過那家的檸檬和橙子，就為了體驗從搜索到收貨的全流程。

這種"用戶視角"的偏執，讓他的報價單從"人天費率"變成了"問題解決套餐"。

企業客戶開始主動找上門。一個國際建筑公司的招聘門戶項目，他作為自由職業首席開發者全程把控。一個需要支撐數千站點的WordPress主題，部署在Kubernetes集群里。這些項目的共同點是：客戶先買的不是他的技術，而是他"不會過度工程化"的承諾。

技術選型背后的權力博弈：為什么開發者偏愛"熟悉的麻煩"

Steinke列出的技術清單很長：WordPress、WooCommerce、Shopify、Astro、Gatsby、Hugo、Typo3、Drupal、Magento、Shopware、Xsite。他承認自己的偏好很明顯——"作為開發者，我顯然更傾向我已經知道的"。

但這種偏好背后有個被忽視的變量：控制權。

SaaS平臺把服務器、安全更新、合規認證都包圓了，代價是你得按它的規則玩。Steinke舉過一個具體例子：某平臺2022年突然調整API速率限制，導致他客戶的庫存同步延遲了四小時。客戶損失了訂單，平臺條款里寫著"不保證服務連續性"。

自托管方案（如WordPress+WooCommerce或Shopware）把風險轉給了店主，但也給了反向操作的空間。Steinke的一個客戶在德國能源危機期間緊急上線了"本地取貨"功能，從需求提出到上線只用了48小時——這在依賴平臺審核流程的SaaS架構里幾乎不可能。

「找到內容、定制代碼和業務邏輯之間的平衡，也意味著找到對的人合作。」Steinke在文章里強調。他的合作網絡包括設計師、數據科學家、法務和營銷專家，但核心原則沒變：避免大型代理公司那種"不可削減的 overhead"。

如果你清楚自己要什么，直接找資深自由職業者通常更快更便宜——前提是對方誠實告訴你"這個需求對我來說太大/太小"。

這種匹配效率是Steinke現在最看重的指標。他拒絕過一個月入需求只有5000歐元的"全包電商方案"咨詢，也推掉過需要二十人團隊的企業級項目。過濾機制讓他的實際交付成功率維持在90%以上，而行業平均在60%左右徘徊。

2024年的新變量：AI生成代碼是幫手還是新陷阱

Steinke對"AI建站"的態度很克制。他試用過幾個熱門工具，結論是：生成式AI在處理標準化模塊時確實快，但遇到業務規則的邊緣情況就會"自信地胡說"。

他測試過一個場景：讓AI生成符合德國《價格指示條例》的促銷標簽代碼。AI給出了看起來正確的實現，但漏掉了"折扣必須基于過去30天最低售價"的細節——這個疏忽在法庭上可能意味著數萬歐元罰款。

「AI、無代碼、積木式搭建，叫什么都可以，但定制網站或網店永遠不止是一鍵安裝。」他在文章開頭寫的這句話，放在2024年反而更貼切了。工具越來越聰明，但"擁有你的生意"這件事沒有捷徑。

Steinke現在的項目清單里，約40%涉及"清理AI生成的半成品代碼"。客戶被低門檻吸引進來，發現定制需求無法被工具覆蓋，再回頭找真人開發者救火。這種循環讓他想起十年前"模板網站"時代的類似劇本。

他的應對策略是前置溝通。新項目的第一封郵件不再討論技術方案，而是問三個問題：你的核心業務流程是什么？哪些環節絕對不能出錯？如果明天必須改一個規則，誰能拍板？

這些問題過濾掉了80%的"試試看"咨詢，但留下的客戶續約率是之前的2.3倍。

Steinke的最新項目是幫一個 ethical startup 遷移從AI工具起步的電商架構。遷移成本占重新開發的60%，但客戶算過賬：繼續用半吊子自動化，每年的隱性損失（庫存錯誤、客服返工、合規風險）是這個數字的四倍。

他在項目文檔里寫了一行備注，后來被客戶轉發到了Twitter："我們不是在買代碼，是在買'能睡個好覺'的確定性。"

這句話現在掛在他網站的首頁。訪客以為是營銷話術，Steinke知道這是2019年那個對著1.5萬次下載量發呆的開發者，花了五年時間才想明白的真相。

如果你明天要啟動一個電商項目，你會先選工具，還是先畫清楚自己的業務規則邊界？