Buổi pitch suôn sẻ. Nhà đầu tư thích bản demo, cái deck "ghi điểm", term sheet đã trong tầm tay. Rồi họ mời một cố vấn kỹ thuật vào "đạp lốp xe thử". Cố vấn đó mở nắp ca-pô — code thật, kiến trúc, cách dữ liệu chảy — và bắt đầu hỏi những câu MVP của bạn không trả lời được. Đột nhiên vòng gọi vốn tưởng đã xong lại khựng lại. Đây là due diligence kỹ thuật (technical due diligence), và là chỗ mà một số lượng đáng ngạc nhiên các startup vốn dĩ gọi được vốn lại mất đà. Tin tốt: nó có thể đoán trước được. Nếu biết thứ gì sẽ bị soi, bạn xây được thứ qua được. Bài này đi qua đúng điều đó.
Due diligence kỹ thuật là phần trong quá trình rà soát của nhà đầu tư, nơi họ (hoặc một người họ tin) đánh giá xem công nghệ của bạn có thật, có vững, và có sở hữu được không. Nó không bàn demo có đẹp không. Nó bàn thứ nằm bên dưới có sống sót khi gặp người dùng thật, dữ liệu thật và một cap table thật hay không.
Với vòng pre-seed và seed, phần này thường nhẹ hơn các cuộc audit kéo dài nhiều tuần mà công ty giai đoạn sau phải chịu — đôi khi chỉ là một buổi review code và vài cuộc trò chuyện trúng đích. Nhưng "nhẹ hơn" không có nghĩa là "bỏ qua". Một angel sắc sảo hoặc một quỹ có bất kỳ technical partner nào cũng sẽ nhìn. Và thứ họ tìm thấy định đoạt mức độ tự tin khi họ ký séc — hoặc liệu họ có ép đàm phán lại điều khoản.
Sai lầm của founder là coi MVP như một đạo cụ bán hàng — thứ chỉ cần trông ổn trong mười phút demo. Due diligence kỹ thuật giả định điều ngược lại: rằng code là một tài sản thật mà họ đang mua một phần. Đó là hai cái chuẩn rất khác nhau.
Một cố vấn kỹ thuật không audit MVP của bạn cho vui. Họ trả lời đúng một câu hỏi cho nhà đầu tư: rủi ro thật trong công nghệ này là gì? Câu đó chia thành vài mảng họ sẽ nhìn, dù bạn ở giai đoạn sớm tới đâu.
Chất lượng code và kiến trúc. Codebase có gọn gàng, dễ đọc không, hay là một mớ rối chỉ tác giả gốc hiểu? Một kỹ sư mới có làm việc hiệu quả trong vài ngày không? Kiến trúc hợp lý cho giai đoạn hiện tại — và không tự dồn mình vào chân tường — báo hiệu một team biết xây.
Khả năng scale. Không phải "cái này chịu được một triệu user" — chẳng ai kỳ vọng thế ở seed. Câu hỏi là thiết kế có những bức tường rõ ràng không. Nó có đổ ngay ở trăm user đồng thời đầu tiên không? Có một nút thắt cơ bản nào buộc phải viết lại đúng lúc bạn bắt đầu tăng trưởng không? Một bức tường nhìn thấy được từ đây là dấu hiệu đáng ngại.
Bảo mật. Credential lộ thiên, endpoint không bảo vệ, không validate input, secret commit thẳng vào repo. Đây là những thứ đầu tiên một reviewer giỏi kiểm tra, và chúng phổ biến đến mức ngượng trong các MVP làm vội.
IP và quyền sở hữu code. Cái này làm khựng deal nhiều hơn founder tưởng — nói kỹ ở dưới.
Nợ kỹ thuật và rủi ro phụ thuộc một người. Bao nhiêu phần của bản build là đường tắt rồi sẽ phải gỡ ra làm lại? Và nếu một người ngày mai rời đi, kiến thức để bảo trì cái này có đi theo họ không?
Dependency bên thứ ba và license. Sản phẩm của bạn phụ thuộc vào gì, và các license đó có tương thích với kinh doanh thương mại không? Một dependency lỡ dính license copyleft có thể là vấn đề thật sự.
Xử lý dữ liệu và tuân thủ. Nếu bạn chạm tới dữ liệu y tế, thanh toán, hay thông tin cá nhân, bạn có xử lý đúng luật không? Trong ngành quản lý chặt, một lỗ hổng HIPAA hay PCI DSS không phải chú thích nhỏ — nó là trách nhiệm pháp lý mà nhà đầu tư giờ cũng dính vào.
Đây là phần đáng lưu lại. Khi một cố vấn kỹ thuật ngồi xuống với MVP của bạn, đại khái đây là checklist của họ. Hãy coi nó như cuộc audit-trước-gọi-vốn của chính bạn.
Hãy tự chấm điểm thành thật theo mười mục đó trước khi nhà đầu tư làm thay bạn. Phần lớn MVP pre-seed qua được ba hoặc bốn mục. Khoảng cách giữa ba và mười chính là khoảng cách giữa một vòng diligence trơn tru và một vòng khựng lại.
Qua các cuộc review này, cùng những vấn đề lặp đi lặp lại. Nếu MVP của bạn dính bất kỳ điều nào, hãy giả định một cố vấn kỹ thuật sẽ tìm ra.
Dữ liệu hardcode. Demo chạy được vì "dữ liệu" được fake trong source. Click qua một bước khỏi happy path là nó vỡ. Reviewer cố tình test đúng cái path đó.
Không có audit trail. Không gì ghi lại ai đổi cái gì. Với sản phẩm quản lý chặt thì đây là điểm loại; với mọi sản phẩm thì nó nói cho reviewer biết phần nền tảng không hào nhoáng đã bị bỏ qua.
Không scale quá N user. Một thiết kế chạy được cho bản demo trên laptop của founder nhưng có trần cứng — một lời gọi database quá tải, không xử lý async, blocking khắp nơi — biến tăng trưởng thành một bản viết lại.
Sở hữu code mập mờ. Bạn thuê một agency, và hợp đồng nói lập lờ về việc ai sở hữu kết quả — hoặc tệ hơn, họ giữ nó và bạn thực chất đang đi thuê chính sản phẩm của mình. Nhà đầu tư ghét điều này, và nó phổ biến hơn founder tưởng nhiều. Nhiều shop khóa khách bằng cách giữ source, hạ tầng, hoặc khóa deploy.
Không có test. Zero coverage tự động nghĩa là mọi thay đổi tương lai là một canh bạc. Reviewer đọc "không test" thành "team này ship bằng niềm tin".
Lỗ hổng bảo mật. API key hardcode, một route admin không auth, input người dùng đẩy thẳng vào câu query database. Bất kỳ cái nào trong số này cũng biến một buổi review thân thiện thành một cuộc nói chuyện căng thẳng.
Để ý xem bao nhiêu trong số này là về phần 99% nhàm chán — sở hữu, test, logging, xử lý dữ liệu — chứ không phải tính năng thông minh trong demo của bạn. Đó chính là điểm mấu chốt. 1% thông minh chỉ sống được nếu 99% không hào nhoáng đỡ nó.
Trong tất cả, sở hữu code xứng đáng có cảnh báo riêng, vì đây là cái founder hay đâm đầu vào mà không thấy trước. Khi bạn outsource MVP, lựa chọn rẻ hoặc nhanh thường kèm điều kiện ngầm: agency giữ IP, giữ source, hoặc trói bạn vào hợp đồng bảo trì vì bạn không thể mang code đi đâu khác. Trong demo, chẳng cái nào lộ ra. Trong due diligence MVP, đó là một trong những thứ đầu tiên cố vấn của nhà đầu tư hỏi — và một câu trả lời mập mờ có thể làm khựng term sheet.
Cách khắc phục mang tính cấu trúc, không phải thứ vá sau: sở hữu mọi thứ ngay từ ngày đầu. Ở BeevR, bạn sở hữu 100% code — source, hạ tầng và IP — từ commit đầu tiên, không lock-in. Khi nhà đầu tư hỏi "ai sở hữu cái này?", câu trả lời nên là một từ "chúng tôi", có giấy tờ chống lưng.
Bạn không cần over-engineer một sản phẩm giai đoạn seed. Bạn cần xây đúng thứ tới một chuẩn thật: kiến trúc sạch, luồng dữ liệu thật, test ở những chỗ quan trọng, một audit trail, bảo mật tỉnh táo, và quyền sở hữu rõ ràng. Đó là việc BeevR làm — phần mềm cấp production và AI tiên tiến cho ngành quản lý chặt, làm bởi đội chỉ senior do founder dẫn dắt, không có rào cản project-manager giữa bạn và những người viết code. Xem chúng tôi làm gì, hoặc xem cách chúng tôi scope một MVP sẵn sàng gọi vốn với giá cố định và thời gian cố định.
Triết lý của chúng tôi đơn giản: thà đáng tin còn hơn gây ấn tượng. Chúng tôi xây phần 99% không hào nhoáng để 1% thông minh sống sót — và vòng gọi vốn của bạn cũng vậy.
Đang gọi vốn và lo MVP không trụ nổi? BeevR ship MVP sẵn sàng gọi vốn với giá cố định và thời gian cố định, và bạn sở hữu từng dòng code ngay từ ngày đầu. Đặt lịch tư vấn →