Khi nghe rằng một sub-version chỉ có giá bằng 50% version gốc, nhiều người sẽ nghĩ đây là một quy ước bán hàng. Thực ra, logic phía sau lại nằm ở năng lực thi công và khả năng dự báo chi phí. Với Midi Coder, giá không được dựng từ cảm tính hay số giờ review thủ công, mà từ một mô hình software factory có traceability, contract-first và complexity score rõ ràng. Vì vậy, sub-version rẻ hơn không phải vì giá trị thấp hơn, mà vì phần việc lặp lại, rủi ro tích hợp và khối lượng xác minh đã giảm đáng kể.
1. Nhìn đúng vào cấu trúc chi phí: hạ tầng riêng và phí dùng theo output
Mô hình giá của Midi Coder thường được hiểu theo hai lớp. Lớp thứ nhất là phí hạ tầng riêng để duy trì môi trường vận hành ổn định cho đội ngũ và quy trình: nơi lưu vết, quản trị contract, kiểm soát phiên bản, sandbox và năng lực triển khai. Lớp thứ hai là phí dùng theo output, tức theo version, sub-version hoặc sandbox được tạo ra trong quá trình thi công.
Cách tách lớp này rất quan trọng. Phí hạ tầng đảm bảo doanh nghiệp có một dây chuyền sản xuất phần mềm nhất quán. Phí theo output mới phản ánh mức sử dụng thực tế. Đây chính là tinh thần PAYG: trả tiền theo khối lượng tạo ra, thay vì phải ôm một đội ngũ cố định với chi phí khó dự báo.
2. Vì sao version gốc đắt hơn sub-version?
Version gốc thường là lần thi công đầu tiên của một phạm vi tính năng hoặc một module. Ở bước này, hệ thống phải thực hiện nhiều việc nền tảng hơn: xác lập contract, dựng cấu trúc implementation, kiểm tra tương thích đầu-cuối, tạo mốc traceability và hoàn thiện baseline để các lần mở rộng sau có thể bám vào.
Sub-version là phần phát triển tiếp theo trên nền đã có. Khi baseline đã tồn tại, phần việc mới thường không cần lặp lại toàn bộ chi phí thiết kế và xác minh ban đầu. Nói cách khác, doanh nghiệp không nên trả 100% chi phí của lần đầu cho một thay đổi chỉ sử dụng lại phần lớn nền móng cũ. Mốc 50% vì vậy phản ánh lợi thế tái sử dụng có kiểm soát.
Điểm then chốt là Midi Coder không xem mọi thay đổi đều là một dự án mới. Nếu thay đổi đó nằm trong quỹ đạo của contract-first, tận dụng được traceability và không kéo theo chi phí tái cấu trúc lớn, thì sub-version có thể được định giá thấp hơn đáng kể mà vẫn đảm bảo chất lượng.
3. Complexity score là gì và vì sao giá tăng tuyến tính?
Complexity score là cách lượng hóa độ phức tạp thi công thay vì dùng cảm giác chủ quan. Mỗi version hay sub-version được gắn với một điểm số phản ánh độ rộng phạm vi, mức phụ thuộc, tác động lên luồng dữ liệu, số điểm tích hợp và rủi ro kiểm thử. Khi đã có score, giá tăng tuyến tính theo score sẽ tạo ra hai lợi ích lớn.
Thứ nhất, khách hàng dễ dự báo ngân sách. Nếu độ phức tạp tăng 20%, chi phí cũng tăng theo logic rõ ràng, không nhảy vọt vì những biến số khó giải thích. Thứ hai, đội thi công có động lực tối ưu thiết kế để giảm complexity thật, thay vì chuyển chi phí mơ hồ sang các hạng mục khác.
Giá tăng tuyến tính không có nghĩa mọi bài toán đều đơn giản như nhau. Nó có nghĩa là sau khi đã chuẩn hóa cách đo độ phức tạp, doanh nghiệp sẽ thấy mối quan hệ minh bạch giữa yêu cầu và chi phí. Đây là nền tảng để pricing gắn với năng lực sản xuất, không gắn với mức độ thuyết phục trong báo giá.
4. Một cách ước lượng ngân sách khi mỗi tháng thi công nhiều version
Doanh nghiệp có thể ước lượng ngân sách theo công thức thực dụng: tổng ngân sách tháng = phí hạ tầng riêng + tổng chi phí các version gốc + tổng chi phí các sub-version + chi phí sandbox nếu có. Nếu một version gốc được tính theo complexity score đầy đủ, thì sub-version thường chỉ cần tính theo hệ số 50% trên cùng logic score, với điều kiện phạm vi thay đổi vẫn bám trên baseline hiện hữu.
Ví dụ, trong một tháng doanh nghiệp làm 2 version gốc và 4 sub-version, thay vì phải dự phòng một ngân sách phình to như mô hình thuê đội ngũ cố định, doanh nghiệp có thể nhìn thẳng vào khối lượng output tạo ra. Điều này đặc biệt hữu ích với startup và SME, nơi dòng tiền cần độ chắc chắn cao hơn là một lời hứa “đội sẽ cố gắng tối ưu”.
5. Chi phí vô hình mới là thứ làm tổng đầu tư đội lên
Nếu chỉ so sánh đơn giá bề mặt, một số mô hình truyền thống có vẻ rẻ. Nhưng chi phí thực tế thường đội lên ở những phần khó thấy: rework vì đặc tả không rõ, regression vì thay đổi đụng dây chuyền, human review kéo dài và không scale, hoặc việc phụ thuộc quá nhiều vào từng cá nhân nắm ngữ cảnh.
Midi Coder giải bài toán này bằng contract-first và traceability. Khi mọi thay đổi đều gắn với contract và được theo dõi xuyên suốt, xác suất sửa đi sửa lại sẽ giảm. Khi quy trình giống một software factory hơn là một nhóm làm theo kinh nghiệm rời rạc, chi phí kiểm soát chất lượng cũng giảm theo. Vì vậy, mức giá 50% cho sub-version không chỉ là tiết kiệm ở báo giá, mà còn là cách chặn bớt chi phí vô hình ở giai đoạn sau.
6. Bài toán ROI theo từng quy mô doanh nghiệp
Với startup, lợi ích lớn nhất là giữ được tốc độ thử nghiệm mà không phải tuyển trước cả một đội lớn. Họ có thể tung version gốc để kiểm tra thị trường, sau đó mở rộng bằng các sub-version với ngân sách nhỏ hơn và dự báo tốt hơn.
Với SME, điểm có giá trị nhất là khả năng lập kế hoạch. Nếu mỗi tháng có nhiều thay đổi vừa và nhỏ, việc biết rằng sub-version chỉ bằng khoảng 50% version gốc giúp bộ phận vận hành và tài chính dễ khóa ngân sách hơn.
Với enterprise, ROI nằm ở tính kiểm soát và giảm bất ngờ kỹ thuật. Họ không chỉ cần làm nhanh mà còn cần audit được, truy vết được và hạn chế rủi ro lan rộng giữa nhiều hệ thống. Khi đó, traceability và cách pricing theo complexity score giúp việc ra quyết định đầu tư sát thực tế hơn nhiều.
7. Kết luận
Logic của mô hình “sub-version bằng 50% version gốc” nằm ở chỗ Midi Coder đã chuẩn hóa được phần việc nền tảng của lần thi công đầu tiên và tận dụng lại nó cho các lần mở rộng sau. Khi có contract-first, software factory, traceability và complexity score, chi phí không còn là một con số mặc cả mà trở thành hệ quả của năng lực thi công có hệ thống.
Giá trị lớn nhất vì vậy không nằm ở việc rẻ hơn trên từng dòng báo giá, mà ở khả năng dự báo, khả năng mở rộng và việc giảm những bất ngờ kỹ thuật vốn thường làm ROI của dự án phần mềm xấu đi theo thời gian. Trong bối cảnh doanh nghiệp cần tốc độ nhưng vẫn phải kiểm soát ngân sách, đây là lý do mô hình PAYG của Midi Coder trở nên hợp lý.
