Ký hợp đồng với công ty viết app không chỉ là mua một số màn hình và dòng code. Doanh nghiệp đang giao cho nhà cung cấp quyền tiếp cận quy trình, dữ liệu, tài khoản, hạ tầng và các quyết định có thể ảnh hưởng sản phẩm trong nhiều năm.
Rủi ro thường không xuất hiện ở buổi demo đầu tiên. Nó xuất hiện khi scope phát sinh, người phụ trách rời dự án, build không tái tạo được, store account do vendor đứng tên, dữ liệu không export được hoặc app lỗi sau bàn giao nhưng hợp đồng không nói ai chịu trách nhiệm.
Tóm tắt nhanh: Trước khi ký, hãy làm rõ outcome, SOW, đội ngũ, kiến trúc, quyền sở hữu, dữ liệu, bảo mật, nghiệm thu, thay đổi phạm vi, release store, bảo trì và exit plan. Mọi câu trả lời quan trọng phải được chuyển thành điều khoản, phụ lục hoặc deliverable có thể kiểm tra — không chỉ nằm trong proposal hoặc trao đổi miệng.
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 sở hữu trí tuệ, 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ế.
Trước khi so giá, hãy chuẩn hóa đầu bài
Không thể so sánh hai báo giá nếu mỗi nhà cung cấp đang hiểu một phạm vi khác nhau. Một bên có thể tính cả backend, admin, analytics và store submission; bên khác chỉ tính mobile client. Tổng tiền thấp hơn chưa chắc là phương án rẻ hơn.
- Vấn đề và nhóm người dùng chính.
- Outcome hoặc KPI cần thay đổi.
- Must-have, Should-have và Not now.
- Hệ thống, dữ liệu và vendor cần tích hợp.
- Thị trường, nền tảng và ràng buộc store.
- Mốc kinh doanh, ngân sách và người phê duyệt.
- Yêu cầu bảo mật, dữ liệu và vận hành.
Nếu đầu bài còn nhiều giả định, nên ký một giai đoạn discovery trước khi cam kết full build. Bài MVP app giúp xác định giả thuyết và thin slice cần kiểm chứng thay vì đưa mọi ý tưởng vào hợp đồng đầu tiên.
Checklist 10 câu hỏi cần hỏi
| # | Câu hỏi | Đầu ra cần thấy |
|---|---|---|
| 1 | App giải quyết vấn đề nào và thành công được đo bằng gì? | Problem, target user, outcome, baseline và KPI |
| 2 | SOW bao gồm và loại trừ những gì? | Deliverable, scope, exclusions, assumption, dependency |
| 3 | Ai thực sự làm dự án và kiến trúc được chọn vì sao? | Team, role, availability, subcontractor, architecture decision |
| 4 | Ai sở hữu source, IP, dữ liệu, tài khoản và artifact? | IP schedule, repo/account ownership, open-source list |
| 5 | Dữ liệu và bảo mật được quản trị thế nào? | Data flow, processing terms, access, security requirements |
| 6 | Thiết kế, testing và nghiệm thu dựa trên tiêu chí nào? | Prototype, test plan, acceptance và Definition of Done |
| 7 | Timeline, thanh toán và change request vận hành ra sao? | Milestone, payment trigger, estimate, change control |
| 8 | Ai chịu trách nhiệm store, release và phí bên thứ ba? | Release RACI, store assets, vendor-cost register |
| 9 | Sau launch có bảo hành, SLA và incident support gì? | Warranty, maintenance scope, SLA và escalation |
| 10 | Nếu kết thúc hợp tác, doanh nghiệp nhận gì và chuyển giao thế nào? | Exit plan, assistance, export, access revocation |
1. App giải quyết vấn đề nào và thành công được đo bằng gì?
Nhà cung cấp không cần quyết định chiến lược thay doanh nghiệp, nhưng phải hiểu lý do dự án tồn tại. Nếu proposal chỉ lặp lại danh sách tính năng mà không chỉ ra người dùng, hành động cốt lõi và outcome, scope rất dễ phình ra nhưng không tạo giá trị.
- Persona hoặc vai trò nào được ưu tiên ở phiên bản đầu?
- Vấn đề hiện được giải quyết bằng quy trình nào?
- Activation hoặc hành động cốt lõi là gì?
- KPI dẫn dắt và KPI kết quả nào cần tracking?
- Điều gì không phải mục tiêu của dự án?
- Kết quả nào khiến doanh nghiệp mở rộng, điều chỉnh hoặc dừng?
Câu trả lời tốt không nhất thiết có một con số chắc chắn khi chưa có baseline, nhưng phải chỉ ra giả định, cách đo và người quyết định. Tránh cam kết tăng trưởng hoặc tiết kiệm cố định nếu chưa có dữ liệu chứng minh.
2. SOW bao gồm và loại trừ những gì?
SOW — Statement of Work — cần mô tả deliverable và boundary của dự án. Cụm từ “xây app bán hàng” không đủ để xác định backend, admin, role, API, migration, analytics, store listing hoặc hỗ trợ sau launch.
| Phần cần khóa | Ví dụ |
|---|---|
| Client | iOS, Android, web, tablet; version OS và device scope |
| Backend | API, service, database, queue và business rule |
| Admin | Role, module, approval và audit |
| Integration | Payment, CRM, ERP, POS, map, SMS, identity |
| Data | Migration, cleansing, import/export và ownership |
| Design | Research, flow, wireframe, UI, design system và microcopy |
| Quality | Test layer, device matrix, security và performance |
| Release | Beta, store assets, submission, rollback và monitoring |
| Operations | Support, training, documentation và warranty |
| Exclusions | Third-party license, content entry, legal review hoặc hardware |
Mỗi assumption cần người xác nhận và ngày kiểm tra. Ví dụ, “API ERP đã sẵn sàng” phải được kiểm chứng bằng tài liệu, sandbox và owner; nếu không, timeline chỉ là ước tính dựa trên giả định chưa biết.
3. Ai thực sự làm dự án và kiến trúc được chọn vì sao?
Tên công ty và portfolio không cho biết ai sẽ làm dự án hằng ngày. Doanh nghiệp cần biết vai trò, mức tham gia, người thay thế và phần nào được giao cho subcontractor.
- Product/BA, UX/UI, mobile, backend, QA, DevOps và security owner là ai?
- Senior/lead tham gia ở giai đoạn nào và bao nhiêu capacity?
- Có subcontractor hoặc freelancer không; ai chịu trách nhiệm chất lượng và bảo mật?
- Nếu nhân sự chính nghỉ, knowledge transfer và replacement diễn ra thế nào?
- Kiến trúc và tech stack có decision record, trade-off và constraint nào?
- Doanh nghiệp có quyền phỏng vấn hoặc phê duyệt vai trò chủ chốt không?
Không có công nghệ luôn tốt nhất. Native, cross-platform, modular monolith hay microservices cần được chọn theo use case, đội ngũ, hiệu năng, integration và chi phí vận hành. Tham khảo Native hay Cross-Platform để hiểu các trade-off chính.
4. Ai sở hữu source code, IP, dữ liệu và tài khoản?
“Bàn giao source code” chưa đủ. Hợp đồng cần tách rõ phần code tùy biến, IP nền của vendor, mã nguồn mở, thư viện thương mại, thiết kế, nội dung, dữ liệu, model, tài liệu và quyền sử dụng sau khi kết thúc.
| Tài sản | Điều cần ghi |
|---|---|
| Custom source code | Quyền sở hữu/chuyển giao hoặc phạm vi license và thời điểm có hiệu lực |
| Vendor background IP | Phần vendor giữ và quyền sử dụng lâu dài của doanh nghiệp |
| Open-source | Danh sách component, version, license và nghĩa vụ |
| Commercial SDK | Chủ tài khoản, phí, giới hạn và khả năng thay thế |
| Design/content | Figma, asset, font, media license và editable file |
| Data | Quyền kiểm soát, export, retention, xóa và format bàn giao |
| Accounts | Git, cloud, domain, store, analytics, push và vendor account |
| Keys/secrets | Signing key, certificate, token và quy trình thu hồi |
| Documentation | Architecture, API, schema, runbook, build và known issues |
Pháp luật sở hữu trí tuệ Việt Nam bảo hộ chương trình máy tính theo cơ chế quyền tác giả; quyền và thỏa thuận liên quan cần được ghi rõ cho dự án cụ thể. Có thể tham khảo hệ thống văn bản tại WIPO Lex — Luật sửa đổi Luật Sở hữu trí tuệ 2022, sau đó nhờ cố vấn rà soát điều khoản áp dụng.
5. Dữ liệu và bảo mật được quản trị thế nào?
NDA không thay thế điều khoản xử lý dữ liệu và security requirements. Khi vendor truy cập dữ liệu, log, production hoặc hệ thống khách hàng, hợp đồng cần xác định vai trò, mục đích, phạm vi, quyền truy cập, bên thứ ba và cách xử lý khi có sự cố.
- Data inventory và data flow có được lập không?
- Vendor được dùng dữ liệu production cho development/test không?
- Ai được truy cập production, theo cơ chế nào và review bao lâu một lần?
- Subprocessor/SDK/cloud nào xử lý dữ liệu?
- Secret, source, artifact và log được bảo vệ ra sao?
- Vulnerability, incident và thông báo được xử lý theo quy trình nào?
- Khi chấm dứt, dữ liệu được trả/xóa và quyền được thu hồi thế nào?
Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 là một nguồn cần được 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ủ. Phạm vi và nghĩa vụ cụ thể phải được xác định theo vai trò thực tế của các bên.
Yêu cầu kỹ thuật nên gắn với risk assessment và Definition of Done. Có thể đối chiếu checklist bảo mật ứng dụng di động.
6. Thiết kế, testing và nghiệm thu dựa trên tiêu chí nào?
Hợp đồng không nên dùng các tiêu chí mơ hồ như “giao diện đẹp”, “chạy ổn” hoặc “giống mô tả”. Mỗi deliverable cần acceptance criteria, môi trường test, bằng chứng và người có quyền chấp nhận.
| Lớp | Ví dụ acceptance |
|---|---|
| UX/UI | Flow, component, responsive state, error/empty/loading và số vòng review |
| Functional | User story, business rule, role và negative case |
| Integration | Contract, retry, timeout, error mapping và sandbox/production |
| Quality | Device/OS matrix, blocker threshold, regression và performance |
| Security/privacy | Authorization, storage, data flow, permission và finding threshold |
| Analytics | Event name, parameter, source và dashboard validation |
| Release | Build, signing, store assets, monitoring và rollback |
| Handover | Source, account, docs, training và build reproduction |
Testing cần phân biệt vendor QA, UAT của doanh nghiệp và beta với tester. TestFlight và Google Play testing tracks là kênh phân phối build; chúng không tự thay thế test plan. Xem setup TestFlight và Google Play Internal Testing.
7. Timeline, thanh toán và change request vận hành ra sao?
Timeline nên gắn với dependency và acceptance, không chỉ ngày tháng. Payment milestone cũng không nên kích hoạt chỉ vì “đã hết tháng” nếu deliverable chưa được bàn giao theo tiêu chí.
| Điểm cần khóa | Câu hỏi |
|---|---|
| Milestone | Đầu ra, ngày dự kiến và dependency nào? |
| Payment trigger | Thanh toán khi deliverable nào được chấp nhận? |
| Review window | Khách hàng có bao nhiêu ngày để phản hồi? |
| Delay | Chậm do khách hàng, vendor hoặc bên thứ ba được xử lý thế nào? |
| Change request | Ai yêu cầu, ai phê duyệt, impact được estimate ra sao? |
| Reprioritization | Đổi scope trong cùng ngân sách có được không? |
| Rework | Sai acceptance khác thay đổi yêu cầu thế nào? |
| Termination | Dừng giữa chừng thanh toán và bàn giao theo tiến độ nào? |
Change request cần có mô tả, lý do, impact tới scope–timeline–chi phí–risk và phê duyệt trước khi làm. Không để mọi thay đổi qua chat rồi tranh luận cuối dự án.
8. Ai chịu trách nhiệm store, release và phí bên thứ ba?
Phát hành app gồm nhiều phần hơn upload build: account, signing, metadata, screenshot, privacy declaration, review notes, demo account, rollout, monitoring và phản hồi khi store hỏi.
- Apple Developer và Google Play Console đứng tên doanh nghiệp hay vendor?
- Ai chuẩn bị metadata, screenshot, privacy/Data safety và review notes?
- Nếu bị reject vì code, metadata, policy hoặc mô hình kinh doanh, trách nhiệm được phân loại thế nào?
- Ai giữ signing key/certificate và quyền release production?
- Ai theo dõi rollout, crash và rollback criteria?
- Phí cloud, SMS, map, payment, eKYC, AI, email, analytics và CMS do ai trả?
- Quota, minimum commitment, renewal và vendor lock-in được quản trị ra sao?
Money page chi phí đưa app lên Google Play và Apple Store sở hữu intent báo giá store; hợp đồng phát triển cần ghi rõ phần submission nào đã bao gồm và phần nào là dịch vụ riêng.
9. Sau launch có bảo hành, SLA và incident support gì?
Bảo hành thường xử lý sai lệch so với scope đã nghiệm thu. Bảo trì xử lý compatibility, dependency, production issue và cải tiến. Hai khái niệm cần tách rõ để tránh mọi lỗi bị gọi là change request hoặc mọi thay đổi bị gọi là bug.
- Thời hạn và điều kiện bảo hành là gì?
- Support hours và kênh incident nào được dùng?
- Severity được phân loại theo impact nào?
- Acknowledgement, response, restore và resolution target có tách riêng?
- Hotfix, store review, rollback và communication do ai phụ trách?
- OS/SDK/API update và security patch nằm trong gói nào?
- Monitoring, report và service review được cung cấp ra sao?
Đối chiếu các gói bảo trì và nâng cấp app để lập operating model sau bàn giao trước khi app lên production.
10. Nếu kết thúc hợp tác, doanh nghiệp nhận gì?
Exit plan không phải dấu hiệu thiếu tin tưởng; nó là control liên tục kinh doanh. Một dự án có thể kết thúc vì hoàn thành, đổi chiến lược, thay vendor hoặc một bên vi phạm. Trong mọi trường hợp, tài sản và quyền truy cập cần được xử lý có trật tự.
- Source và lịch sử Git đến thời điểm nào?
- Build có thể tái tạo bằng tài khoản doanh nghiệp không?
- Dữ liệu được export ở format nào và kiểm tra tính toàn vẹn ra sao?
- Tài liệu kiến trúc, API, schema, runbook và known issues có đầy đủ?
- Vendor có hỗ trợ knowledge transfer cho đội mới trong bao lâu?
- Quyền, token, certificate và account của nhân sự/vendor được thu hồi thế nào?
- License hoặc dịch vụ nào không thể chuyển giao?
- Công việc đang dở, bug và risk được bàn giao bằng evidence nào?
Ma trận so sánh nhà cung cấp không dùng điểm số giả
Không nên cộng điểm 1–5 rồi để tổng điểm thay quyết định. Một nhà cung cấp có portfolio đẹp nhưng không chấp nhận ownership rõ hoặc không có security process có thể không phù hợp dù điểm trung bình cao. Hãy dùng hard gate trước, sau đó mới so trade-off.
| Tiêu chí | Hard gate | Evidence | Trade-off |
|---|---|---|---|
| Scope/acceptance | SOW đủ rõ | Sample SOW, backlog, acceptance | Mức discovery cần thêm |
| Ownership | Tài sản lõi thuộc doanh nghiệp hoặc license đủ dùng | IP schedule, account model | Vendor background IP |
| Team | Có owner và capacity | Team plan, interview, replacement | Onsite/remote, seniority |
| Security/data | Control và trách nhiệm rõ | Policy, checklist, incident process | Phạm vi audit/pentest |
| Quality/release | Có test evidence và release process | Test plan, CI/CD, sample report | Tốc độ và mức automation |
| Operations | Có handover/exit | Runbook, SLA, support model | Retainer hoặc theo giờ |
| Economics | Tổng chi phí minh bạch | Estimate, vendor cost, assumptions | Fixed price, T&M hoặc capacity |
Dấu hiệu nên dừng ký để làm rõ
- Không cung cấp 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 subcontractor hoặc đội thực hiện.
- Cam kết ngày và giá cố định dù dependency chưa được kiểm tra.
- Không có security/data-processing requirement dù truy cập dữ liệu.
- Testing chỉ được mô tả là “vendor tự test”.
- Store/cloud/repo bắt buộc đứng tên vendor mà không có exit mechanism.
- Change request và payment trigger không rõ.
- Không có warranty, support hoặc handover plan.
- Dùng lời hứa tăng trưởng, bảo mật hoặc scale tuyệt đối thay cho evidence.
Bộ tài liệu nên đính kèm hợp đồng
- Business/Product brief và scope guardrail.
- SOW, deliverable, exclusions và assumptions.
- Milestone, payment schedule và change-control process.
- Architecture/technology decision và dependency register.
- IP, open-source, account và asset schedule.
- Data-processing/security schedule.
- UX/UI, testing, acceptance và Definition of Done.
- Release/store RACI và third-party-cost register.
- Warranty, maintenance, SLA và incident process.
- Handover, exit assistance và access-revocation checklist.
Cần rà soát brief và scope trước khi ký?
WebsiteHCM có thể hỗ trợ discovery, bóc tách MVP, SOW kỹ thuật, architecture, testing, release và kế hoạch bàn giao. Điều khoản pháp lý cuối cùng nên được cố vấn của doanh nghiệp rà soát.
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. Hãy chuẩn hóa deliverable, ownership, testing, release, support và third-party cost rồi mới so mô hình giá.
Source code có mặc định thuộc doanh nghiệp không?
Không nên dựa vào giả định. Hợp đồng phải ghi rõ quyền với custom code, vendor IP, open-source, thiết kế và tài liệu, cùng thời điểm bàn giao hoặc chuyển quyền. Cần tư vấn pháp lý cho điều khoản cụ thể.
Fixed price hay Time & Materials tốt hơn?
Fixed price phù hợp khi scope và acceptance đủ rõ. Time & Materials hoặc capacity phù hợp khi discovery và thay đổi còn lớn. Mô hình nào cũng cần governance, estimate và reporting.
Có cần ghi SLA ngay trong hợp đồng phát triển?
Cần ghi ít nhất cơ chế support trong giai đoạn build, warranty và sau launch. SLA production nên phản ánh giờ phục vụ, criticality và khả năng monitoring thực tế.
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ò. Trường hợp vendor tạm quản lý cần có lý do, giới hạn quyền, kế hoạch chuyển giao và exit mechanism rõ.
Kết luận
Một hợp đồng viết app tốt không loại bỏ mọi thay đổi, nhưng 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 chuyển mười câu hỏi về outcome, scope, team, ownership, dữ liệu, nghiệm thu, chi phí, release, support và exit thành tài liệu có thể kiểm tra. Khi đó doanh nghiệp không chỉ mua một bản build, mà xây nền tảng để sản phẩm tiếp tục vận hành và thay đổi mà không bị khóa vào một cá nhân hoặc nhà cung cấp.
Đ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ả.
