用無程式碼起步，以後會不會打掉重做

同一個畫面，兩種做法

比較無程式碼與自建開發時，人們通常攤開一張功能清單：能不能註冊會員，能不能接金流，有沒有後台管理頁。可這張清單得不出結論，因為現在的無程式碼工具對絕大多數項目都會回答「可以」。

真正分開兩者的是資料。自建的後端裡，會員資訊與訂單紀錄躺在你自己簽約的資料庫中。無程式碼則把它們放在工具廠商的系統裡，你只能透過對方提供的介面與匯出功能去接觸。單看畫面，兩個產品跑起來一模一樣。差別要等到你和這家廠商的關係結束時才顯現。

這裡容易生出一個誤讀：以為無程式碼是權宜之計，自建才是正經做法。並非如此。預約登記、內部申請表單、小型商城這類資料結構單純、規模可預期的服務，用無程式碼運行好幾年也不會出問題。之所以出現打掉重做，往往不是工具不好，而是產品朝著選型時沒預料到的方向長了起來。

無程式碼真正卡住的三個位置

第一是費用隨用量上漲的計價方式。無程式碼工具多半按紀錄筆數、執行次數或席次計費。如果使用者成長的同時營收也成長，這沒有問題。但若免費使用者佔大宗、付費轉換只是一小部分，漲的只有成本，營收跟不上。算帳不要用現在的方案，要用使用者數翻十倍時收到的帳單來算。

第二是多人同時改動同一份資料的時刻。庫存只剩一件的商品，兩位顧客同時下單會怎樣。自建後端對這種情況有成熟的處理方式。無程式碼的自動化流程常常按「步驟依序執行」來設計，因此需要翻廠商文件，確認執行互相重疊時它究竟怎麼處理。平時看不見，偏偏在最忙的那天爆出來。

第三是外部服務串接超出內建範圍的時候。金流、簡訊、地圖這些常用連接大多已經備好。麻煩的是工具沒有直接支援的對象，比如某家區域物流公司或報稅系統。這時你會搭一條繞行的路把它接上，而繞行的路一旦累積到三四條，維護難度就超過了自建。不是沒有程式碼，而是程式碼散落在好幾個工具裡。

提前壓低搬遷成本的兩件事

這三件都是將來的事，眼下很難判斷。所以無論選哪條路，現在都有兩件事值得先確認。

看資料能不能整份取出來。 在選定工具之前先查它的匯出功能。把畫面上看得見的表格下載成試算表，和連同關聯關係一起、透過檔案或 API 取走全部資料，這是兩回事。未來搬遷成本的大部分就在這裡定下。資料只要完整出來，畫面可以重做；資料被鎖住，就得靠人手一筆筆搬。

決定商業規則寫在哪裡。 折扣比例、等級判定、結算方式，這些是只屬於你這門生意的規則。把它們分散埋進無程式碼工具的各個自動化模組，將來搬遷的第一項工作就是把這些規則一個個找出來。反過來，如果把規則集中放在一處，換工具時這部分可以原樣帶走。

歸結起來，最先要定的不是無程式碼還是自建，而是這個產品的資料會怎樣生長，以及你能不能隨時把它取出來。這一點定了，工具的選擇自然跟著出來。

如果你已經在用某個工具，告訴我們它的名字就夠了。Weple 會先看你現在的結構還能走多遠，若確實需要搬遷，再把先取什麼、按什麼順序取理出來。如果還什麼都沒選，那就從你想做的產品聊起。