Mỗi lần một founder hỏi tôi “báo giá trọn gói hay tính giờ?”, tôi phải kìm lại để không trả lời bằng một câu hỏi ngược. Câu trả lời thẳng thắn là: mô hình giá là hệ quả của việc cả hai bên hiểu scope đến đâu, và đa số scope MVP được hiểu tệ hơn nhiều so với những gì founder nghĩ. Cuối cùng bạn chọn giữa hai cách sai: một mức giá trọn gói sai về khối lượng công việc, hoặc một rate theo giờ sai về ngân sách.
Bài này là rubric tôi thực sự dùng khi một SaaS MVP rơi vào inbox của tôi. Nó đi qua một chút số học đủ để khiến lựa chọn trở nên rõ ràng trong hầu hết trường hợp, các failure mode của từng phía, và một ví dụ cùng một dự án sẽ ra sao dưới hai mô hình. Đây không phải bài “trọn gói luôn tốt hơn”, vì không phải vậy, và cũng không phải ngược lại.
Chúng ta đang so sánh điều gì
Trọn gói nghĩa là: bạn và contractor chốt một scope và một con số. Con số đó không đổi trừ khi scope đổi. Rủi ro “việc này lâu hơn dự kiến” nằm ở phía contractor.
Tính giờ (hoặc tính ngày) nghĩa là: bạn trả tiền cho thời gian, với một cap lỏng nếu may mắn. Rủi ro “việc này lâu hơn dự kiến” nằm ở phía bạn, người mua. Đa số thỏa thuận “time and materials” trong thực tế là invoice hàng tuần với một trần mềm mà không ai siết cho đến khi phải siết.
Có hình thức thứ ba — “theo milestone với mức trần không vượt quá” — về bản chất là trọn gói khoác áo tính giờ, và trong bài này tôi sẽ xếp nó vào trọn gói.
Điều cần nói cho chính xác: đây không phải là mô hình giá. Đây là mô hình phân bổ rủi ro. Trọn gói định giá cho sản phẩm bàn giao. Tính giờ định giá cho sự chú ý của contractor. Bạn không chọn cách trả tiền; bạn chọn ai sẽ ăn phương sai.
Cốt lõi của rubric: phương sai, không phải rate
Sai lầm đầu tiên mà gần như mọi founder mắc phải là so sánh rate theo giờ với con số trọn gói chia cho số giờ ước lượng. Con số đó gây hiểu lầm vì nó không bao gồm phương sai.
Đây là rubric tôi chạy trong đầu, nói nôm na.
- Độ rõ của scope. Hôm nay, bạn có viết được một trang mô tả “done” là gì không? Nếu có, trọn gói dễ hơn. Nếu không, tính giờ là trung thực hơn.
- Trọng số discovery. Bao nhiêu phần công việc là “tìm hiểu xem mình đang xây cái gì” so với “xây cái đã thống nhất”? Discovery nặng → tính giờ. Execution nặng → trọn gói.
- Khẩu vị đổi ý. Bạn dự kiến đổi ý bao nhiêu lần trong 30 ngày đầu? Founder gần như luôn báo thấp con số này. Trả lời thật mà cao → tính giờ có kỷ luật, hoặc các lát trọn gói ngắn.
- Mức chịu đựng downside của bạn. Nếu dự án tốn gấp đôi ước lượng thì công ty bạn sẽ ra sao? Nếu câu trả lời là “không trả nổi lương” thì bạn không thể chơi tính giờ không cap, chấm hết.
- Mức chịu đựng downside của họ. Contractor có phải solo operator mà sẽ thấm đòn nếu vượt 50%, hay là agency đã tính phương sai vào giá? Solo + trọn gói + scope chặt có thể là deal tốt cho cả hai. Solo + trọn gói + scope mơ hồ là cách các engineer giỏi học cách ghét khách hàng.
Một bảng quyết định thô khớp với cách tôi thực sự báo giá:
| Tình huống | Mô hình mặc định | Lý do |
|---|---|---|
| Spec một trang, stack đã biết, MVP 4-8 tuần | Trọn gói | Phương sai có biên; cả hai bên thắng nhờ tính dự đoán |
| ”Giúp tôi tìm ra phải xây cái gì” | Tính giờ, chỉ giai đoạn discovery | Bạn đang trả tiền cho việc suy nghĩ, không phải sản phẩm |
| Cải tiến dài hạn sau launch | Tính giờ có cap hoặc retainer | Dòng các yêu cầu nhỏ, không có deliverable rõ |
| Tích hợp với hệ thống legacy bừa bộn | Tính giờ với milestone gate | Unknown unknown là có thật, chỉ lộ ra khi đã ở bên trong |
| ”Cần cái này cho buổi demo 3 tuần nữa” | Trọn gói, scope hẹp | Áp lực thời gian thưởng cho việc freeze scope cứng |
Chú ý là không dòng nào nói “X USD/giờ là quá đắt”. Rate là thứ làm bạn xao nhãng. Một contractor senior với rate cao nhưng xong trong một phần ba thời gian của junior thì rẻ hơn tính bằng tiền tuyệt đối và ship sớm hơn. Biến số quan trọng là tổng chi phí kỳ vọng kèm phương sai, không phải con số đầu tiên bạn nhìn thấy.
Để có mỏ neo cho thị trường Việt Nam: senior Ruby on Rails ở Việt Nam có thể ship Rails đàng hoàng thường rơi vào khoảng 800k-1,5tr VNĐ/giờ tùy kinh nghiệm và khách ở đâu. Khách trong nước thường ở đầu thấp, khách Mỹ/EU đẩy lên đầu cao. Trọn gói cho một MVP 4-8 tuần ở chất lượng đó thường rơi vào khoảng $14k-$40k (~360tr-1 tỷ VNĐ) tùy mức độ chặt của scope.
Mỗi mô hình hỏng ở đâu
Failure mode của trọn gói là cuộc chiến change request. Bạn đã chốt scope. Ba tuần sau, bạn nhận ra luồng login cần SSO vì khách hàng quan tâm đầu tiên là enterprise. Contractor đã báo giá khi chưa có SSO, giờ phải hoặc nuốt thêm vài ngày, hoặc viết change order. Cả hai đường đều ăn mòn quan hệ. Change order liên tục là dấu hiệu rằng scope gốc chỉ là phỏng đoán mặc áo spec.
Failure mode của tính giờ là trôi đến vô cực. Không có lực đẩy nào hỏi “việc này còn đáng xây không?”. Invoice mỗi thứ Sáu nhìn riêng lẻ thì đều hợp lý. Tám tuần thứ Sáu sau, bạn đã chi gấp đôi một deal trọn gói mà vẫn còn pre-launch. Tính giờ mà không cap, không burn-down hàng tuần, không có cuộc trao đổi “done trông như thế nào?” là một dạng bug.
Có failure thứ ba không thuộc về mô hình nào: sai contractor cho hình dạng công việc. Một agency quen với chu kỳ engagement sáu tháng không biết cách ship một MVP bốn tuần, và một solo engineer chưa từng báo giá trọn gói sẽ báo thiếu rồi sinh ra ác cảm với bạn. Khớp hình dạng contractor với hình dạng công việc trước khi tranh cãi về giá.
Một ví dụ cụ thể về mặt khái niệm
Giả sử scope là một Rails SaaS MVP: trang marketing, auth, billing qua Stripe, một workflow lõi, admin cơ bản, deploy lên một managed host. Đúng loại việc tôi đã viết trong scoping một Rails MVP cho 4-8 tuần.
Dưới trọn gói, contractor sizing cho khoảng sáu tuần làm việc tập trung và báo một con số đã gài buffer — thường là 20-30% trên ước lượng trung vị, vì họ là người ăn phương sai. Hợp đồng nêu tên deliverable rõ ràng và liệt kê những gì không bao gồm. Đổi thì tốn tiền và bảng giá thay đổi nằm trong hợp đồng. Founder được tính dự đoán: cùng một con số trên invoice ở tuần một và tuần sáu.
Dưới tính giờ, cũng contractor đó báo một rate và một khoảng ước lượng — kiểu “dự kiến nằm đâu đó trong khoảng X đến Y giờ”. Có check-in hàng tuần, burn-down viết ra, và một cap mềm để kích hoạt cuộc trao đổi chứ không phải dừng lại. Founder trả ít hơn nếu việc trơn tru, nhiều hơn nếu không, và phải gánh các khoảnh khắc đổi ý dọc đường.
Quan sát thú vị, theo kinh nghiệm của tôi: tổng chi phí kỳ vọng giữa hai kịch bản này thường chỉ chênh nhau trong vòng 10-15%. Trọn gói đã gài sẵn buffer; tính giờ giữ lại phương sai mà khi bình quân qua nhiều dự án sẽ ăn gần hết phần buffer kia. Cái khác nhau là phân bố kết quả. Trọn gói gom phân bố về một con số. Tính giờ giữ nguyên độ trải và trao nó cho người mua.
Nếu bạn là founder chỉ có một phát đạn runway, bạn không muốn phân bố rộng. Bạn muốn một con số có thể viết xuống bảng cash-flow. Riêng cái sở thích đó đã đủ để chọn trọn gói ngay cả khi bài toán nhìn như hòa.
Mô hình giá là một dự báo về việc cả hai bên giỏi nói không với scope creep đến đâu. Chọn mô hình khớp với mức kỷ luật bạn thực sự có, không phải mức kỷ luật bạn ước mình có.
”Done” trông như thế nào dưới mỗi mô hình
Một engagement trọn gói xong khi các deliverable trên SOW được trình diễn chạy trên production. Không phải “feature-complete trên một branch”. Không phải “sẵn sàng cho QA”. Hợp đồng nên ghi “đã deploy, truy cập được tại URL này, với những acceptance criteria sau quan sát được là đúng”. Bất cứ thứ gì kém hơn thì 10% cuối cùng sẽ thành cột gôn trượt.
Một engagement tính giờ xong khi một trong ba thứ xảy ra: việc của phase đó đã ship, cap đã thống nhất bị chạm, hoặc founder gọi dừng. Phần khó nhất của tính giờ là dám nhấn nút thứ ba. Contractor sẽ không, trong lương tâm, bảo bạn ngừng trả tiền cho họ. Đó là việc của bạn. Đặt một nhắc lịch cho cái cap và coi nó như một checkpoint, không phải gợi ý mềm.
Trong cả hai trường hợp, “done” nên bao gồm những thứ chán ngắt: pipeline deploy chạy sạch sẽ, secret không nằm trong repo, error tracking đã được nối, founder có thể đăng nhập và thấy dữ liệu của chính mình. Tôi đã viết về thuê Rails contractor khi bản thân không code được; checklist nghiệm thu ở đó áp dụng bất kể mô hình giá là gì.
Khi không rubric nào áp dụng
Hai tình huống phá vỡ toàn bộ framework này.
Thứ nhất là khi dự án thực sự có hình dạng nghiên cứu — “tôi muốn biết RAG trên cơ sở tri thức của mình có ra câu trả lời hữu ích không”. Không có scope nào fix được vì deliverable là tri thức, không phải phần mềm. Trả tiền theo giờ, đặt một budget cap như học phí, và chấp nhận đầu ra có thể là “không, hướng này không chạy” — và điều đó vẫn có giá trị. Đây cũng là hình dạng phổ biến hơn trong 2026 khi AI agent integration trở thành mặc định chứ không còn là feature riêng, và nhiều founder đến với một câu hỏi chứ chưa phải một spec.
Thứ hai là khi bạn không thực sự cần một MVP — bạn cần một prototype để cho nhà đầu tư hoặc một design partner duy nhất xem. Đó là một con thú khác: nhỏ hơn, vứt được, tối ưu cho một cuộc trao đổi chứ không phải cho người dùng thật. Trọn gói vẫn dùng được, nhưng scope phải ngắn đến tàn nhẫn và hợp đồng phải ghi rõ “đây không phải code production”.
Một kết luận nhỏ để bám vào
Nếu bạn tính phương sai một cách trung thực, trọn gói và tính giờ gần như không bao giờ chênh nhau quá 15% tổng chi phí kỳ vọng cho một MVP 4-8 tuần được scope tử tế. Lý do chọn trọn gói không phải vì nó rẻ hơn. Lý do là nó ép cuộc trao đổi scope đau đớn diễn ra trước khi tiền bắt đầu chảy, và cuộc trao đổi đó chính là phần dự án mà đa số founder bỏ qua, và đa số đều hối tiếc vì đã bỏ qua.