Nếu hệ thống web được làm đúng ngay từ đầu — nghiệp vụ nằm ở máy chủ, có API riêng — thì việc thêm app sau này chỉ là thêm một lớp hiển thị, chi phí bằng khoảng 50–70% so với làm app độc lập và thời gian 6–10 tuần. Nếu hệ thống cũ để logic rải trong giao diện, không có API, thì phải bọc lại toàn bộ phần nghiệp vụ trước, chi phí tăng 40–70% và thời gian gấp đôi. Đây là lý do câu hỏi "sau này thêm app được không" đáng được hỏi trước khi ký hợp đồng, không phải sau khi bàn giao.
Câu trả lời ngắn
| Tình huống | Cần làm gì | Chi phí tương đối | Thời gian |
|---|---|---|---|
| Có API sẵn, tách nghiệp vụ | Chỉ xây app gọi API | 50–70% so với app độc lập | 6–10 tuần |
| Có API nhưng thiếu/sơ sài | Bổ sung API, chuẩn hoá xác thực, rồi xây app | 80–110% | 8–14 tuần |
| Không có API, logic nằm trong giao diện | Bóc tách nghiệp vụ, xây API, rồi xây app | 130–170% | 12–20 tuần |
| Dữ liệu không tách được khỏi web cũ | Gần như làm lại phần lõi | 180%+ | 16–24 tuần |
Con số "so với app độc lập" lấy mốc là giá app iOS + Android niêm yết tại bảng giá. Điều quan trọng không phải con số chính xác, mà là khoảng cách 2–3 lần giữa trường hợp tốt nhất và xấu nhất — và khoảng cách đó được quyết định từ ngày đầu của dự án web.
Vì sao câu hỏi này xuất hiện gần như ở mọi dự án
Trong thực tế, rất ít doanh nghiệp đặt web quản lý rồi dừng lại. Sau 6–12 tháng vận hành, ba áp lực thường xuất hiện:
- Nhân viên đi hiện trường (giao hàng, kỹ thuật, tư vấn tại nhà, kiểm kho) cần dùng điện thoại, không mang laptop.
- Khách hàng quen muốn tra đơn, xem điểm, đặt lại — và họ mở điện thoại trước tiên.
- Quản lý muốn xem số liệu trên điện thoại thay vì mở máy tính.
Không có app, doanh nghiệp thường xử lý tạm bằng ba cách: nhân viên chụp ảnh rồi gửi Zalo, dùng Google Sheet ngoài hệ thống, hoặc dùng web trên điện thoại (nhưng web quản lý nhiều cột thì thao tác rất mệt trên màn hình nhỏ). Cả ba cách đều tạo ra dữ liệu nằm ngoài hệ thống — và đó là vấn đề lớn hơn việc thiếu app.
Cùng một máy chủ, hai lớp hiển thị
Cách hiểu đúng về kiến trúc: app không phải một hệ thống mới, nó là một giao diện khác của cùng một hệ thống.
Web quản lý (trình duyệt) App iOS / Android
\ /
\ /
→ API (máy chủ) ←
|
Cơ sở dữ liệu + nghiệp vụ
Ba nguyên tắc quyết định mọi thứ:
- Nghiệp vụ ở máy chủ. Kiểm tra tồn kho, tính giá, tính hoa hồng, phân quyền — tất cả phải chạy ở máy chủ. Giao diện chỉ hiển thị và gửi yêu cầu.
- Một nguồn dữ liệu duy nhất. Không có "kho của web" và "kho của app". Nếu có hai nguồn, sớm muộn cũng lệch.
- Xác thực bằng token. App không dùng cookie phiên như trình duyệt; dùng token có thời hạn và có cơ chế làm mới.
Nếu ba nguyên tắc này được tôn trọng từ đầu, việc thêm app gần như chỉ là công việc giao diện. Nếu không, mỗi màn hình app sẽ phải "sao chép" một phần logic từ web — và từ đó, hai bên bắt đầu lệch nhau.
Một ví dụ để thấy khác biệt
Giả sử hệ thống có nghiệp vụ "tính hoa hồng đối tác". Cách làm thường thấy ở hệ thống khó nâng cấp: công thức tính nằm trong trang web báo cáo hoa hồng, đọc dữ liệu đơn hàng từ cơ sở dữ liệu rồi cộng trừ ngay trong mã nguồn của trang đó.
Khi cần thêm app, mọi chuyện trở nên khó:
- App phải tự viết lại công thức hoặc gọi một trang web trả về HTML — cả hai đều dở.
- Nếu chính sách hoa hồng thay đổi, phải sửa ở hai nơi, và hai nơi sẽ lệch nhau trong vài tháng đầu.
- Không thể phân quyền chặt: gọi trang web báo cáo nghĩa là trả về toàn bộ dữ liệu của trang đó.
- Không có cách nào kiểm tra "ai được xem hoa hồng của ai" nếu kiểm tra đó đang nằm ở giao diện.
Cách làm ở hệ thống nâng cấp được: công thức hoa hồng nằm trong một hàm nghiệp vụ duy nhất ở tầng máy chủ. Web gọi hàm đó qua API; app cũng gọi đúng hàm đó. Chính sách thay đổi thì sửa một chỗ, cả hai bên cùng đúng. Phân quyền kiểm tra ở máy chủ, giao diện chỉ hiển thị.
Chi phí của hai cách làm này gần như bằng nhau ở thời điểm xây dựng. Chênh lệch chỉ xuất hiện khi cần thêm app — và khi đó, khoảng cách là 2–3 lần chi phí.
Bảo mật khi mở API cho app
Mở API ra ngoài cho app dùng là thay đổi về bề mặt tấn công. Sáu điểm cần làm đúng, ở mức tối thiểu:
| Điểm | Cần làm | Nếu bỏ qua |
|---|---|---|
| Xác thực | Token có hạn, có cơ chế làm mới, thu hồi được theo thiết bị | Token bị lộ là mất toàn bộ dữ liệu |
| Phân quyền | Kiểm tra ở máy chủ theo vai trò và hành động, không theo màn hình | App có thể gọi được API ngoài phạm vi người dùng |
| Giới hạn truy cập | Giới hạn số yêu cầu theo tài khoản và theo thiết bị | Bị dò mật khẩu hoặc lạm dụng tài nguyên |
| Ghi log | Ghi lại ai gọi gì, khi nào, từ thiết bị nào | Không truy được khi có sự cố |
| Dữ liệu trả về | Chỉ trả đúng trường cần thiết, không trả toàn bộ bản ghi | Lộ giá vốn, lộ thông tin khách |
| Phiên bản API | Đặt phiên bản ngay từ đầu (v1, v2) | Bản app cũ trên máy người dùng bị hỏng khi API đổi |
Điểm cuối cùng hay bị bỏ qua nhất. Khi đã có app trên store, không phải mọi người dùng đều cập nhật. Nếu API thay đổi mà không giữ phiên bản cũ, những bản app cũ sẽ lỗi hàng loạt. Vì vậy cần chấp nhận chạy song song hai phiên bản API trong một thời gian chuyển tiếp.
Bảy điểm phải làm đúng ngay từ đầu dự án web
Đây là danh sách dành cho người đang chuẩn bị đặt làm hệ thống web (chưa làm). Mỗi điểm đều rẻ nếu làm sớm và đắt nếu làm muộn.
1. Tách nghiệp vụ khỏi giao diện ngay từ đầu
Nếu đội phát triển đặt câu hỏi "tính toán này đặt ở đâu", câu trả lời luôn là: ở tầng nghiệp vụ, không ở trang hiển thị. Đây là điểm khác biệt lớn nhất giữa hệ thống nâng cấp được lên app và hệ thống phải làm lại.
2. Thiết kế API cùng lúc với web, không phải sau
Ngay cả khi chưa có app, mọi thao tác của web nên đi qua API nội bộ. Khi đó API đã được kiểm chứng bằng chính người dùng web — và app dùng lại được ngay.
3. Đừng để giới hạn phân quyền gắn với "trang web"
Phân quyền phải theo vai trò và hành động (xem đơn, sửa đơn, duyệt chiết khấu), không theo "màn hình số 3 của web". Nếu gắn với màn hình, khi làm app bạn sẽ phải định nghĩa lại toàn bộ.
4. Thông báo đẩy cần được tính từ đầu
App có một thứ web không có: thông báo đẩy. Nhưng nó không tự xuất hiện. Hệ thống cần một bảng hàng đợi thông báo ngay từ đầu (ai nhận, loại gì, khi nào, đã gửi chưa). Nếu web chưa có bảng này, khi làm app sẽ phải thêm và sửa lại các luồng nghiệp vụ để phát sinh thông báo.
5. Ghi nhận thiết bị và phiên đăng nhập
Một tài khoản có thể đăng nhập nhiều thiết bị. Cần ghi được: thiết bị nào, đăng nhập lúc nào, lần hoạt động cuối, và có thu hồi được không. Đây là yêu cầu bảo mật, và cũng là yêu cầu vận hành (nhân viên nghỉ việc thì phải khoá được ngay).
6. Dùng mã định danh ổn định
App lưu dữ liệu tại máy để chạy nhanh và chạy khi mất mạng. Nếu mã đơn hàng hay mã sản phẩm bị đổi, dữ liệu tại máy sẽ trỏ sai. Cần dùng mã không đổi (UUID hoặc số tự tăng) và không tái sử dụng mã đã xoá.
7. Viết tài liệu API và trao quyền sở hữu
Điều khoản hợp đồng nên ghi rõ: tài liệu API là một phần của sản phẩm bàn giao, và doanh nghiệp có quyền dùng API đó cho app của mình. Không có tài liệu API, đơn vị làm app sau sẽ phải đọc ngược mã nguồn — chi phí tăng và rủi ro hiểu sai nghiệp vụ rất cao.
Nếu hệ thống đã chạy rồi mới nghĩ đến app: 5 bước
Đây là trường hợp phổ biến nhất. Thứ tự dưới đây quan trọng: đừng bắt đầu bằng việc thiết kế màn hình app.
Bước 1 — Kiểm kê xem nghiệp vụ đang nằm ở đâu
Chọn 3 luồng quan trọng nhất (ví dụ: tạo đơn, kiểm kho, tính hoa hồng) và trả lời: phần tính toán nằm ở đâu? Nếu nằm trong trang web, đó là việc phải xử lý trước tiên.
Bước 2 — Xác định phần nào app cần
Không phải toàn bộ hệ thống cần lên app. Một app tốt thường chỉ cần 5–12 chức năng cốt lõi. Bảng dưới giúp chọn:
| Nhóm chức năng | Web quản lý | App nhân viên | App khách |
|---|---|---|---|
| Nhập liệu tại hiện trường, chụp ảnh | Khó | Cần | Không |
| Quét mã vạch, kiểm kho | Được | Cần | Không |
| Tra đơn, trạng thái đơn | Được | Cần | Cần |
| Đặt hàng, đặt lịch | Được | Không | Cần |
| Thông báo đẩy, nhắc hẹn | Không có | Cần | Cần |
| Báo cáo, cấu hình, phân quyền chi tiết | Cần | Không | Không |
| Duyệt chiết khấu, sửa giá | Cần | Không | Không |
Nguyên tắc: việc cấu hình và duyệt để trên web; việc làm nhanh, làm tại chỗ để trên app.
Bước 3 — Bổ sung API cho đúng phần app cần
Không cần làm API cho mọi thứ. Chỉ cần API cho những chức năng đã chọn ở bước 2, nhưng làm đúng chuẩn: xác thực, phân quyền, phân trang, xử lý lỗi rõ ràng.
Bước 4 — Xây app trên nền API đó
Đây mới là bước giao diện. Vì nghiệp vụ đã ở máy chủ, app chỉ cần hiển thị và gọi. Thời gian bước này thường ngắn hơn bước 3.
Bước 5 — Chạy song song và đo
Cho một nhóm nhỏ dùng app 2–4 tuần song song với web, đo ba thứ: số thao tác phát sinh ngoài hệ thống còn không, thời gian xử lý một việc giảm bao nhiêu, và số lỗi nhập liệu. Nếu cả ba không cải thiện, vấn đề không nằm ở app.
Chi phí và thời gian thực tế
| Phạm vi | Chức năng | Thời gian | Mức giá tham khảo |
|---|---|---|---|
| App MVP trên API sẵn có | 1 nền tảng, 5–7 màn hình, đăng nhập, danh sách, form, thông báo đẩy | 4–6 tuần | từ 90 triệu |
| App nhân viên đầy đủ | iOS + Android, 8–14 màn hình, quét mã, chụp ảnh, offline nhẹ | 6–10 tuần | 90 – 150 triệu |
| App khách + API mở rộng | iOS + Android, 12–20 màn hình, tài khoản, đặt hàng/lịch, thanh toán, thông báo | 10–14 tuần | 150 – 220 triệu |
| Bọc API cho hệ thống cũ chưa có API | Bóc tách nghiệp vụ, chuẩn hoá xác thực, tài liệu API | 3–6 tuần | 40 – 90 triệu |
| Bàn giao lên store | Tài khoản, cấu hình, kiểm duyệt, xử lý bị từ chối | 1–3 tuần | trong phạm vi gói |
Ghi chú quan trọng: dòng "bọc API" là khoản phát sinh chỉ có ở hệ thống cũ. Nếu hệ thống được làm đúng từ đầu, dòng này bằng 0. Đây chính là khoản chênh lệch 2–3 lần đã nêu ở phần đầu.
Ngoài chi phí xây dựng, cần dự trù:
- Tài khoản Google Play: phí một lần cho tài khoản nhà phát triển.
- Apple Developer Program: phí hằng năm, bắt buộc để đăng app lên App Store.
- Bảo trì hằng năm: iOS và Android ra bản mới mỗi năm; app không cập nhật sẽ bị store cảnh báo hoặc ngừng hiển thị.
Bốn điều khoản hợp đồng nên có
Nếu bạn là người đặt làm hệ thống và nghĩ đến app trong tương lai, bốn điều khoản này đáng được đưa vào hợp đồng ngay từ đầu:
- Quyền sở hữu mã nguồn và API. Ghi rõ doanh nghiệp sở hữu mã nguồn, cơ sở dữ liệu và tài liệu API; đơn vị phát triển chỉ giữ quyền sử dụng cho mục đích bảo trì.
- Tài liệu API là sản phẩm bàn giao. Không phải "sẽ cung cấp khi cần". Có tài liệu mới có thể cho đơn vị khác làm app.
- Tài khoản App Store và Google Play đứng tên doanh nghiệp. Nếu đứng tên đơn vị phát triển, doanh nghiệp mất quyền kiểm soát app của chính mình.
- Đơn giá cho phần mở rộng. Ghi mức giá tham chiếu cho việc bổ sung API hoặc thêm màn hình, để việc nâng cấp sau này không phát sinh tranh cãi.
Điều 2 và 3 là hai điều khoản hay bị bỏ qua nhất, và cũng là hai điều khoản gây thiệt hại lớn nhất khi phải chuyển đơn vị.
Mười hiểu lầm thường gặp
- "App chỉ là web bọc lại (WebView)." Bọc web thì nhanh và rẻ, nhưng thao tác chậm, không dùng được thông báo đẩy đúng cách, và trải nghiệm không đủ tốt để người dùng mở lại. Chỉ phù hợp khi cần một bản có mặt trên store gấp.
- "Có app rồi thì không cần web." Vẫn cần: web là nơi cấu hình, duyệt, báo cáo chi tiết và làm việc trên màn hình lớn.
- "App tự đồng bộ với web." Không có tự động. Phải có API dùng chung và một nguồn dữ liệu duy nhất.
- "Làm app là làm lại từ đầu." Không, nếu hệ thống tách nghiệp vụ đúng. Làm lại từ đầu chỉ xảy ra khi logic nằm trong giao diện web.
- "App mobile dùng được cả iOS và Android với chi phí bằng một nền tảng." Flutter cho phép một mã nguồn, nhưng vẫn cần kiểm thử trên cả hai, và vẫn cần hai bộ tài khoản store.
- "Đăng lên store là xong." Store có quy trình kiểm duyệt, có chính sách thay đổi, và có thể từ chối. Cần dự trù 1–3 tuần và có phương án sửa.
- "App rồi sẽ tự có người dùng." App phải được đưa vào đúng quy trình làm việc. Nếu nhân viên vẫn phải nhập lại trên web, app sẽ bị bỏ sau vài tuần.
- "Xong app là hết chi phí." Có bảo trì hằng năm: iOS/Android ra bản mới, thư viện lỗi thời, chính sách store thay đổi.
- "Chỉ cần app cho quản lý xem báo cáo." Đây thường là nhu cầu nhỏ nhất. Nếu chỉ cần xem số liệu, một dashboard web responsive là đủ và rẻ hơn nhiều.
- "Làm app trước rồi làm web sau cũng được." Được, nhưng tốn hơn: app khó thay đổi nhanh hơn web, và mỗi lần sửa phải qua store.
Nên làm app nào trước?
| Bối cảnh | Nên làm trước | Vì sao |
|---|---|---|
| Nhân viên đi hiện trường nhiều | App nhân viên | Giảm thao tác ngoài hệ thống, dữ liệu về đúng một nơi |
| Khách quay lại thường xuyên, có tích điểm | App khách | Giữ chân, nhắc mua lại, giảm phụ thuộc Zalo |
| Khách mua một lần, giá trị lớn | Web trước | Không đủ tần suất dùng để biện minh cho app |
| Quản lý chỉ cần xem số liệu | Dashboard responsive | Rẻ nhất, không cần store |
| Có cả hai nhu cầu | App nhân viên trước | Hiệu quả vận hành đến trước, app khách đến sau |
Lý do xếp app nhân viên trước: hiệu quả của app nhân viên đo được ngay trong tháng đầu (giảm thao tác, giảm sai sót), còn app khách cần thời gian để có người dùng và cần nội dung, chương trình phía sau.
Liên quan
- Thiết kế App Mobile — phạm vi, gói và thời gian
- Chi phí làm app mobile — bóc tách từng khoản
- Quy trình làm app mobile — 7 giai đoạn
- Nên làm app hay website trước — chọn thứ tự
- Phần mềm quản lý theo yêu cầu — cách chọn đơn vị làm
- Bảng giá