大多數中小企業到現在還相信，做一個「正經的」行動 App 意味著 6 個月開發週期、兩個平行團隊（iOS + Android）、台幣七位數預算，加上一份足以自己變成一個事業單位的維護合約。這個模型在 2018 年是合理的。在 2026 年，用 Flutter 前端加 Laravel 後端、再配上一個合理規模的 MySQL 9.7，同樣的範圍 6 週就能上線。
這不是行銷話術——這是我們每一個中小企業行動專案實際採用的架構。下面解釋它為什麼成立，以及為什麼我們屢屢從報價是我們四倍的大型工作室手中接走標案。
一、一份程式碼、兩家商店、不必妥協
Flutter 3.41——5 月初剛發的當前穩定版——把 Flutter UI 跟原生 UI 之間最後肉眼可見的差距抹平了。Cupertino 風格的 sheet、原生的拖曳把手、跟原生 CircularProgressIndicator 同等的無障礙支援、Impeller 上新的 bounded blur、可以按平台分配資產讓 iOS 包體變小的 pubspec 規則。我們可以同一天交給客戶一個 iOS 版本——截圖起來跟用 Swift 寫的原生 App 沒有差別——和一個 Material 3 風格俐落的 Android 版本，從同一份程式碼。
這不是空話。我們最近三個中小企業的行動 App 上線，都在同一個 24 小時內雙商店上架。每一個在 2018 年都會是兩個三個月各自獨立的專案。
二、不會變成明年問題的後端
我們每個 Flutter 前端都搭配 Laravel 13 + MySQL 9.7 後端。客戶通常要過一段時間才會體會到這個 stack 為什麼重要。MySQL 9.7 的動態資料遮罩意味著我們可以把 staging dump 直接交給外包工程師，完全不必寫遮罩腳本。JSON Duality 意味著 Flutter App 拿到的 API 回傳，是直接對著畫面塑形好的——沒有 Eloquent N+1、沒有 overfetch、沒有前端在那邊重組資料。Laravel 13 的 AI SDK 意味著智慧搜尋、App 內摘要、智慧通知這些功能，是一行 service 層呼叫，不是廠商綁定。
結果是：當客戶在第七個月想加第四個功能，我們不用重寫任何東西。加一條 route、上線、繼續做下一個。
三、已經為真正會來的東西做好準備
我們已經在為兩個平台位移設計。
iOS 27 Extensions（從 Apple 5 月相關報導推估，預計 6 月 WWDC 正式宣布）。我們交付的每一個 Flutter App 都把商業邏輯抽離 UI，用純 Dart 寫，並透過單一 dispatcher 曝出 intent。等 iOS 27 上線、客戶想讓 Siri 可以查詢他們的 App——預約時段、查訂單、紀錄一次運動——整合是一層薄殼，不是重寫。
Android AI Core / 端側 Gemini。 同樣的形狀。我們的後端 gateway 已經會說結構化 intent，要換端側模型只是改 config。
這是「6 週交付」跟「6 週衝刺後把客戶卡住」的差別。我們不是用偷工減料省時間。我們省時間，是因為今天我們不偷的那些工，正是三個月後要花三個月去補的那些工。
四、6 週裡我們交付什麼
第 1 週：需求釐清、線稿、MySQL schema、Laravel API contract。
第 2–3 週：Flutter UI 骨架、登入、核心 CRUD 流程、雙商店 build。
第 4 週：Laravel API 整合、推播、App 內分析。
第 5 週：客戶 UAT、收尾、商店送審文件。
第 6 週：商店審查、上線、交接文件、為日後在公司內部接手 App 的人辦一場知識交接會。
固定價格。原始需求書裡的修改不會被以「scope creep」加價。維護月費小到讓客戶不會看到帳單就皺眉，但又有實質內容到我們真的會幫你把依賴升級保持新鮮。
五、為什麼這個模式特別適合中小企業
大型代理商的利潤來自團隊規模。他們報 30 週是因為要養 bench。我們的利潤來自一個高度互信、且做這套架構超過十次以上的小團隊的速度。每個專案會複利到下一個。每一塊可重用模組——登入、推播、金流、App 內訊息、Extensions adapter——下一次部署都更便宜。
如果你的事業在零售、運輸、服務、餐旅，而你被告知今年做客製行動 App 不切實際，請拿到第二份報價。把你的需求書交給我們。價格不會是你預期的，時程也不會是。