基礎篇：免費方案實際包含什麼

我花了五天時間,像真正的使用者一樣實際使用免費方案,而不是照著定價頁面上寫的方式體驗。截圖然後就走人,並不是找出隱藏條款的方法;實際花一週時間建置東西、撞上真實存在的限制,才是。以下是這段過程的紀錄。

週一,上午 9:40 — 註冊,不需信用卡

在動手寫任何程式之前,我先確認的第一件事是:會不會要求輸入信用卡資訊。結果沒有。這種細節我通常會略過,但一個在你還沒建置任何東西前就要求付款資訊的免費方案,其實已經透露了它對你的看法,所以我把這點記下來,然後就開始實際建置。

選了一個小型企業網站作為測試專案 — 沒什麼特別的,一個登陸頁面、一個聯絡表單、一個部落格區塊。到上午 10:15,我已經在免費子網域上發布了第一版。「建置」與「發布」之間沒有付費牆阻擋,這一點在很多免費方案中,常常悄悄變成只能做展示的關卡。

週一,下午 2:00 — 疊代循環,我原本預期會撞牆的地方

這是我最懷疑的部分。第一次建置對任何 AI 代理來說都很「便宜」——需求乾淨、沒有既有程式碼要協調——所以平台可以讓免費方案在第一次建置時看起來很大方,但到第二次建置就悄悄開始壓榨你。我特地針對這個疊代循環測試:「讓標題列固定在頂部」、「修正行動版導覽列」、內容調整,以及之後再兩個較小的修改。每一項改動所牽涉的檔案都比需求描述本身暗示的更多,這正是真實修改的常態。那天我沒有真的撞到上限,但能感覺到上限在哪裡——這個額度顯然是以一個完整循環的份量來設計的,而不是五個。

那天下午,我也特地檢查了免費帳號是否會為了省算力而跳過審核步驟。結果沒有——同樣的程式碼檢查、同樣的安全性檢查、同樣的功能驗證,任何東西標記完成前都一樣要跑過。我特地檢查這一點,是因為如果換作是我在經營這門生意、面臨利潤壓力時,這正是我第一個會砍掉的環節,而它並沒有被砍掉。

週二,上午 11:00 — 建立第二個專案,測試後端限制

又建立了一個新點子,這次需要真正的後端 — 資料庫、API 路由,一應俱全。這正是我預期會真正碰到限制的地方,而我也確實找到了:免費帳號只能有一個正式運作中、具伺服器後端的應用程式。我試著在第一個之外再啟動第二個具伺服器的後端,結果無法讓兩者同時上線運作。

讓我意外的是,哪些東西不會佔用那個名額。我在那週稍晚建置了一個小型的可下載工具——沒有伺服器,只是一個打包好的應用程式——它照常發布,完全不會跟正在運作中的後端搶名額。仔細想想其實合理,從成本結構來看:一個具伺服器的後端需要持續保持運作,不論有沒有人在用都要花錢;而靜態或可安裝的建置版本,就只是靜靜放在那裡的檔案。只有持續運作的那種才會被限制數量。

週二下午4:30——嘗試打破並行性

啟動了一個建構任務,然後在執行途中要求助理啟動另一件不相關的事。它排隊等候,而不是並行執行。前九十秒左右有點惱人,之後就無關緊要了——反正我一直在看第一個建構的預覽,所以「等它完成再開始下一個」本來就是我會做的事。我可以想像這對同時運行兩條智慧代理流程的團隊來說會更重要——一邊在某個頁面上生成內容,一邊讓建構代理重新調整另一個頁面的結構——但那是跟我不同的使用模式。

週三——關於資料庫,以及它們為什麼不是試用功能

週三整天都在測試累積功能——知識庫、參考圖片、範本——在免費版上是否真的可用,還是只是付費版的試用預告。結果並沒有被限制。到第三天,平台已經在重複使用我的品牌語調和參考截圖,不需要我再重新解釋一遍,而這正是知識層存在的全部意義:如果把它鎖起來,免費用戶就永遠看不到產品的複利效果,那他們又怎麼會願意付費繼續使用一個從未讓他們看到價值的東西呢。

我也試探了租戶資料隔離是否在免費版上「比較弱」——部分隔離、隔離檢查排隊較慢,或任何類似的情況。結果並沒有,而且說實話它在結構上就不可能有差別;隔離是二元的。背景工作與查詢要麼按租戶完全隔離,要麼就沒有隔離,這裡不存在打八折出售的中間版本。免費版和付費版在這一點上獲得相同的保證,這是我原本就假設的,但我想親自驗證而不是憑空相信。

週四——上架發布,那件我差點沒試的事

我差點跳過這項測試,因為我以為發布到應用程式商店只限付費用戶——這是大多數人會有的直覺,而且是錯的。我把週二做的那個小工具打包成可安裝檔案,平台端的發布流程運作方式跟我預期的付費帳戶完全一樣。唯一的阻力來自 Google 自己的開發者註冊費,跟我用的方案毫無關係。這點值得明講,因為我見過有人僅僅因為假設最壞情況,就自我設限了根本不存在的限制。

週五——下次我會跳過的部分

如果我再跑一次這項測試,我會跳過週二下午的並行性探測——它在不到兩分鐘內就得到了答案,而我又多花了四十分鐘嘗試各種變化,結果都證實了同一件事。我也會把租戶隔離檢查提前到第一天,而不是第三天,因為這是人們在把任何正式資料放上平台之前就該知道的事實,而不是事後才知道。

我不會跳過的部分:週一的迭代循環測試。那是免費方案通常會露出馬腳、顯示自己其實是行銷包裝更好的漏斗的地方,如果你在猶豫這究竟是真正的產品還是包裝精美的試用版,這項測試值得你自己花時間重跑一次。

所以:根據我實際遇到的問題,而不是我原本預期會遇到的問題,升級的三個正當理由如下。你已經不只一次把迭代循環用到見底,而不只是每個人第一個月都會經歷的那一次——參見用完額度後實際會發生什麼,不會有任何損失,但重複出現的模式就是一種訊號。你需要同時上線兩個託管後端,這是免費版在結構上就無法承載的需求,而不是靠精打細算就能解決的預算問題。或者你做的東西已經不再是測試,而是開始為你賺錢,這時候在接近上限的邊緣運行,是一種焦慮成本,而不只是技術成本。

這週我一個都沒遇到。我建構了一個真正的網站和一個真正可下載的工具,兩者都反覆迭代、都發布上架,而我遇到的唯一牆,正好就是說明文件裡寫明會有的那道牆。