Hợp Đồng Phần Mềm: 5 Điều Khoản Tôi Luôn Thêm Để Bảo Vệ Cả Hai Bên

Năm 2022, tôi hoàn thành một dự án phần mềm quản lý cho chuỗi spa. Phần mềm chạy tốt, khách hàng hài lòng, thanh toán đủ. Mọi thứ tưởng hoàn hảo — cho đến 4 tháng sau khi khách gọi: "Anh Thanh, phần mềm bị lỗi module booking. Em yêu cầu anh sửa miễn phí vì còn trong bảo hành."

Vấn đề là: hợp đồng KHÔNG ghi rõ thời hạn bảo hành và phạm vi bảo hành. Khách nói "mặc định 1 năm", tôi hiểu "3 tháng sau bàn giao". Cuối cùng tôi sửa miễn phí vì muốn giữ mối quan hệ — nhưng bài học đó đắt giá.

Từ đó, mỗi hợp đồng tại Trinity Software đều có 5 điều khoản mà tôi coi là KHÔNG THỂ THIẾU. Bài viết này chia sẻ 5 điều khoản đó — dù bạn là khách hàng hay đội dev, bạn đều cần biết.

Tại Sao Hợp Đồng Phần Mềm Khác Hợp Đồng Thông Thường?

Phần mềm không giống mua bán hàng hóa. Nó có những đặc thù riêng:

• Sản phẩm vô hình: Không sờ được, không cân đo đong đếm được — dễ tranh cãi "đã hoàn thành chưa"
• Scope creep: Yêu cầu thay đổi liên tục trong quá trình phát triển — ai trả tiền cho phần thay đổi?
• Quyền sở hữu trí tuệ: Code do ai sở hữu? Khách có được chỉnh sửa không? Dev có được tái sử dụng không?
• Bảo trì sau bàn giao: Phần mềm cần được "nuôi" — ai chịu trách nhiệm?

Nếu hợp đồng không cover những điểm trên, xung đột là chắc chắn xảy ra. Và khi xung đột xảy ra mà không có văn bản rõ ràng, cả hai bên đều thiệt.

Điều Khoản #1: Quyền Sở Hữu Trí Tuệ (IP Ownership)

Đây là điều khoản quan trọng nhất mà 80% hợp đồng phần mềm tại Việt Nam bỏ qua hoặc ghi mập mờ.

Có 3 mô hình phổ biến:

Tại Trinity, tôi mặc định dùng mô hình Full Transfer: khách nhận toàn bộ source code, tài liệu kỹ thuật, và quyền sở hữu. Lý do: khách trả tiền cho sản phẩm — họ nên sở hữu nó. Điều này cũng giúp khách không bị "khóa" vào Trinity nếu muốn chuyển sang team khác bảo trì.

Ngoại lệ: Các thư viện open-source mà team sử dụng vẫn thuộc license gốc (MIT, Apache...). Và framework nội bộ của Trinity (nếu có sử dụng) vẫn thuộc Trinity — khách được quyền sử dụng nhưng không được bán lại framework đó.

Mẹo cho khách hàng: Hỏi rõ: "Sau khi thanh toán đủ, tôi có nhận được toàn bộ source code không? Tôi có được thuê người khác chỉnh sửa không?" Nếu câu trả lời là "không" — hãy cân nhắc kỹ.

Điều Khoản #2: Thanh Toán Theo Milestone

Đừng bao giờ thanh toán 100% trước. Cũng đừng yêu cầu dev làm xong mới trả tiền. Cả hai cách đều tạo rủi ro.

Mô hình thanh toán Trinity áp dụng: 30-30-30-10

• 30% khi ký hợp đồng: Để đội dev bắt đầu thiết kế, mua infrastructure
• 30% khi hoàn thành design + prototype: Khách review được giao diện, flow trước khi code
• 30% khi hoàn thành phát triển + UAT: Khách test hệ thống, report bug
• 10% sau bàn giao + chạy ổn định 2 tuần: Đảm bảo hệ thống không có lỗi critical trên production

Tôi đã chia sẻ chi tiết về mô hình thanh toán này trong bài Tôi Đã Báo Giá 50+ Dự Án — mô hình 30-30-30-10 bảo vệ cả hai bên: khách không mất tiền nếu dev bỏ ngang, dev không làm không công nếu khách hủy giữa chừng.

Điều kiện thanh toán kèm theo:

• Mỗi milestone phải có deliverables rõ ràng (ví dụ: "Bàn giao file Figma thiết kế 15 màn hình, khách duyệt trong 5 ngày làm việc")
• Quá hạn duyệt 10 ngày mà không phản hồi = mặc định chấp nhận (tránh trường hợp khách trì hoãn vô thời hạn)
• Hóa đơn xuất trong 3 ngày làm việc sau milestone — thanh toán trong 7 ngày

Điều Khoản #3: Quy Trình Thay Đổi Yêu Cầu (Change Request)

Nếu tôi phải chọn một điều khoản gây ra nhiều xung đột nhất, đó chính là Change Request. "Em muốn thêm 1 tính năng nhỏ" — câu này xuất hiện ở MỌI dự án. Và "nhỏ" theo khách hàng có thể là 2-3 tuần phát triển thêm.

Quy trình Change Request tại Trinity:

1. Khách gửi yêu cầu thay đổi bằng văn bản (email/Zalo) 2. Trinity đánh giá impact: thời gian, chi phí, ảnh hưởng đến timeline 3. Trinity gửi báo giá CR trong 3 ngày làm việc 4. Khách duyệt CR → ký phụ lục → bắt đầu phát triển 5. Nếu khách không duyệt → giữ nguyên scope ban đầu

Quan trọng: Hợp đồng phải ghi rõ bao nhiêu lần thay đổi nhỏ miễn phí (tôi thường cho 3-5 CR nhỏ dưới 4 giờ dev) và CR lớn tính phí như thế nào (thường theo man-day rate).

Không có điều khoản CR, bạn sẽ rơi vào tình huống: khách nghĩ "mọi thay đổi đều miễn phí vì nằm trong hợp đồng", dev nghĩ "mọi thay đổi đều tính thêm tiền." Kết quả: cãi nhau.

Điều Khoản #4: Bảo Hành & Bảo Trì

Đây chính là điều khoản mà tôi "quên" trong case spa năm 2022. Bây giờ, hợp đồng Trinity luôn phân biệt rõ:

Bảo hành (Warranty) — Miễn phí, có thời hạn: - Thời hạn: **3 tháng sau bàn giao** (hoặc 6 tháng tùy dự án) - Phạm vi: Sửa lỗi (bug) so với yêu cầu đã ký trong hợp đồng - KHÔNG bao gồm: Thay đổi tính năng, thêm tính năng mới, lỗi do khách tự chỉnh sửa code, lỗi do infrastructure bên thứ 3

Bảo trì (Maintenance) — Có phí, dài hạn: - Cập nhật bảo mật, nâng cấp framework - Thêm tính năng mới - Hỗ trợ kỹ thuật - Monitoring & backup

Sự khác biệt giữa hai khái niệm này rất quan trọng — tôi đã phân tích chi tiết trong bài Phần Mềm "Chết" Sau 6 Tháng Nếu Không Bảo Trì.

Điều Khoản #5: Bàn Giao Source Code & Tài Liệu

Bàn giao phần mềm KHÔNG CHỈ là "đưa link website". Hợp đồng phải liệt kê rõ những gì khách nhận được:

Mẹo quan trọng: Yêu cầu bàn giao qua Git repository — không phải file ZIP. Git lưu toàn bộ lịch sử thay đổi, giúp team bảo trì sau này hiểu được "tại sao code được viết như vậy." Và yêu cầu README file trong repo — hướng dẫn cách setup dự án từ zero.

Tôi đã gặp case khách hàng cũ nhận bàn giao bằng file ZIP từ một đội dev khác — không có document, không có README, không có comment trong code. Khi đưa cho Trinity maintain, team tôi mất 3 tuần chỉ để ĐỌC HIỂU code trước khi sửa được bất cứ thứ gì. Chi phí 3 tuần đó đắt hơn cả chi phí viết tài liệu ban đầu.

Template Checklist Hợp Đồng Phần Mềm

Trước khi ký bất kỳ hợp đồng phần mềm nào, hãy check:

• [ ] Scope of work rõ ràng (liệt kê tính năng, có wireframe/mockup kèm theo)
• [ ] Timeline với milestones cụ thể
• [ ] Thanh toán theo milestone (không trả 100% trước)
• [ ] Quyền sở hữu IP được ghi rõ
• [ ] Quy trình Change Request
• [ ] Thời hạn và phạm vi bảo hành
• [ ] Danh sách deliverables khi bàn giao
• [ ] Điều khoản bảo mật (NDA nếu cần)
• [ ] Điều khoản phạt hợp đồng (cả hai chiều)
• [ ] Quy trình giải quyết tranh chấp

Nếu hợp đồng thiếu 3+ mục trên, bạn đang đặt mình vào rủi ro. Điều này đúng cho cả khi bạn thuê freelancer hay công ty phần mềm.

Lời Kết

Hợp đồng tốt không phải để "bẫy" bên nào — mà để cả hai bên có kỳ vọng rõ ràng, tránh hiểu lầm, và có cơ sở giải quyết khi phát sinh vấn đề. Dự án phần mềm thành công bắt đầu từ hợp đồng rõ ràng.

Tại Trinity Software, tôi luôn sẵn sàng giải thích từng điều khoản cho khách hàng trước khi ký. Bởi tôi tin rằng: khách hàng hiểu rõ hợp đồng = dự án chạy mượt hơn = cả hai bên đều hài lòng.

Đọc Thêm Từ Trinity Software

• Tôi Đã Báo Giá 50+ Dự Án Phần Mềm
• Quy Trình Làm Phần Mềm Tại Trinity
• 7 Sai Lầm Khi Thuê Làm Phần Mềm

Thanh Trần — Founder Trinity Software (phanmemtrinity.com)