Trước khi ký hợp đồng với một công ty viết app, doanh nghiệp nên kiểm tra 10 nhóm vấn đề: outcome, phạm vi, đội ngũ, quyền sở hữu, dữ liệu/bảo mật, nghiệm thu, timeline/thanh toán, phát hành Store, bảo trì và exit plan. Mục tiêu không phải hỏi thật nhiều, mà là biến câu trả lời quan trọng thành SOW, phụ lục hoặc deliverable có thể kiểm tra. Nếu cần đối chiếu phạm vi thuê triển khai, xem thêm dịch vụ phát triển ứng dụng di động.
Trả lời nhanh: nếu vendor không làm rõ scope, ownership, acceptance, data/security và handover thì chưa nên ký chỉ vì giá thấp hoặc portfolio đẹp.
Lưu ý: Đây là checklist thương mại, sản phẩm và kỹ thuật; không thay thế tư vấn pháp lý. Điều khoản IP, dữ liệu, trách nhiệm, bồi thường và chấm dứt nên được người có chuyên môn rà soát theo pháp luật áp dụng và mô hình dự án thực tế.
Bộ hồ sơ nên có trước khi ký
- SOW và danh sách phần nằm ngoài phạm vi.
- Ma trận nghiệm thu cho chức năng, dữ liệu, tích hợp và phát hành.
- Danh sách tài khoản, mã nguồn, license và quyền sở hữu.
- Bản đồ dữ liệu, quyền truy cập và bên thứ ba tham gia xử lý.
- Danh sách chi phí cloud, SMS, bản đồ, thanh toán hoặc SDK.
- Kế hoạch bàn giao, đào tạo và chuyển sang đơn vị khác nếu cần.
Có bộ hồ sơ này trước khi hỏi giá giúp các báo giá được so trên cùng một phạm vi, đồng thời làm rõ việc nào cần đưa vào hợp đồng và việc nào phải báo riêng.
Checklist 10 câu hỏi cần hỏi trước khi ký
| # | Câu hỏi | Bằng chứng cần thấy | Red flag |
|---|---|---|---|
| 1 | App giải quyết vấn đề gì và thành công đo bằng gì? | Problem, target user, baseline, KPI | Chỉ có danh sách tính năng |
| 2 | SOW bao gồm và loại trừ những gì? | Deliverable, exclusions, assumptions, dependencies | Báo giá “trọn gói” nhưng scope mơ hồ |
| 3 | Ai thực sự làm dự án và chọn kiến trúc vì sao? | Team plan, role, capacity, architecture decision | Không rõ đội thực hiện/subcontractor |
| 4 | Ai sở hữu source, IP, dữ liệu và tài khoản? | IP schedule, repo/account ownership, license list | Store/cloud/repo bắt buộc đứng tên vendor |
| 5 | Dữ liệu và bảo mật được quản trị thế nào? | Data flow, access model, security requirement, incident process | Chỉ có NDA nhưng không có control |
| 6 | Nghiệm thu dựa trên tiêu chí nào? | Prototype, test plan, acceptance, Definition of Done | “Chạy ổn”, “giao diện đẹp” |
| 7 | Timeline, thanh toán và change request vận hành ra sao? | Milestone, payment trigger, review window, change control | Thanh toán chỉ theo ngày, không theo deliverable |
| 8 | Ai chịu trách nhiệm Store và phí bên thứ ba? | Release RACI, store asset list, vendor-cost register | Không rõ ai trả cloud/SMS/map/payment/SDK |
| 9 | Sau launch có bảo hành/SLA gì? | Warranty, maintenance scope, severity, escalation | Không có support hoặc định nghĩa bug |
| 10 | Nếu kết thúc hợp tác, doanh nghiệp nhận gì? | Exit plan, export, handover, access revocation | Không có cách chuyển vendor |
Trước khi so giá, hãy chuẩn hóa đầu bài
Hai báo giá chỉ so được khi cùng phạm vi. Một bên có thể tính cả backend, admin, analytics và Store submission; bên khác chỉ tính mobile client. Vì vậy, trước khi yêu cầu giá, hãy khóa tối thiểu các mục sau. Nếu cần xem cách lập ngân sách, tham khảo chi phí viết app, nhưng vẫn phải đối chiếu lại theo SOW thực tế.
| Đầu bài | Cần nêu rõ |
|---|---|
| Người dùng & outcome | Ai dùng, job chính, KPI cần thay đổi |
| Phạm vi | Must-have, not-now, backend/admin, integration |
| Dữ liệu | Source of truth, migration, privacy, access |
| Nền tảng | iOS/Android/web, device/OS, Store |
| Ràng buộc | Ngân sách, mốc kinh doanh, compliance, bảo mật |
| Vận hành | Support, maintenance, owner sau launch |
Nếu đầu bài còn nhiều giả định, nên làm discovery hoặc MVP trước khi cam kết full build. Xem MVP app.
4 điều phải ghi rõ trong hợp đồng
| Nhóm | Cần khóa |
|---|---|
| Scope & acceptance | Deliverable, exclusions, assumptions, test evidence, người phê duyệt |
| Ownership & accounts | Custom source, vendor IP, open-source, Figma, data, Git, cloud, Store, signing key |
| Change & payment | Milestone, payment trigger, review window, delay, change request |
| Handover & exit | Source, build reproduction, data export, docs, training, revoke access |
Với sở hữu trí tuệ, không nên giả định “bàn giao source” đồng nghĩa mọi quyền mặc định thuộc doanh nghiệp. Hợp đồng cần ghi rõ quyền với custom code, vendor background IP, open-source và license thương mại. Có thể tham khảo hệ thống văn bản tại WIPO Lex và nhờ cố vấn pháp lý rà điều khoản áp dụng.
Dữ liệu và bảo mật: hỏi gì là đủ?
| Câu hỏi | Điều cần có |
|---|---|
| Vendor được truy cập dữ liệu nào? | Data inventory + purpose + access owner |
| Có dùng production data cho test không? | Rule rõ, masking/anonymization khi cần |
| Ai truy cập production? | Role, approval, log, review định kỳ |
| Có bên thứ ba nào xử lý dữ liệu? | Danh sách SDK/cloud/subprocessor |
| Khi có sự cố? | Incident process + escalation + evidence |
| Khi chấm dứt? | Export/xóa dữ liệu + thu hồi quyền |
Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 là một nguồn cần rà soát khi dự án xử lý dữ liệu cá nhân tại Việt Nam; văn bản chính thức có tại Cổng thông tin văn bản Chính phủ. Nghĩa vụ cụ thể phụ thuộc vai trò thực tế của các bên.
Về kỹ thuật, có thể đối chiếu checklist bảo mật ứng dụng di động.
Nghiệm thu và release nên khóa thế nào?
| Lớp | Ví dụ acceptance |
|---|---|
| UX/UI | Flow, component, loading/error/empty state |
| Functional | User story, business rule, negative case |
| Integration | Contract, timeout, retry, error mapping |
| Quality | Device/OS matrix, blocker threshold, regression |
| Security/privacy | Authorization, storage, data flow, permission |
| Release | Build, signing, store asset, monitoring, rollback |
| Handover | Source, account, docs, training, build reproduction |
Testing cần phân biệt vendor QA, UAT và beta distribution. TestFlight/Google Play testing tracks chỉ là kênh phân phối build, không thay thế test plan. Để xem các giai đoạn phát triển và đầu ra tương ứng, tham khảo quy trình phát triển ứng dụng di động. Xem thêm TestFlight và Google Play Internal Testing.
Dấu hiệu nên dừng ký để làm rõ
- Không có SOW, exclusions hoặc acceptance criteria.
- Né tránh quyền sở hữu source, account hoặc dữ liệu.
- Không công khai đội thực hiện/subcontractor.
- Cam kết giá/ngày cố định dù dependency chưa kiểm tra.
- Không có security/data-processing requirement dù truy cập dữ liệu.
- Không có warranty, support, handover hoặc exit plan.
Câu hỏi thường gặp
Có nên chọn báo giá app thấp nhất không?
Không nên so tổng tiền khi scope khác nhau. Chuẩn hóa deliverable, ownership, testing, release, support và third-party cost rồi mới so giá.
Fixed price hay Time & Materials tốt hơn?
Fixed price phù hợp khi scope/acceptance đủ rõ. Time & Materials phù hợp hơn khi discovery và thay đổi còn lớn. Mô hình nào cũng cần governance, estimate và reporting.
Có nên để vendor đứng tên Store và cloud?
Tài khoản lõi nên do doanh nghiệp sở hữu và cấp quyền theo vai trò. Nếu vendor tạm quản lý, cần giới hạn quyền, thời hạn và cơ chế chuyển giao rõ.
Kết luận
Một hợp đồng viết app tốt không loại bỏ mọi thay đổi; nó làm rõ cách hai bên xử lý thay đổi, trách nhiệm và bằng chứng. Trước khi ký, hãy khóa outcome, scope, team, ownership, dữ liệu, acceptance, chi phí, release, support và exit plan.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.