設計師在晨光下的桌面上以鉛筆繪製線框草圖,紙面留白

合作前先讀這裡

關於合作、報價與時程的常見問題

這裡整理訪客在合作前最常提出的問題。如果你要問的項目不在其中,可以直接到聯絡頁提出,我們會依你的情況回覆。

報價方式

報價是怎麼算的

兩人並坐在桌旁,手指著一張空白紙面討論範圍

我們通常依範圍與階段報價,而不是給一個籠統的總價。原因是同樣叫「做一個 App」,功能數量、後台需求、雙語複雜度與權限設計的差異可以很大。

實務上我們會先做需求整理,把工作拆成可估算的項目,再分階段提出費用。這樣你可以選擇先做第一階段,確認方向後再決定要不要往下走。

影響估價的幾個變數

  • 功能數量與流程分支 直接影響
  • 後台與資料結構 常有隱藏工
  • 中英雙語的版面複雜度 設計階段就要算
  • 帳號權限與角色設計 越晚改越貴
  • 第三方服務串接數量 依實際需要

需求整理完成後,你會拿到一份可估算的工作清單,而不是一個無法驗證的總價。

排期邏輯

專案大概要多久

時程取決於功能範圍與外部依賴。設計階段通常在前段佔比較多時間,開發與測試則在範圍穩定後展開。上架審核、第三方服務申請與資料整理這些外部項目,常常是影響最大的變數。

我們會在需求整理後給出分階段的排期,而不是一個模糊的總天數。這樣你可以按階段驗收,也方便安排內部的配合人力。

前段

需求整理與設計

訪談、流程圖、資訊架構與介面設計。雙語與權限的決定要在這一段定案,後段才不會反覆。

中段

開發與內部測試

前端與後端並行,依階段交付可操作的版本。每個階段都有可驗收的內容,不必等全部做完才看到東西。

後段

上架與外部審核

商店審核、第三方服務開通與正式資料匯入。這一段時間長短不由我們單方面決定,排期會先講清楚。

技術選擇

應該先做原生還是跨平台

如果兩個平台要同時上線、介面要求一致、且需要較快的迭代節奏,Flutter 這類跨平台框架可以讓單一程式碼庫輸出 iOS 與 Android,版本同步的負擔較小。

如果功能高度依賴特定硬體或系統層能力,原生路線的控制力會更直接。iOS 端我們以 Xcode 進行編譯、除錯與模擬器測試。這題沒有標準答案,要看你的功能清單與半年內的改版計劃。

兩平台同時上線、介面一致 跨平台優先
深度使用相機、藍牙或系統層能力 原生優先
改版節奏快、要常推小版本 跨平台優先
還不確定,就先一起把功能清單列出來 我們的建議
手持手機在暗色桌面上,螢幕只留下溫暖的微光

技術路線會直接影響後續的維護成本,因此我們會在動手前把兩條路線的差異講清楚,再一起決定。

雙語規劃

繁中與英文要怎麼安排

重點不只在翻譯,而在版面。英文字串通常比中文長,按鈕、選單與表格欄位都可能在切換後跑掉。我們會在資訊架構階段就把語言切換當成正式功能規劃。

標籤、導覽名稱、錯誤訊息與通知文案都會預留英文長度,並在設計系統裡定義換行與截斷規則。這樣到開發階段,雙語不會變成臨時加班的來源。

如果現階段只需要中文,我們也會保留未來加上英文的結構空間,避免之後整份版面重做。

雙語設計要先處理的事

  • 按鈕與導覽名稱先估英文長度,保留換行規則
  • 表格欄位與錯誤訊息定義截斷與提示方式
  • 字體與行高在兩種語言下都要維持可讀
  • 語言切換視為正式功能,排進設計與測試流程
在沙發邊以觸控筆在平板上畫出簡單流程的人

快速驗證

無程式碼工具適合做 MVP 嗎

適合,前提是目標清楚。如果只是想確認某個流程有沒有用、內部工具的使用者會不會買單,Bubble 這類平台可以較快做出可操作的網頁應用與後台原型,讓真人試用後再決定要不要客製開發。

但如果你需要複雜權限、大量資料處理或長期維護的系統,繞這一段反而多花時間。我們會直接說明哪種情況適合先驗證,哪種情況直接開發更實際。

適合先做原型

流程還在搖擺、要給真人試用、或只是內部工具的小範圍驗證。

適合直接開發

需要複雜權限、大量資料處理,或預期要長期演進與維護的系統。

上線之後

上線後誰負責維護

上線後的工作包括既有功能修復、系統與憑證更新、以及新需求開發。我們會在一開始就約定維護範圍與回應方式,把界線講清楚。

常見的維護節奏是按季度檢查依賴項目與作業系統版本。如果產品需要持續加功能,也可以改用固定的迭代週期,把設計、開發與驗收排進同一個節奏裡。

兩種常見的合作方式

按季度檢查與修復 節奏穩定
固定迭代週期持續加功能 產品演進
界線先講清楚,後面才好配合 我們的作法

維護範圍、回應方式與費用會在合作開始前寫進同一份說明,避免上線後才臨時協調。

合作範圍

你們不做哪些工作

我們不做社群代操、廣告投放與大量行銷素材製作。這些工作需要不同的節奏與專業,硬接對雙方都不好。

我們的範圍集中在產品本身:流程、介面、資料與上線後的穩定度。如果你的需求橫跨這兩邊,我們可以協助界定哪部分適合找我們、哪部分找其他夥伴。

我們負責的部分

  • 產品流程與資訊架構規劃
  • 介面設計與設計系統
  • App 與網站開發、上線交付
  • 上線後的維護與後續版本

開始合作

怎麼開始合作

第一次聯繫不需要準備完整規格書。把你目前的做法、遇到的卡點、希望什麼時候能用,大概講一遍就夠了。我們會根據這些資訊判斷適合從哪個階段切入。

如果有現成的設計稿、舊系統或參考產品,也可以一併提供。接著我們會說明需要哪些資料才能給出可行的排期,再決定下一步。

目前的做法與遇到的卡點 最重要
希望什麼時候能用 影響排期
現有設計稿、舊系統或參考產品 有就提供
沒有規格書也沒關係,先聊現況就好 放心

直接聯絡

把你的情況寄給我們,或到聯絡頁填寫需求,我們會依你的狀況回覆下一步。

Equator 數碼產品工作室

Almatı şehri, Abay caddesi, 143, ofis 2

+852 2141 0206

[email protected]

週一至週五 09:00–18:00

其他常見疑問

合作前還會被問到的幾件事

設計稿要交到什麼程度

設計會做到開發可以直接照著實作的程度:元件狀態、間距規則、字體層級與雙語長度都會標明。若你只需要設計而不需要開發,也可以只交付設計與設計系統說明。

過程中要開幾次會

視階段而定,需求整理與設計評審通常需要較密集的討論,開發階段則以階段交付與書面回饋為主。開會頻率會在一開始約定,避免佔用雙方過多時間。

程式碼與設計檔案最後歸誰

合作結束後,專案程式碼與設計檔案會交付給你,包含必要的建置與部署說明。這也是為什麼我們在專案一開始就把版本控制與檔案整理方式講清楚。

如果專案中途要調整方向

調整方向在專案裡很常見。我們會在每個階段結束時確認範圍,把變更寫成新的工作項目與排期,而不是讓它默默吃掉後面的時間。

如果你的問題不在這一頁,直接到聯絡頁提出即可,我們會依你的情況回覆。