有了畫面，卻沒有背後那一塊？
App 或網站的畫面是有了，卻沒有一個能儲存和讀取資料的伺服器。就算有，使用者一多就變慢、資料開始打結、權限開始外洩。後端這一塊，一開始設計錯了，日後往往得整個重寫。
我們會做什麼
-
API 設計與實作
做出 App 和網站要呼叫的 API。名稱和規則都定得一致，日後接上別的畫面也能直接沿用。
-
資料庫設計
把什麼資料、要怎麼儲存的結構定下來。一開始定得好，資料就不會打結，規模變大也不會變慢。
-
登入與權限
註冊、登入，以及誰能做什麼的權限，都建立起來。這一塊就是為了擋住別人的資料被看到、被外洩。
-
為不斷增加的使用者做準備
不管現在是十個人用還是一萬個人用，都設計成撐得住。會先看出哪裡會成為瓶頸，也把費用控制在不會突然暴增的範圍。
你會拿到的東西
有哪些 API、資料是怎麼儲存的、伺服器和金鑰放在哪裡，都寫成文件留下。整理成前端開發者或下一個接手的人就算不懂伺服器，也能接上去的形式。
這樣開始
-
說說需要什麼
告訴我們是要做哪個服務的背後、要儲存哪些資料、要呼叫哪些功能。
-
設計與報價
先把資料結構和 API 清單定下來，再把範圍、費用、時程整理給你。
-
開發、串接、交付
依談定的範圍做好、接到 App 或網站上，並連同文件一起交給你。
適合這樣的地方
- 畫面已經做好、卻還需要一個在背後運作的伺服器的團隊
- 使用者變多後，現有伺服器開始變慢或打結的團隊
- 想把資料庫從一開始就好好設計的團隊
常見問題
- 這和第三方串接有什麼不同？
- 串接是把金流、通知這類已經存在的外部服務接上去；這項服務則是為你新建一個儲存並處理自家資料的自有伺服器。
- 會用什麼技術來做？
- 不預先綁定。會就服務規模和之後的維護，挑出合適的那一種。優先選日後好找人接手的常見技術。
- 做好之後的維護也做嗎？
- 做。伺服器檢查、備份、安全性更新，都可以接著以網站維護交給我們。