Mở đầu — vì sao bài này quan trọng
Có một quyết định mà gần như mọi tech lead đều phải đối mặt, thường là vào lúc bất tiện nhất: nhóm của bạn cần một chức năng nào đó — hệ thống thanh toán, công cụ gửi email, hệ thống tìm kiếm, hàng đợi tin nhắn, dashboard phân tích — và bạn phải trả lời câu hỏi tưởng chừng đơn giản: "Chúng ta tự viết hay dùng cái có sẵn?"
Nghe thì đơn giản, nhưng đây là một trong những quyết định đắt giá nhất mà một tech lead đưa ra. Quyết định sai theo hướng "build" khiến đội bạn dành sáu tháng viết lại thứ mà một dịch vụ 200 đô/tháng làm tốt hơn. Quyết định sai theo hướng "buy" khiến bạn khóa chặt trái tim của sản phẩm vào một vendor, để rồi ba năm sau không thể đổi được, phải trả phí gấp mười lần, hoặc tệ hơn — vendor đóng cửa.
Điều làm cho quyết định này khó không phải là kỹ thuật. Về mặt kỹ thuật, hầu hết mọi thứ đều "build được". Cái khó là nó buộc bạn phải trả lời một câu hỏi chiến lược: năng lực engineering hữu hạn của đội nên đổ vào đâu để tạo ra giá trị lớn nhất cho business? Đây là lý do build vs buy là bài toán của leadership, không phải bài toán của lập trình viên. Trong bài này, chúng ta sẽ đi sâu vào khung tư duy để bạn đưa ra quyết định này một cách có kỷ luật, thay vì theo cảm tính hay theo cái tôi kỹ thuật.
Khái niệm cốt lõi
Câu hỏi trung tâm: đây có phải core differentiator không?
Trước mọi bảng tính chi phí, mọi so sánh tính năng, có một câu hỏi duy nhất bạn phải trả lời:
Component này có phải là yếu tố tạo nên sự khác biệt cạnh tranh (core differentiator) của business không?
Nếu có — đây là thứ khách hàng chọn bạn thay vì đối thủ, thứ tạo ra doanh thu, thứ chứa đựng IP (intellectual property — tài sản trí tuệ) và know-how của công ty — thì nghiêng mạnh về build. Bạn muốn kiểm soát trọn vẹn, muốn tự do phát triển theo hướng riêng, không muốn phụ thuộc vào roadmap của người khác.
Nếu không — đây chỉ là "hạ tầng cần có" mà mọi công ty đều cần, khách hàng không hề quan tâm bạn làm nó thế nào — thì nghiêng mạnh về buy. Mỗi giờ kỹ sư đổ vào đây là một giờ không dùng để làm thứ thực sự tạo khác biệt.
Ví dụ trực quan: Shopee không cạnh tranh nhau bằng việc ai viết được thư viện gửi email tốt hơn. Họ cạnh tranh bằng thuật toán gợi ý sản phẩm, bằng logistics, bằng trải nghiệm mua sắm. Vậy nên gửi email — buy. Recommendation engine — build.
Vì sao "buy" không có nghĩa là lười
Nhiều kỹ sư trẻ có định kiến rằng buy là "hèn", là không đủ giỏi để tự làm. Đây là tư duy nguy hiểm. Buy đúng chỗ chính là đòn bẩy chiến lược: nó giải phóng thời gian đắt đỏ nhất trong công ty — thời gian của kỹ sư giỏi — để dồn vào phần tạo ra khác biệt.
Hãy nghĩ theo chi phí cơ hội. Nếu đội bạn có 5 kỹ sư và mất 3 tháng để build một hệ thống xác thực (authentication) tự viết, thì cái giá thực không phải là lương 3 tháng của 5 người. Cái giá thực là những tính năng khách-hàng-thực-sự-muốn mà 5 người đó đã không làm trong 3 tháng ấy. Đó là chi phí cơ hội, và nó thường lớn hơn nhiều so với hóa đơn của Auth0 hay Firebase Auth.
Chi phí thật của "build" — tảng băng chìm
Sai lầm kinh điển là ước tính chi phí build chỉ bằng công sức viết phiên bản đầu tiên. Thực tế, phiên bản đầu chỉ là phần nổi của tảng băng. Chi phí thật của build gồm:
- Chi phí xây dựng ban đầu: viết code, test, tích hợp.
- Chi phí bảo trì vĩnh viễn: sửa bug, vá lỗ hổng bảo mật, nâng cấp theo thay đổi của hệ điều hành/thư viện. Cái này kéo dài suốt vòng đời sản phẩm.
- Chi phí kiến thức (bus factor): khi người viết nó nghỉ việc, ai hiểu hệ thống? Bạn có rơi vào cảnh không ai dám chạm vào "cái hộp đen" đó không?
- Chi phí cơ hội: như đã nói ở trên — thứ giá trị nhất mà đội bạn đã không làm.
Chi phí thật của "buy" — cũng có tảng băng chìm
Ngược lại, buy không phải là "trả tiền rồi quên". Nó có những chi phí ẩn riêng:
- Vendor lock-in: mức độ khó khăn khi muốn rời bỏ vendor. API độc quyền, định dạng dữ liệu riêng, khiến chi phí chuyển đổi (switching cost) tăng vọt theo thời gian.
- Chi phí leo thang theo quy mô: dịch vụ 200 đô/tháng lúc bạn có 1.000 người dùng có thể thành 50.000 đô/tháng khi bạn có 1 triệu người dùng. Nhiều mô hình định giá SaaS trừng phạt sự thành công của bạn.
- Giới hạn tùy biến: bạn bị nhốt trong những gì vendor cho phép. Cần một tính năng đặc thù? Chờ họ làm, hoặc không bao giờ có.
- Rủi ro vendor: họ tăng giá, đổi chính sách, bị mua lại, hoặc đóng cửa.
Lằn ranh xám: khi câu trả lời không rõ ràng
Đa số quyết định rơi vào vùng xám. Vài yếu tố giúp phân định:
- Độ trưởng thành của công ty: startup giai đoạn đầu nên buy gần như mọi thứ để chạy nhanh và tìm product-market fit. Công ty lớn đã có quy mô mới đủ nguồn lực để build những phần chiến lược.
- Tính sẵn có của giải pháp thị trường: nếu có giải pháp tốt, trưởng thành trên thị trường — buy. Nếu không có gì phù hợp với bài toán đặc thù của bạn — build có lý hơn.
- Yêu cầu tuân thủ và dữ liệu nhạy cảm: dữ liệu y tế, tài chính, hoặc yêu cầu dữ liệu phải nằm trong nước (data residency) đôi khi buộc bạn build hoặc self-host.
Tình huống thực tế
Tình huống 1: Tiki và bài toán search
Bối cảnh: Một sàn thương mại điện tử Việt Nam (tình huống dựa trên mẫu hình chung của các sàn như Tiki, Sendo) ở giai đoạn tăng trưởng nhanh. Chức năng tìm kiếm sản phẩm ban đầu được ghép tạm bằng LIKE '%keyword%' trên MySQL. Khi catalog vượt 2 triệu sản phẩm, search trở nên chậm và cho kết quả kém, tỉ lệ chuyển đổi từ trang tìm kiếm tụt rõ rệt.
Quyết định: Đội cân nhắc ba lựa chọn. Một là tự build search engine từ đầu (build thuần). Hai là dùng dịch vụ managed search như Algolia (buy thuần). Ba là dùng Elasticsearch/OpenSearch mã nguồn mở tự vận hành (con đường lai).
Diễn giải: Họ nhận ra search là core differentiator — trên một sàn TMĐT, khả năng khách tìm đúng thứ họ muốn ảnh hưởng trực tiếp đến doanh thu. Nhưng build một search engine từ con số không (viết cả inverted index, ranking) là điên rồ khi đã có công nghệ chín muồi. Algolia thì tuyệt vời lúc đầu nhưng chi phí leo thang khủng khiếp ở quy mô hàng chục triệu truy vấn/tháng, và họ không tùy biến được thuật toán ranking theo đặc thù người Việt (dấu tiếng Việt, từ đồng nghĩa "áo thun/áo phông"). Họ chọn con đường lai: dùng Elasticsearch mã nguồn mở (buy nền tảng), nhưng build lớp ranking và relevance tuning riêng phía trên (build phần khác biệt).
Bài học: Quyết định không phải "build hay buy" mà là "build phần nào, buy phần nào". Mua nền tảng công nghệ, tự xây phần chứa IP và tạo khác biệt.
Tình huống 2: Startup fintech và cám dỗ tự làm cổng thanh toán
Bối cảnh: Một startup fintech ở TP.HCM, 8 kỹ sư, đang xây ứng dụng ví điện tử. Một kỹ sư cứng cựa đề xuất tự build lớp tích hợp thanh toán và đối soát trực tiếp với từng ngân hàng, thay vì dùng cổng trung gian như VNPAY, MoMo, hay ZaloPay. Lý lẽ của anh: "Tự làm thì không mất phí giao dịch cho bên trung gian, mà mình lại kiểm soát toàn bộ."
Quyết định: Tech lead phản đối và chọn buy — tích hợp qua cổng thanh toán có sẵn.
Diễn giải: Nghe qua thì lý lẽ tự build có vẻ hợp lý về mặt chi phí. Nhưng tech lead nhìn ra tảng băng chìm: tích hợp trực tiếp với ngân hàng đòi hỏi hợp đồng pháp lý, tuân thủ chuẩn bảo mật (PCI DSS), quy trình đối soát cực kỳ phức tạp, và mỗi ngân hàng lại một kiểu API. 8 kỹ sư sẽ chìm nghỉm trong đây cả năm, trong khi sản phẩm cốt lõi — trải nghiệm ví và các tính năng tài chính cá nhân — không được đầu tư. Quan trọng nhất: xử lý thanh toán không phải thứ khách hàng chọn họ. Không ai tải app ví vì "họ tích hợp ngân hàng trực tiếp". Chi phí giao dịch cho cổng trung gian là cái giá hoàn toàn xứng đáng để đổi lấy tốc độ ra thị trường.
Bài học: Đừng để cái tôi kỹ thuật ("tôi làm được") lấn át câu hỏi chiến lược ("tôi có nên làm không"). Ở giai đoạn đầu, buy để chạy nhanh gần như luôn thắng.
Tình huống 3: Dropbox và quyết định "build" ngược dòng
Bối cảnh: Trong nhiều năm, Dropbox lưu trữ toàn bộ dữ liệu người dùng trên Amazon S3 — một quyết định buy hoàn toàn hợp lý ở giai đoạn đầu, giúp họ tập trung vào trải nghiệm đồng bộ file. Nhưng khi đạt quy mô hàng trăm petabyte, họ đã build hệ thống lưu trữ riêng ("Magic Pocket") và rời khỏi S3.
Diễn giải: Đây là ví dụ kinh điển cho thấy quyết định build vs buy không phải là vĩnh viễn. Ở quy mô của Dropbox, lưu trữ chính là core differentiator — nó chiếm phần lớn chi phí vận hành và là trái tim kỹ thuật của sản phẩm. Tự vận hành hạ tầng lưu trữ giúp họ tiết kiệm hàng trăm triệu đô và tối ưu sâu cho use case của mình. Nhưng lưu ý: họ chỉ build khi đã đủ lớn để có nguồn lực và khi kinh tế học của việc build trở nên thắng thế. Nếu build từ ngày một, Dropbox đã chết trước khi kịp lớn.
Bài học: Quyết định đúng ở giai đoạn này có thể sai ở giai đoạn khác. Hãy đặt lại câu hỏi build vs buy định kỳ khi quy mô và chiến lược thay đổi.
Hướng dẫn từng bước
Đây là quy trình có kỷ luật để đưa ra quyết định build vs buy cho một component cụ thể:
Bước 1 — Trả lời câu hỏi differentiator trước. Hỏi thẳng: component này có nằm trong lõi cạnh tranh của business không? Nếu khách hàng không bao giờ thấy hay quan tâm đến nó, khả năng cao là buy. Đây là bộ lọc quan trọng nhất; đừng bỏ qua để nhảy thẳng vào so sánh tính năng.
Bước 2 — Khảo sát thị trường. Có giải pháp trưởng thành nào tồn tại không? Nó phủ được bao nhiêu phần trăm nhu cầu của bạn? Nếu một sản phẩm sẵn có đáp ứng 80% nhu cầu và 20% còn lại không phải deal-breaker — đó là dấu hiệu mạnh cho buy.
Bước 3 — Ước tính tổng chi phí sở hữu (TCO) của cả hai con đường. Với build: cộng cả chi phí xây dựng, bảo trì trong 3 năm, và chi phí cơ hội. Với buy: cộng phí license theo quy mô dự kiến (không phải quy mô hiện tại), chi phí tích hợp, và ước tính chi phí thoát (exit cost). So sánh trên cùng một khung thời gian, ví dụ 3 năm.
Bước 4 — Đánh giá rủi ro của từng hướng. Build: rủi ro bus factor, rủi ro trễ tiến độ. Buy: rủi ro lock-in, rủi ro vendor. Với mỗi rủi ro lớn, hỏi "nếu điều tệ nhất xảy ra, chúng ta làm gì?"
Bước 5 — Xem xét con đường lai. Rất hiếm khi câu trả lời là build-thuần hoặc buy-thuần. Thường tối ưu nhất là: buy nền tảng (mã nguồn mở hoặc SaaS), build lớp mỏng chứa logic khác biệt phía trên. Hoặc buy trước để ra thị trường, lên kế hoạch build sau khi đủ quy mô.
Bước 6 — Thiết kế để giảm chi phí đảo ngược quyết định. Nếu buy, hãy bọc dịch vụ của vendor sau một lớp trừu tượng (abstraction layer / adapter) trong code của bạn, để sau này đổi vendor đỡ đau. Điều này khiến quyết định trở thành "cửa hai chiều" thay vì "cửa một chiều".
Bước 7 — Ghi lại quyết định. Viết ngắn gọn: lựa chọn là gì, các phương án đã cân nhắc, lý do chọn. Sáu tháng sau khi ai đó hỏi "sao hồi đó không tự build", bạn có câu trả lời rõ ràng.
Lỗi thường gặp & mẹo
Lỗi 1 — "Not Invented Here" syndrome. Xu hướng tự build mọi thứ vì không tin dùng đồ của người khác, hoặc vì kỹ sư thấy tự build vui hơn. Đây là bẫy cái tôi. Mẹo: luôn buộc người đề xuất build phải trả lời "vì sao giải pháp có sẵn không đủ tốt?" bằng dữ liệu, không phải cảm giác.
Lỗi 2 — Chỉ tính chi phí xây dựng, quên chi phí bảo trì. Đội hào hứng viết phiên bản đầu trong 2 tuần rồi dành 2 năm bảo trì trong đau khổ. Mẹo: khi ước tính build, luôn nhân chi phí bảo trì và tự hỏi "ai sẽ chăm nó trong 3 năm tới?"
Lỗi 3 — Ước tính chi phí buy theo quy mô hiện tại. Dịch vụ rẻ hôm nay có thể phá sản bạn khi thành công. Mẹo: luôn tính giá theo quy mô mục tiêu, không phải quy mô hiện tại.
Lỗi 4 — Bỏ qua chi phí thoát. Buy dễ, thoát khó. Mẹo: trước khi ký, hỏi "nếu một năm nữa muốn rời, sẽ tốn bao nhiêu công?" Nếu câu trả lời khiến bạn rùng mình, hãy đầu tư ngay vào lớp trừu tượng.
Lỗi 5 — Xem quyết định là bất biến. Đúng ở startup không có nghĩa đúng ở scale-up. Mẹo: gắn nhãn các quyết định "buy vì chạy nhanh" và hẹn xem lại khi đạt cột mốc quy mô nhất định.
Mẹo tổng quát: Phân loại quyết định thành "cửa một chiều" (khó đảo ngược, cần cẩn trọng — ví dụ chọn database chính) và "cửa hai chiều" (dễ đảo ngược, cứ quyết nhanh — ví dụ chọn công cụ gửi email). Đừng phân tích quá mức cho quyết định cửa hai chiều.
Bài tập thực hành
- Lập ma trận cho đội bạn. Liệt kê 8–10 component/hệ thống mà đội bạn đang dùng (auth, thanh toán, gửi email, logging, search, CI/CD...). Với mỗi cái, đánh dấu "core differentiator: có/không" và "hiện đang build/buy". Bạn có phát hiện chỗ nào build cái không nên build, hoặc buy cái đáng lẽ nên build không?
- Viết một trang quyết định. Chọn một quyết định build vs buy mà đội bạn sắp phải đưa ra. Áp dụng 7 bước ở trên và viết một tài liệu một trang: phương án cân nhắc, TCO 3 năm của mỗi hướng, rủi ro, và khuyến nghị cuối cùng có lý do rõ ràng.
- Tính chi phí thoát. Chọn một vendor quan trọng mà đội bạn đang phụ thuộc. Ước tính: nếu phải rời vendor này trong 6 tháng tới, cần bao nhiêu công sức? Có lớp trừu tượng nào bảo vệ bạn không? Nếu không, phác thảo lớp trừu tượng đó.
Tóm tắt
Build vs buy về bản chất không phải câu hỏi kỹ thuật mà là câu hỏi chiến lược về việc phân bổ nguồn lực engineering khan hiếm. Bộ lọc quan trọng nhất là: component này có phải core differentiator không — nếu có thì nghiêng về build để giữ kiểm soát và IP, nếu không thì nghiêng về buy để giải phóng kỹ sư cho phần tạo khác biệt.
Cả build và buy đều có tảng băng chìm: build kéo theo chi phí bảo trì và cơ hội gấp nhiều lần chi phí xây ban đầu; buy kéo theo lock-in và chi phí leo thang theo quy mô. Phần lớn quyết định tốt là con đường lai — mua nền tảng, tự xây phần khác biệt phía trên. Hãy quyết định có kỷ luật qua bảy bước, thiết kế để dễ đảo ngược, ghi lại lý do, và nhớ rằng quyết định đúng hôm nay có thể cần xem lại khi công ty lớn lên. Đừng để cái tôi "tôi làm được" thắng câu hỏi "tôi có nên làm không".