Mô hình hợp tác là quyết định sản phẩm mà phần lớn studio làm sai
Hầu hết các đội chọn tech stack một cách cẩn trọng nhưng lại chọn mô hình hợp tác một cách tình cờ. Họ mặc định theo bất cứ điều gì mẫu hợp đồng ghi sẵn — cam kết tối thiểu ba tháng, đặt cọc 50%, giữ IP cho đến khi thanh toán nốt, một SOW được viết ra trước khi có ai kịp thấy sản phẩm chạy. Rồi họ thắc mắc vì sao mối quan hệ trật bánh vào tuần thứ sáu.
Chúng tôi coi cách hai bên hợp tác là một bài toán thiết kế, y hệt như cách chúng tôi dựng sản phẩm. Qua những dự án đã giao — các đợt presale thanh toán bằng USDT thật, các Telegram Mini App chạy trên nhiều chuỗi, hạ tầng thanh toán vận hành trên bảy mạng lưới — chúng tôi hội tụ về đúng một mô hình và loại bỏ hết phần còn lại. Bài viết này chính là mô hình đó, được trình bày đầy đủ: chuyện gì diễn ra trước khi bạn trả bất kỳ đồng nào, mỗi tuần trông ra sao, bạn trả tiền thế nào, bạn rời đi ra sao, và điều gì xảy ra sau khi ra mắt.
Nếu bạn muốn phiên bản về chi phí của lập luận này — mức giá thị trường, so sánh bốn mô hình hợp tác theo giá, cách đọc một bản báo giá — chúng tôi đã viết riêng trong Thuê một lập trình viên crypto năm 2026 thực sự tốn bao nhiêu. Bài này nói về hình hài của mối quan hệ, không phải con số trên hóa đơn.
Hình hài của sự hợp tác, từ đầu đến cuối
Đây là toàn bộ vòng đời gói gọn trong một trang. Mọi thứ bên dưới chỉ là chi tiết của từng ô.
Ba tính chất luôn đúng ở mọi ô: bạn thấy trước khi trả tiền, bạn sở hữu thứ bạn đã trả, và bạn có thể rời đi ở ranh giới tuần mà không bị phạt. Hãy ghi nhớ chúng — đó chính là điểm cốt lõi của toàn bộ câu chuyện.
Giai đoạn 0 — Bản thiết kế MVP miễn phí (trước khi bất kỳ đồng tiền nào chuyển tay)
Hầu hết sự hợp tác bắt đầu bằng một khoản đặt cọc và một bước nhảy vào niềm tin. Của chúng tôi bắt đầu bằng một tài liệu chúng tôi tặng không.
Gửi cho chúng tôi ý tưởng — một bản tóm tắt, một bản Figma, một tin nhắn thoại, hay một dòng Telegram nửa vời lúc 2 giờ sáng. Chúng tôi sẽ quay lại với một bản thiết kế MVP:
- Danh sách tính năng MVP đã được xác định phạm vi — những gì có trong v1 và, quan trọng không kém, những gì chúng tôi sẽ hoãn lại.
- Luồng người dùng và cấu trúc trang.
- Kiến trúc kỹ thuật và stack chúng tôi sẽ dùng, kèm lý do.
- Kế hoạch giao hàng theo từng tuần.
- Một mốc thời gian thực tế.
- Một khoảng ngân sách hằng tuần ước chừng.
Nó là của bạn để giữ, bất kể chúng ta có hợp tác hay không. Nếu kế hoạch hợp lý, bạn đã có tấm bản đồ để khởi động Tuần 1. Nếu không — hoặc nếu bạn mang nó đến một đội khác — bạn vẫn rời đi với sự rõ ràng mà trước đó bạn chưa có.
Tại sao lại tặng không thứ đó? Hai lý do, đều thực dụng. Thứ nhất, một sản phẩm crypto mới không thể được báo giá trung thực như một hộp đen; chính việc viết ra bản thiết kế là hành động hiểu xem chúng tôi có phải đội phù hợp hay không. Thứ hai, nó sàng lọc. Một khách hàng tiềm năng đọc một phạm vi rõ ràng và một kế hoạch theo từng tuần mà vẫn muốn hợp tác là người đã tin tưởng cách chúng tôi vận hành. Đó là một khởi đầu tốt hơn nhiều so với một hợp đồng đã ký và hai tay khấn vái.
Đây cũng là câu trả lời cho sự do dự phổ biến nhất chúng tôi nghe được: tôi có phải trả tiền trước khi các bạn còn chưa hiểu dự án của tôi không? Không. Sự thấu hiểu đến trước, và nó miễn phí.
Giai đoạn 1 — Tuần 1, thứ duy nhất bạn trả trước
Nếu bản thiết kế trúng đích, Tuần 1 được trả trước bằng USDT và chúng tôi bắt đầu. Đó là khoản thanh toán trả trước duy nhất trong toàn bộ quá trình hợp tác. Mọi thứ sau đó đều được trả sau, dựa trên công việc đã giao.
Buổi khởi động cố tình nhàm chán:
- Một nhóm Telegram. Bạn, chúng tôi, và những người thực sự viết code. Không có account manager truyền tin, không cổng ticket, không có “để tôi hỏi lại đội”.
- Một đội. Frontend, backend, smart contract, Telegram, DevOps — vẫn những con người đó, không thầu phụ, không những lần bàn giao khiến ngữ cảnh tan biến.
- Một hóa đơn. Mỗi tuần. Liệt kê chi tiết. Bằng USDT.
Tuần 1 thường là tuần nặng nhất — kiến trúc, hợp đồng cốt lõi hoặc mô hình dữ liệu, cái xương sống mà mọi thứ khác bám vào. Chúng tôi dồn những quyết định cấu trúc khó nhằn lên đầu khi sự hợp tác còn nhỏ và dễ rời bỏ, chứ không phải sau khi bạn đã trả ba kỳ.
Giai đoạn 2 — Vòng lặp hằng tuần: bằng chứng trước, thanh toán sau
Đây là cỗ máy. Nó lặp lại mỗi tuần và chạy theo một chiều duy nhất:
Dựng (Thứ 2–Thứ 5) → demo trực tiếp (Thứ 6) → bạn duyệt → bạn trả tiền → bàn giao mã nguồn → kế hoạch tuần kế.
Mỗi Thứ 6 bạn nhận bốn thứ:
- Một bản demo có thể bấm, có thể kiểm thử. Không phải slide thuyết trình, không phải video quay màn hình từ máy của chúng tôi. Một thứ bạn có thể tự mở ra và tự bẻ gãy. Nếu bạn không chạm vào được, nó không được tính là đã giao.
- Một báo cáo tiến độ — những gì đã được dựng, những gì chúng tôi học được, những gì đã thay đổi.
- Toàn bộ mã nguồn của công việc tuần đó, chuyển giao khi thanh toán. Kho mã của bạn lớn lên mỗi Thứ 6.
- Kế hoạch tuần kế — những gì chúng tôi sẽ làm tiếp và chi phí ước chừng cho tuần đó.
Rồi bạn quyết định có trả tiền cho tuần bạn vừa thấy hay không. Thanh toán được khớp với công việc đã giao và đã được chấp nhận — không bao giờ trả trước. Thứ tự quan trọng: bạn thấy, bạn duyệt, bạn trả tiền, rồi tuần kế bắt đầu vào Thứ 2.
Chỉ một thứ tự này lặng lẽ sửa được cái thứ làm hỏng phần lớn các mối quan hệ thuê ngoài — vòng lặp động lực. Dưới mô hình tính theo giờ, mỗi giờ debug thêm cho chính yêu cầu mơ hồ của bạn là doanh thu của nhà cung cấp; đồng hồ tính giờ tưởng thưởng cho sự chậm chạp. Dưới một mức giá tuần cố định trả khi giao hàng, một tuần hiệu quả là lợi nhuận của chúng tôi và một tuần chậm là chi phí của chúng tôi. Động lực đảo chiều về phía giao hàng. Bạn không mua giờ công rồi cầu mong chúng biến thành sản phẩm. Bạn mua một sản phẩm, mỗi lần một tuần có thể kiểm chứng được.
Lợi ích 1 — Không trói buộc, và bạn trả tiền từ bất kỳ đâu trên Trái Đất
Có hai thứ người ta ngụ ý khi nói “trói buộc”, và mô hình này hóa giải cả hai.
Trói buộc bằng hợp đồng. Không có cam kết tối thiểu nhiều tháng, không phí thoát ra, không IP bị giữ làm con tin cho đến khoản thanh toán phình to cuối cùng. Vì mã nguồn được chuyển giao mỗi Thứ 6 khi thanh toán, kịch bản tệ nhất nếu bạn rời đi là: bạn dừng vào một Thứ 6 và giữ từng dòng code bạn đã trả, đã nằm sẵn trong kho của bạn. Bạn không bao giờ chỉ cách một hóa đơn cuối tranh chấp là mất trắng công sức. Bạn có thể tạm dừng hoặc dừng hẳn ở bất kỳ ranh giới tuần nào — và mối quan hệ vì thế lành mạnh hơn, bởi cả hai bên đều biết cánh cửa luôn rộng mở. Một studio phải giam giữ bạn mới giữ được bạn thì không giao ra thứ đáng để ở lại.
Trói buộc bằng kênh thanh toán. Chúng tôi thanh toán bằng USDT (TRC-20 hoặc Polygon), chấp nhận ETH, SOL và TON như các lựa chọn thay thế. Đó không phải lựa chọn hình thức — đó là thứ khiến nhịp hằng tuần khả thi về mặt vật lý trong một sự hợp tác phân tán toàn cầu:
- Nó chuyển xong trong vài giây, trên toàn cầu, với phí gần như bằng không. Một lần duyệt Thứ 6 nghĩa là công việc khởi động lại vào Thứ 2 — chứ không phải Thứ 5 tuần sau khi một lệnh chuyển khoản quốc tế cuối cùng cũng qua được ba ngân hàng trung gian.
- Không ngân hàng, không mẫu chuyển khoản, không trò chơi tỷ giá. Bạn giữ ngân quỹ của bạn bằng crypto; chúng tôi giữ của chúng tôi. Không ai mất một lát vì quy đổi tiền tệ ở mỗi lần thanh toán hằng tuần, và không khoản thanh toán nào bị treo vì một bộ phận tuân thủ gắn cờ giao dịch xuyên biên giới.
- Nó vốn thuộc về chính công việc này. Các sản phẩm chúng tôi dựng thanh toán bằng USDT; những khách hàng thuê chúng tôi cũng thường vậy. Ép một bên trung gian fiat vào giữa một dự án crypto-native là ma sát không có lợi ích.
Điều quan trọng là sự kết hợp: giao hàng hằng tuần chỉ hiệu quả nếu thanh toán hằng tuần không có ma sát, và USDT là thứ khiến thanh toán hằng tuần không ma sát từ bất cứ đâu có một chiếc ví.
Lợi ích 2 — Lặp lại theo nhu cầu và bảo trì dài hạn, tính theo ngày
Ra mắt không phải là điểm kết của mối quan hệ. Đó là khoảnh khắc mối quan hệ đổi hình hài — và phần lớn các mô hình hợp tác xử lý điều này rất tệ. Agency làm giá cố định đóng SOW lại và coi mọi việc tiếp nối là một cuộc thương lượng mới. Hợp đồng giữ chỗ thì cứ thu phí dù có việc hay không. Cả hai đều sai cho cái xảy đến sau ra mắt, vốn bùng phát theo đợt: những quãng yên ắng bị cắt ngang bởi “chúng tôi cần tính năng này trước cuối tuần”.
Chúng tôi xử lý điều đó một cách tự nhiên — và đơn vị tính phí đổi theo cho khớp. Một tuần là đơn vị đúng để dựng cả một sản phẩm từ con số không; nó là đơn vị sai cho một chỉnh sửa nhỏ lẻ sau ra mắt. Vậy nên một khi phiên bản đầu tiên của bạn đã ra mắt, chúng tôi chuyển từ cột mốc theo tuần sang tính phí theo cấp độ ngày: chúng tôi ước lượng số người và số ngày một thay đổi thực sự cần, báo giá theo đó, và bạn duyệt trước khi chúng tôi bắt đầu. Đường ray vẫn y hệt — vẫn cùng một đội, cùng nhóm Telegram, vẫn bằng-chứng-trước-thanh-toán, vẫn thanh toán bằng USDT — chỉ là độ chi tiết trở nên tinh hơn.
- Không cần làm quen lại. Đội đã giao nó vẫn nắm ngữ cảnh, vẫn giữ chìa khóa, vẫn mang kiến trúc trong đầu. Không có thuế khám phá lại, không có cái tuần “để tôi đọc lại codebase đã” mà bạn phải trả tiền.
- Bạn trả cho số ngày công việc cần — không phải một tuần cố định, không phải hợp đồng giữ chỗ. Một tích hợp chuỗi mới, một chỉnh sửa giới thiệu, một báo cáo dashboard trước một chiến dịch? Chúng tôi xác định phạm vi theo ngày, ước lượng nhân lực, và báo giá từ đó — nửa ngày, hai ngày, một tuần tập trung nếu nó thực sự lớn. Những quãng yên ắng không tốn gì của bạn cả; không có hợp đồng giữ chỗ chạy nhàn rỗi trong khi chẳng có gì được giao.
- Nó mở rộng thành một quan hệ đối tác thực thụ. Các tính năng nhỏ và việc bảo trì chạy theo giá ngày. Cả một dòng sản phẩm mới — một đợt presale thứ hai, một lớp game, một mảng mở rộng thanh toán — là một dự án dựng mới và quay về mô hình theo tuần. Dù theo cách nào thì vẫn cùng một đội, không cần làm quen lại: một mạch liên tục thay vì hai hợp đồng.
Đây là phần dễ bị bỏ sót khi bạn so sánh các bản báo giá: đội rẻ nhất để bắt đầu thường lại đắt nhất để ở lại, bởi mỗi thay đổi sau ra mắt là một cuộc tái thương lượng. Lặp lại theo nhu cầu, tính theo giá ngày, định giá cái đuôi dài một cách trung thực — bạn trả cho chuyển động, không phải cho việc chờ chực.
Những lợi ích khác đáng được gọi tên
Vài tính chất nữa nảy sinh từ cùng một cấu trúc. Không cái nào là tiêu đề chính, nhưng cộng lại chúng là lý do mô hình đứng vững trong điều kiện thực tế.
| Tính chất | Nó có nghĩa gì với bạn |
|---|---|
| Điều chỉnh phạm vi không bị phạt | Ưu tiên dịch chuyển giữa chừng — luôn luôn như vậy. Chúng ta cùng điều chỉnh phạm vi ở ranh giới tuần thay vì định giá từng thay đổi như bị dí súng. Không có thuế đổi đơn cho việc học ra điều gì đó. |
| Phạm vi được tinh chỉnh theo thực tế, không phải một bản đặc tả ngày đầu | Một sản phẩm mới không thể được đặc tả đầy đủ trước khi bạn thấy nó chạy. Tinh chỉnh hằng tuần không phải là thất bại của việc lập kế hoạch — đó là cách sản phẩm tốt lên. Kế hoạch uốn theo những gì bạn khám phá vào Thứ 6. |
| Một đội, full stack, không bàn giao | Không có những đường nối thầu phụ nơi một con bug ẩn nấp giữa hai nhà cung cấp. Người viết hợp đồng nói chuyện với người viết frontend — trong cùng một nhóm Telegram, cùng một ngày. |
| Bất chấp múi giờ theo thiết kế | Một đội phân tán toàn cầu cộng với một điểm kiểm tra bất đồng bộ vào Thứ 6 nghĩa là tiến độ không đình trệ chờ một văn phòng thức dậy. Chính nhịp độ là lớp điều phối. |
| Quyền sở hữu mã nguồn tích lũy hằng tuần | Kho mã của bạn không bao giờ là “kho của họ cho đến khi bạn trả đủ”. Nó lớn lên mỗi Thứ 6, nằm trong tay bạn, nên đòn bẩy không bao giờ nghiêng hẳn về một phía bàn. |
Mô hình này không phù hợp cho điều gì
Những mô hình hợp tác trung thực tự loại mình ra một cách thẳng thắn. Mô hình này là một lựa chọn dở nếu:
- Bạn muốn tăng cường nhân sự. Chúng tôi không cho bạn thuê một lập trình viên để cắm vào buổi standup của bạn. Thứ giao ra ở đây là một sản phẩm, không phải một chỗ ngồi. Nếu bạn cần cắm một kỹ sư vào một đội sẵn có, chúng tôi là lựa chọn sai.
- Bạn không thể tương tác hằng tuần. Cả mô hình dựa trên một điểm kiểm tra vào Thứ 6 — một con người thực nhìn vào một bản demo thực và duyệt nó. Nếu tổ chức của bạn không thể rà soát và quyết định theo nhịp đó, vòng lặp sẽ tắc và bạn đánh mất lớp bảo vệ lớn nhất của mô hình.
- Bạn muốn một mức giá cố định duy nhất khắc đá ngay ngày đầu cho một sản phẩm còn chưa tồn tại. Chúng tôi sẽ đưa bạn một khoảng ước chừng trong bản thiết kế, nhưng một tổng số chính xác cho một dự án mới hoàn toàn chưa được định hình là một điều hư cấu mà ai đó sẽ phải trả giá về sau. Nếu bạn cần điều hư cấu đó được ký trước khi khởi động, một cửa hàng làm giá cố định là lựa chọn phù hợp hơn — chỉ cần đọc kỹ điều khoản đổi đơn.
Chúng tôi thà nói với bạn điều này ngay cuộc gọi đầu tiên còn hơn phát hiện ra ở tuần thứ tư. Độ tin cậy của mô hình một phần đến từ những gì nó từ chối giả vờ là.
Cách bắt đầu
Đường dẫn vào là phần rẻ nhất: gửi cho chúng tôi ý tưởng và nhận bản thiết kế MVP miễn phí — phạm vi, luồng, kế hoạch giao hàng, và một khoảng ngân sách hằng tuần ước chừng. Nếu nó hợp lý, bạn trả trước Tuần 1 bằng USDT và chúng tôi bắt đầu. Nếu không, bạn giữ kế hoạch và chúng ta chia tay như bạn bè.
Nếu bạn muốn đi sâu hơn vào những quyết định xung quanh, chúng tôi đã viết về bài toán chi phí thực khi thuê một lập trình viên crypto, kiến trúc đằng sau một đợt presale $8M, và đưa một Telegram Mini App lên production.
Muốn có một bản thiết kế cho dự án của bạn? Đặt một cuộc gọi 30 phút tại 0xforge.io. Chúng tôi sẽ hoặc trao cho bạn một kế hoạch, hoặc nói cho bạn biết vì sao chúng tôi không phải đội phù hợp — và dù theo cách nào, cuộc trò chuyện đó không tốn của bạn đồng nào.
— 0xforge Team