很多公司在做網站時會遇到同一個岔路：業務單位描述了一個需求，廠商回覆說這要客製、要另外開發，但你不確定這句話是真的有技術難度，還是只是報價的說法。網頁程式設計 這個詞涵蓋的範圍很廣，從改一個設定、裝一個模組，到從頭寫一套系統都算，價差與後續責任卻天差地遠。這篇不談前端框架或資料庫怎麼選，而是給你一組判斷準則：怎麼看出手上的需求落在哪一層，以及每一層的成本與維護責任會落在誰身上。
一、先問一句話：這個需求有沒有現成做法
判斷的起點很簡單：你要的東西，是不是很多人也需要？如果答案是肯定的，市面上通常已經有現成的功能或模組，設定一下就能用；如果這個需求只有你們公司這樣做，那多半就得寫。
舉例來說，聯絡表單、最新消息、產品分類、會員註冊、線上付款，這些幾乎每個網站都會用到，屬於現成範圍。但如果你要的是客戶下單後依照各廠區庫存自動分配出貨點，並把結果回寫到內部系統，那就沒有現成的可以直接套用。
中間地帶最容易誤判，也是報價落差最大的地方：需求看起來像現成功能，但有一兩個條件不一樣。例如表單是現成的，但你要送出後依照選項寄給不同部門、自動產生編號並累計統計，這時就從設定進入了擴充。
二、五個問題，決定你需不需要寫程式
面對一個需求時，可以依序問自己這五題，回答是的題數越多，需要開發的程度就越高。
- 這個功能需要跟公司內部既有系統交換資料嗎？
- 有沒有一套只有你們公司才懂的規則或計算邏輯要實作？
- 需要處理的資料量或欄位數，超出一般後台表格能管理的範圍嗎？
- 使用者的操作流程，是不是無法用既有頁面組合出來？
- 這個功能會不會直接影響營收，或牽涉金流與個人資料？
如果五題都否，你的需求大概只要設定就能完成。如果只有一兩題是，通常落在擴充範圍。三題以上是，就要有心理準備進入客製開發，時程與費用的評估方式也會完全不同。
還有一個實務上的提醒：不要用這看起來很簡單來推估。畫面上看起來只是多一個欄位，背後可能牽涉到資料結構、權限、通知與報表。反過來也有看起來複雜、其實有現成解法的情況。所以把需求描述清楚再問廠商，會比自己先下判斷準確得多。
三、第一層：只做設定，不寫程式
這一層的特徵是：所有調整都在後台或工具介面裡完成，包括版面配置、頁面新增、表單欄位、分類結構與基本樣式調整。
成本最低、上線最快，而且門檻低，公司內部的行銷或行政人員經過教學就能自行維護。缺點是受限於工具提供的選項，遇到一點點特殊需求就會卡住；而且為了把工具凹成想要的樣子，常常會疊上一堆補丁式設定，久了反而難以整理。
維護責任在這一層通常落在業主自己身上，這其實是好事：你不需要為了改一行文字去發工單等廠商排程，內容也比較容易保持更新。前提是交接時要拿到完整的後台權限與操作說明，否則名義上能自己改，實際上還是動不了。
四、第二層：擴充既有功能
第二層是在現成系統的基礎上加東西：多一個欄位、改一段流程、串接一個外部服務、調整既有模組的行為。這需要懂程式的人動手，但不是從零開始，開發量相對可控。
這一層的關鍵風險是相容性。你改動的是別人寫好的系統，當那套系統更新版本時，你的改動可能失效或產生衝突。因此擴充的做法很重要：要用系統官方提供的擴充方式來加功能，例如掛勾或子主題，而不是直接修改核心檔案。直接改核心短期可行，長期等於放棄更新，安全風險會慢慢累積。
維護責任在這一層是分擔的：系統本身的更新由平台或主機端負責，擴充的部分由當初寫的人負責。所以合約裡要寫清楚擴充程式的原始碼歸屬、放在哪裡、有沒有註解與說明文件。這一段如果沒有交代，換廠商時最容易變成沒有人認領的地帶，最後只能整個重寫。
五、第三層：客製開發，真正的 網頁程式設計
第三層是依照你的業務邏輯，從資料結構開始設計並實作。適用情境通常是內部系統介接、特殊的計算或審核流程、大量結構化資料的管理與查詢，或需要獨立權限與角色設計的平台。
這一層的成本明顯高於前兩層，而且費用不只發生在開發當下。客製系統需要有人持續維護：執行環境與相依套件要更新、瀏覽器或串接的第三方服務改版時要調整、新需求要延伸。把長期成本算進來之後，有些需求會發現用既有工具搭配流程調整反而更實際。
要進入這一層之前，建議先做兩件事。第一是把需求寫成規格文件，包含使用情境、欄位定義、權限設計與例外處理，這份文件同時是報價基礎與驗收依據。第二是確認原始碼歸屬與交付方式，並要求提供環境建置說明，讓網站在必要時能由別的團隊接手，不會因為一個人離職就停擺。
六、成本與維護責任落在誰身上
把三層放在一起看，差別可以這樣理解。只做設定：建置成本最低，維護責任大部分在業主，風險是受限於工具能力。擴充既有功能：建置成本中等，維護責任由業主與開發者分擔，風險在相容性與人員交接。客製開發：建置成本最高，維護責任長期綁在開發團隊或內部人力，風險在於文件不足時沒有人能接手。
選擇哪一層，不是看哪種技術比較厲害，而是看這個功能對業務有多重要、公司有沒有能力承接後續維護，以及過幾年之後這個需求還在不在。短期活動用的功能，用現成工具撐過去就好；長期支撐核心業務的流程，才值得投入客製。
另外提醒一個常見誤區：把所有需求都推到客製，會讓網站變成沒有人敢動的系統，連改一張圖都要排程。合理的做法是分層，日常內容維持在設定層由內部自己管理，只有真正無法取代的部分才客製。這樣網站才有辦法持續更新，而內容能持續更新，對搜尋表現通常也比較有利。
常見問題
廠商說要客製，我怎麼確認是真的需要？
請對方說明為什麼現成方案做不到、具體卡在哪一個條件。願意解釋的廠商通常講得出來；如果只回答這個要另外開發卻說不出理由，可以再問第二家比對說法。
網頁程式設計 的報價為什麼差距那麼大？
因為做法不同。同一句需求描述，有人用現成模組設定、有人做小幅擴充、有人從頭開發，三種工作量本來就不一樣。比價之前先確認三家提的是同一層做法，否則比的是不同的東西。
客製功能做好之後，就不用再花錢了嗎？
不會。執行環境、瀏覽器與串接的第三方服務都會改版，客製程式需要跟著調整。建議把維護視為固定支出，並在合約裡寫明維護範圍、回應時間與計費方式。
客製開發會讓 SEO 變好嗎？
不必然。自行開發的頁面如果忽略標題階層、網址結構、載入速度與行動裝置呈現，表現可能比套版還差。要讓開發對搜尋有幫助，得在規格階段就把這些基本要求寫進去，而不是上線後才補救。
判斷需求落在哪一層，通常不需要技術背景，只要把為什麼非這樣不可問清楚就有答案。把需求分層之後，你會發現真正需要開發的部分往往比想像中少，預算也能放到更關鍵的地方。
如果你手上有一份還沒定案的需求清單，不確定哪些該客製、哪些用現成的就好，創昇SEO提供免費網站健檢與全台免費到府解說，可以一起把需求攤開來排序，再決定要走哪一條路。