TMNSolutions

Quả Bom Hẹn Giờ Nợ Kỹ Thuật Ẩn Giấu Trong MVP Thuê Ngoài Của Bạn

Bởi Emma Trần

Quả Bom Hẹn Giờ Nợ Kỹ Thuật Ẩn Giấu Trong MVP Thuê Ngoài Của Bạn

Ra mắt MVP lẽ ra phải là khoảnh khắc chiến thắng. Bạn tìm được agency, thỏa thuận giá cả, ship trong ba tháng, có người dùng đầu tiên. Demo trông rất đẹp. Nhà đầu tư quan tâm. Bạn đã bắt đầu nghĩ đến tính năng tiếp theo.

Rồi sáu tháng sau, developer chính nghỉ việc. Hoặc bạn muốn tích hợp cổng thanh toán và backend dev nói sẽ mất tám tuần. Hoặc bạn thuê agency mới tiếp quản, họ xin hai tuần chỉ để hiểu team cũ đã xây gì.

Đó là lúc quả bom phát nổ. Và ngòi nổ đã được châm từ ngày MVP thuê ngoài đó được viết ra.

Nợ Kỹ Thuật Thực Sự Trông Như Thế Nào

Nợ kỹ thuật không phải khái niệm trừu tượng. Trong MVP thuê ngoài, nó xuất hiện theo những mẫu có thể đoán trước — mà developer có kinh nghiệm nhận ra ngay khi mở codebase.

Routes rối rắm và controller cồng kềnh. Thay vì kiến trúc module rõ ràng, toàn bộ logic được nhét vào một controller duy nhất xử lý cả authentication, business logic, và database query cùng lúc. Thêm tính năng đồng nghĩa với việc phải gỡ rối đống code không được thiết kế để gỡ.

Không quản lý environment. Credentials, API keys, và database URL được hardcode thẳng vào source code. Không có file .env, không có secrets management, không phân tách cấu hình giữa staging và production. Khi có lỗi trên production, không thể reproduce trên local vì không ai tài liệu hóa "production" có nghĩa là gì.

Zero test coverage. Team thuê ngoài bị áp lực ngân sách nên bỏ qua test hoàn toàn. Không có gì để bắt regression. Mỗi thay đổi là một canh bạc. Deploy trở thành sự kiện mà cả team sợ.

Không có tài liệu. Team cũ biết tại sao họ đưa ra những quyết định đó. Giờ họ đã đi. Team mới tiếp quản codebase không có README, không có sơ đồ kiến trúc, không có comment giải thích những phần không hiển nhiên. Onboard developer mới mất nhiều tháng.

Vendor lock-in ngoài ý muốn. Agency dùng công cụ độc quyền, tích hợp bên thứ ba không được tài liệu hóa, hoặc host dịch vụ quan trọng trên cơ sở hạ tầng của họ — không phải của bạn. Nếu họ biến mất, app của bạn cũng biến mất theo.

Chi Phí Vô Hình

Con số trông hấp dẫn khi bạn ký hợp đồng. "MVP $30,000 — làm thôi." Những gì hóa đơn không hiển thị là chuyện gì xảy ra tiếp theo.

Khi codebase được xây dựng không quan tâm đến khả năng bảo trì, chi phí tích lũy rất nhanh:

  • Onboard developer mất gấp 2–3 lần vì không có tài liệu và kiến trúc không nhất quán.
  • Mỗi tính năng mới đòi hỏi phải gỡ rối code cũ trước khi viết code mới. Task đáng lẽ một ngày trở thành một tuần.
  • Bug nhân rộng. Không có test coverage, fix cái này tạo ra lỗi khác. Vòng QA không bao giờ kết thúc.
  • Cuối cùng, ai đó nói lên từ đó. Rewrite.

Rewrite toàn bộ — bắt đầu lại từ đầu vì codebase gốc quá hỏng để mở rộng — thường tốn 3–5 lần giá build ban đầu. MVP $30k biến thành rewrite $120k–$150k, cộng thêm nhiều tháng mất tốc độ phát triển trong khi bạn đang chiến đấu với lửa.

Đây không phải kịch bản giả định. Đây là câu chuyện lặp đi lặp lại trong giới startup, và năm 2026, nó xảy ra thường xuyên hơn khi ngày càng nhiều công ty thuê ngoài để cắt giảm chi phí, rồi đâm vào tường khi cố scale.

Dấu Hiệu Cảnh Báo Khi Audit Codebase Tiếp Quản

Nếu bạn vừa tiếp quản codebase từ agency khác — hoặc đang đánh giá một codebase trước khi ký hợp đồng — đây là những gì cần tìm:

Xem commit history. Toàn bộ code được push trong một commit? Đó là dấu hiệu team làm việc local mà không có kỷ luật version control. Codebase lành mạnh có commit history rõ ràng, incremental, kể được câu chuyện codebase được xây dựng như thế nào.

Tìm file .env.example. Nếu không có, không có tài liệu về environment variables mà app cần. Đây là tín hiệu cơ bản về tính chuyên nghiệp.

Chạy test suite. Nếu không có test suite, đó đã nói lên tất cả. Nếu có, chạy nó và xem coverage đạt bao nhiêu phần trăm.

Mở controller lớn nhất. Nếu một file có hơn 300–400 dòng, nó đang làm quá nhiều thứ. Đó là nơi phức tạp — và bug — ẩn náu.

Hỏi về quy trình deploy. Ai trong team cũng có thể deploy không cần kiến thức bộ lạc không? Nếu câu trả lời là "phải hỏi [người đó]" thay vì "chạy script này", không có CI/CD pipeline, và bạn đang một bước xa khỏi khủng hoảng deploy.

Tìm giá trị hardcode. Search codebase tìm các pattern phổ biến như localhost, password, hay API key thật trong config file. Nếu tìm thấy, bạn đã tìm thấy vấn đề bảo mật cần xử lý ngay lập tức.

Những Gì Agency Có Trách Nhiệm Phải Giao

Code chỉ là mức tối thiểu. Agency có trách nhiệm giao cho bạn codebase bạn thực sự có thể sở hữu và vận hành sau khi họ rời đi. Nghĩa là:

README hoạt động được giải thích cách setup môi trường development, chạy test, và deploy. Developer mới nào cũng phải có thể theo dõi mà không cần gọi cho ai.

Environment configuration tách secrets khỏi code. File .env, biến được tài liệu hóa, config khác nhau cho development, staging, và production.

CI/CD pipeline. Test và deploy tự động không phải xa xỉ phẩm. Đây là baseline cho phép team ship với sự tự tin.

Test coverage. Không phải 100% — không thực tế trong timeline MVP. Nhưng các luồng quan trọng — authentication, thanh toán, business logic cốt lõi — phải có test.

Handover notes. Tài liệu giải thích quyết định kiến trúc, vấn đề đã biết, tích hợp bên thứ ba, và bất cứ điều gì developer mới cần biết. Đây là institutional memory không nên chỉ tồn tại trong đầu một người.

Infrastructure của bạn, không phải của họ. App phải chạy trên account của bạn — cloud provider của bạn, domain registrar của bạn, email service của bạn. Bạn phải có thể đổi agency mà không cần đổi provider.

Câu Hỏi Đúng Trước Khi Ký Hợp Đồng

Thời điểm để đánh giá thực hành của agency là trước khi bạn chuyển tiền đặt cọc. Đây là những gì cần hỏi:

"Tôi có thể xem ví dụ về code bạn đã ship cho khách hàng cũ không?" Agency tự tin không ngại cho bạn xem codebase đã sanitize hoặc walk-through kiến trúc dự án trước.

"Chiến lược testing của bạn trông như thế nào cho MVP build?" Câu trả lời đúng ít nhất bao gồm unit test cho các luồng quan trọng. Câu trả lời sai là "chúng tôi sẽ thêm test sau."

"Ai sở hữu repository và hosting accounts khi dự án kết thúc?" Tất cả phải dưới tên bạn. Nếu họ do dự, đó là red flag.

"Bạn xử lý handover như thế nào?" Agency chuyên nghiệp có quy trình handover chuẩn. Nếu họ nhìn bạn ngơ ngác, họ chưa bao giờ nghĩ đến chuyện gì xảy ra sau khi launch.

"CI/CD setup của bạn trông như thế nào?" Pipeline tự động, staging environment, deployment script — những thứ này phải là tiêu chuẩn, không phải tùy chọn.

Bạn không đang khó tính khi hỏi những câu này. Bạn đang bảo vệ một khoản đầu tư đáng kể. Agency nào phản đối sự minh bạch cơ bản không phải agency bạn muốn xây dựng sản phẩm cốt lõi.

Xây Đúng Ngay Từ Đầu

Thị trường outsourcing đầy agency sẽ xây cho bạn thứ gì đó trông đẹp khi demo. Ít hơn sẽ xây thứ gì đó bền vững. Sự khác biệt không phải lúc nào cũng nhìn thấy trong proposal — nó hiện ra trong quyết định kiến trúc, chất lượng code, và những gì được bàn giao khi dự án kết thúc.

MVP không nên là proof of concept bạn sẽ vứt đi. Nó phải là nền tảng bạn có thể xây tiếp. Hãy đảm bảo team bạn thuê hiểu sự khác biệt đó.

Bài viết liên quan

Embedded Team vs. Staff Augmentation — Mô Hình Nào Ra Hàng Nhanh Hơn?
Kinh nghiệm thực chiến

Embedded Team vs. Staff Augmentation — Mô Hình Nào Ra Hàng Nhanh Hơn?

Cả hai mô hình đều hứa hẹn tăng tốc sản phẩm của bạn. Nhưng chỉ một trong số đó thực sự làm được điều đó. Đây là phân tích trung thực về staff augmentation và embedded team, cùng cách xác định mô hình nào phù hợp với tình huống của bạn.