Build vs Buy — câu hỏi muôn thuở, nhưng cách hỏi đúng thường bị bỏ qua#

"Build vs Buy" là một trong những quyết định công nghệ quan trọng nhất mà chủ doanh nghiệp SME phải đưa ra. Sai lầm phổ biến: dùng một tiêu chí duy nhất (thường là giá hoặc thời gian) để quyết định, thay vì đánh giá toàn bộ bối cảnh.

Bài viết này tổng hợp 10 yếu tố cần cân nhắc, một weighted decision matrix để chấm điểm, và 5 câu hỏi then chốt giúp bạn đưa ra quyết định phù hợp với use case của mình.

Tóm tắt

Quyết định Build (xây app riêng) hay Buy (dùng SaaS) phụ thuộc vào ít nhất 10 yếu tố: mức độ đặc thù của quy trình, số lượng người dùng, độ phức tạp tích hợp, quyền kiểm soát dữ liệu, yêu cầu compliance, TCO 3 năm, time-to-market, năng lực kỹ thuật nội bộ, lợi thế cạnh tranh, và rủi ro vendor lock-in. Không có công thức chung cho mọi trường hợp.

10 yếu tố quyết định Build vs Buy#

1. Mức độ đặc thù của quy trình#

Buy (SaaS) phù hợp khi: Quy trình của bạn là "tiêu chuẩn ngành" — 80% doanh nghiệp cùng ngành làm giống nhau. Ví dụ: bán hàng online, quản lý nhân sự cơ bản, kế toán — đã có SaaS trưởng thành.

Build phù hợp khi: Quy trình là "lợi thế cạnh tranh" — chỉ doanh nghiệp bạn mới có cách làm này. Ví dụ: thuật toán định giá độc quyền, workflow vận hành phức tạp nhiều bên, thuật toán matching logistics riêng.

Câu hỏi test: "Nếu đối thủ copy y quy trình này, mình có mất lợi thế không?"

  • Không → SaaS là đủ
  • Có → Build phần lõi (có thể vẫn dùng SaaS cho phần phổ thông)

2. Số lượng người dùng & quy mô#

Quan sát thực tế: Số lượng người dùng một mình không quyết định Build vs Buy — cần kết hợp với các yếu tố khác. Một CRM 5 người dùng cho ngân hàng có compliance nghiêm ngặt vẫn nên Build. Một CRM 50 người dùng cho công ty marketing thông thường vẫn có thể dùng SaaS.

Hướng dẫn tham khảo:

  • < 5 người dùng: SaaS thường rẻ hơn, trừ khi có yêu cầu đặc biệt
  • 5–20 người: tuỳ độ phức tạp, cần đánh giá cụ thể

  • 20 người: Build custom bắt đầu có lợi nếu quy trình đặc thù

  • 100 người: Build thường là lựa chọn tốt hơn về dài hạn

3. Độ phức tạp tích hợp#

Buy phù hợp khi: Chỉ cần kết nối 1–3 hệ thống phổ biến (CRM + email + spreadsheet). SaaS thường có sẵn Zapier/Make integration hoặc API có documentation tốt.

Build phù hợp khi: Cần tích hợp 5–10+ hệ thống với logic phức tạp (ERP + CRM + POS + accounting + custom internal). Cần tầng integration riêng.

4. Quyền kiểm soát dữ liệu#

Buy phù hợp khi:

  • OK với data ở trên cloud của vendor
  • Vendor có compliance tốt (ISO 27001, SOC 2, GDPR-ready)
  • Ít cần custom workflow
  • Đội ngũ không có khả năng maintain code

Build phù hợp khi:

  • Dữ liệu nhạy cảm (y tế, tài chính, quốc phòng) — cần on-premise
  • Cần tích hợp sâu với hệ thống nội bộ khác
  • Có đội ngũ dev in-house hoặc outsource dài hạn
  • Theo ngành có quy định riêng về data residency (ví dụ: dữ liệu phải lưu trong nước)

5. Yêu cầu compliance#

Một số ngành có yêu cầu compliance mà SaaS thông thường không đáp ứng:

  • Y tế: HIPAA (Mỹ), các quy định của Bộ Y tế Việt Nam
  • Tài chính: PCI-DSS cho xử lý thẻ, các quy định của NHNN
  • Dữ liệu cá nhân: Nghị định 13/2023 về bảo vệ dữ liệu cá nhân của Việt Nam
  • Quốc phòng, an ninh: yêu cầu on-premise gần như tuyệt đối

Trong các trường hợp này, Build hoặc SaaS chuyên ngành có compliance sẵn là lựa chọn hợp lệ.

6. TCO (Total Cost of Ownership) 3 năm#

TCO 3 năm là thước đo thực tế nhất. Bao gồm: setup + vận hành hàng tháng × 36 + chi phí nâng cấp/bảo trì + chi phí chuyển đổi nếu cần.

Ví dụ minh hoạ (số liệu ước tính, không phải dự án DsAI cụ thể):

Khoản mục SaaS (vd: Salesforce) Build Custom
Setup ban đầu 0–20 triệu 100–500 triệu
Vận hành/tháng 5–30 triệu/user 5–15 triệu (hosting + dev)
Nâng cấp/năm Free (vendor lo) 20–50% chi phí dev ban đầu
Switching cost Cao (vendor lock-in) Thấp (mình giữ code)
TCO 3 năm (5 users) 180–1.080 triệu 280–800 triệu

Con số này chỉ mang tính minh hoạ. TCO thực tế phụ thuộc rất nhiều vào use case cụ thể. Hãy lập bảng TCO cho dự án của bạn trước khi quyết định.

7. Time-to-market#

Buy phù hợp khi: Cần go-live trong 1–4 tuần. Setup Salesforce, HubSpot, KiotViet, sCoffee... → vài giờ đến vài ngày.

Build phù hợp khi: Có thể chờ 3–12 tháng. MVP custom: 2–4 tháng. Production-ready: 6–12 tháng.

Câu hỏi then chốt: "Nếu không có giải pháp, mình chịu được bao lâu?"

  • < 1 tháng → SaaS (hoặc workaround tạm)
  • 1–3 tháng → SaaS + custom integration

  • 3 tháng → Build được

8. Năng lực kỹ thuật nội bộ#

Build yêu cầu:

  • Có đội ngũ dev in-house HOẶC đối tác outsource dài hạn (không phải 1 dev freelance)
  • Có khả năng maintain, debug, scale sau khi launch
  • Có người hiểu kiến trúc, security, deployment

Nếu không có: Build sẽ thành "abandoned project" sau 6–12 tháng. SaaS an toàn hơn.

9. Lợi thế cạnh tranh & IP#

Build phù hợp khi: Hệ thống là một phần cốt lõi của sản phẩm/dịch vụ. Ví dụ: thuật toán AI độc quyền, workflow logistics khác biệt, tool nội bộ quyết định tốc độ ra quyết định. IP thuộc về bạn = lợi thế cạnh tranh dài hạn.

Buy phù hợp khi: Hệ thống là hỗ trợ vận hành, không phải cốt lõi sản phẩm. Ví dụ: CRM, kế toán, HR — không có gì đặc biệt nếu đối thủ cũng dùng.

10. Rủi ro vendor lock-in#

Vendor lock-in = sự phụ thuộc vào một nhà cung cấp cụ thể. Khi dữ liệu, workflow, training đã gắn với vendor, việc chuyển sang giải pháp khác rất tốn kém.

Cách giảm thiểu khi chọn SaaS:

  • Chọn vendor có open API tốt
  • Export data định kỳ về local
  • Tránh SaaS dùng proprietary format độc quyền
  • Đọc kỹ điều khoản về data ownership khi hợp đồng kết thúc

Nếu lock-in cao + workflow quan trọng: Build là lựa chọn an toàn hơn về dài hạn.

Weighted Decision Matrix — cách chấm điểm#

Để ra quyết định có cơ sở, hãy chấm điểm cho từng yếu tố theo mức độ quan trọng với use case của bạn:

Yếu tố Trọng số (tổng = 100%) Điểm SaaS (1–10) Điểm Build (1–10) Điểm có trọng số (SaaS) Điểm có trọng số (Build)
Đặc thù quy trình _ % _ _ _ _
Số người dùng _ % _ _ _ _
Độ phức tạp tích hợp _ % _ _ _ _
Quyền kiểm soát dữ liệu _ % _ _ _ _
Compliance _ % _ _ _ _
TCO 3 năm _ % _ _ _ _
Time-to-market _ % _ _ _ _
Năng lực kỹ thuật _ % _ _ _ _
Lợi thế cạnh tranh _ % _ _ _ _
Vendor lock-in _ % _ _ _ _
Tổng 100% ___ ___

Cách dùng:

  1. Phân bổ trọng số cho 10 yếu tố theo mức quan trọng với use case (tổng = 100%)
  2. Chấm điểm 1–10 cho SaaS và Build ở mỗi yếu tố (1 = rất tệ, 10 = rất tốt)
  3. Tính điểm có trọng số = trọng số × điểm
  4. So sánh tổng: bên nào cao hơn → ưu tiên bên đó

Lưu ý: Điểm số không phải câu trả lời tuyệt đối, mà là công cụ để buộc bạn đánh giá rõ ràng thay vì cảm tính. Nếu tổng điểm 2 bên chênh lệch < 15%, có thể là tín hiệu cần xem xét cả hybrid (vừa SaaS vừa Build).

5 câu hỏi then chốt trước khi Build#

Nếu sau khi phân tích bạn nghiêng về Build, hãy tự trả lời 5 câu hỏi sau. Nếu ≥ 2 câu trả lời "Không" hoặc "Không chắc", cần xem xét lại:

1. Use case này có khác biệt rõ ràng so với SaaS có sẵn không?

  • Có, và khác biệt đó tạo lợi thế cạnh tranh → Build
  • Không, SaaS đáp ứng 80% nhu cầu → Mua SaaS

2. Có đội ngũ dev in-house hoặc đối tác dài hạn (ít nhất 3 năm) không?

  • Có → Build
  • Không → Build rủi ro cao, cân nhắc SaaS

3. ROI dự kiến có đủ hấp dẫn không?

  • Payback < 12 tháng → Build
  • Payback > 24 tháng → Chỉ Build nếu là chiến lược dài hạn

4. Có thể bắt đầu với MVP và mở rộng dần không?

  • Có thể MVP trong 3 tháng, scale sau → Build
  • Phải làm full ngay từ đầu → Khó khăn, Build chậm

5. Có kế hoạch rõ ràng cho việc maintain sau launch không?

  • Có ngân sách + người chịu trách nhiệm → Build
  • Không có kế hoạch → Build sẽ thành abandoned project

Khi nào KHÔNG nên Build (ngay cả khi ma trận nghiêng về Build)#

1. Ngân sách < 100 triệu và chưa có dev. Setup custom app đúng cách cần ít nhất 100 triệu (chi phí dev). Nếu ngân sách thấp hơn, kết quả thường là sản phẩm nửa vời, không ai dùng.

2. Cần go-live trong < 1 tháng. Build không thể đáp ứng deadline này. Dùng SaaS hoặc workaround tạm.

3. Workflow chưa ổn định. Nếu quy trình vẫn đang thay đổi hàng tháng, Build xong sẽ phải rewrite liên tục. Đợi workflow ổn định 3–6 tháng rồi mới Build.

4. Có thể mua SaaS + custom hóa nhẹ. Đôi khi "Build" thực chất chỉ là "dùng SaaS + viết thêm custom module/integration". Đây thường là lựa chọn tốt hơn Build from scratch.

5. Đối thủ đã có SaaS trưởng thành cho use case này. Nếu đối thủ và nhiều doanh nghiệp cùng ngành đều dùng SaaS X, có lý do. Build từ đầu = bạn tự đi một mình, chấp nhận nhiều rủi ro.

Mô hình Hybrid — thường là lựa chọn tốt nhất#

Qua triển khai, chúng tôi nhận thấy hybrid (vừa SaaS vừa Build cho từng phần) thường cho kết quả tốt hơn cả Build-all hoặc Buy-all:

Thành phần SaaS nên dùng Build nên dùng
Email, calendar Google Workspace, Microsoft 365 —
CRM cơ bản HubSpot, Pipedrive —
Kế toán MISA, Fast —
HR, payroll MISA meInvoice, Base —
Bán hàng cơ bản Shopify, Sapo, KiotViet —
Workflow đặc thù — Custom build
Tích hợp giữa các hệ thống Zapier, Make (cho case đơn giản) Middleware custom (cho case phức tạp)
Dashboard custom Google Data Studio, Metabase (cơ bản) Custom (real-time, AI-driven)
AI/ML models — Custom build

Ví dụ thực tế từ triển khai của DsAI (ẩn danh theo NDA, số liệu ước tính):

Khách hàng logistics (chuỗi 3 kho):

  • Kế toán: MISA (SaaS)
  • CRM: HubSpot (SaaS)
  • Workflow vận hành đặc thù: Custom build
  • Tích hợp: Middleware custom
  • Kết quả: TCO thấp hơn ước tính nếu build all-in-one; time-to-market nhanh hơn đáng kể so với build toàn bộ

5 lỗi thường gặp khi quyết định Build vs Buy#

Lỗi 1 — "Build vì sếp thích." Sếp muốn có app "của riêng mình" nhưng không có use case rõ ràng. Sau 6–12 tháng, dự án bị abandon vì không có người dùng.

Lỗi 2 — "Chọn SaaS rẻ nhất." Cứ chọn cái rẻ nhất, sau vài tháng phát hiện không scale, thiếu tính năng. Switching cost cao, tốn gấp đôi.

Lỗi 3 — "Build nhưng giống SaaS có sẵn." 6 tháng làm ra cái CRM, kết quả = Salesforce 80% features, tốn 500 triệu. Tốt hơn: dùng Salesforce + custom integration.

Lỗi 4 — "Dùng SaaS khi cần Build." Quy trình đặc thù quá, ép vào SaaS → workaround phức tạp, hiệu quả kém.

Lỗi 5 — "Không tính TCO 3 năm." Chỉ nhìn chi phí setup ban đầu, bỏ qua chi phí vận hành + nâng cấp + switching cost. Quyết định sai vì thiếu thông tin.

Câu hỏi thường gặp#

Số lượng người dùng bao nhiêu thì nên Build?

Không có con số chính xác. Phụ thuộc vào 9 yếu tố còn lại. Có team 5 người cần Build (compliance y tế), có team 50 người vẫn dùng SaaS (marketing thông thường). Hãy đánh giá tổng thể, không dùng "20 users = build" như một ngưỡng cứng.

Build hay mua SaaS có sẵn rồi customize?

Đây là câu hỏi thực tế hơn. Một số SaaS cho phép customize qua API, custom fields, custom workflows. Nếu mức customize đáp ứng 80% nhu cầu, đây là lựa chọn tốt nhất: SaaS + customize nhẹ = giảm chi phí + tăng tốc độ.

Hybrid (SaaS + Build) có phức tạp không?

Có, phức tạp hơn Build-all hoặc Buy-all. Nhưng thường cho kết quả tốt nhất. Cần 1 người (hoặc team nhỏ) chịu trách nhiệm quản lý tích hợp giữa các hệ thống. Nếu không có người này, hybrid sẽ trở thành "mớ hỗn độn" sau 1–2 năm.

Có thể chuyển từ SaaS sang Build sau không?

Có, nhưng tốn kém. Bạn sẽ phải:

  • Migrate data từ SaaS sang hệ thống mới
  • Train lại user
  • Maintain song song trong thời gian chuyển tiếp

Do đó, quyết định SaaS có nghĩa là chấp nhận vendor lock-in ở một mức độ nào đó. Hãy đánh giá kỹ trước khi chọn SaaS, hoặc chọn SaaS có open API tốt để dễ migrate sau.

Tổng kết#

Quyết định Build vs Buy không nên dựa trên cảm tính hoặc một tiêu chí duy nhất. Hãy đánh giá đầy đủ 10 yếu tố, sử dụng weighted decision matrix để có cơ sở rõ ràng, và cân nhắc hybrid trong hầu hết trường hợp. Trong nhiều tình huống, hybrid (SaaS cho phần phổ thông + Build cho phần đặc thù + Middleware tích hợp) là lựa chọn cân bằng tốt nhất giữa tốc độ, chi phí và khả năng tùy biến.

Đang cân nhắc một use case cụ thể? Yêu cầu tư vấn miễn phí — chúng tôi sẽ giúp chấm decision matrix cho use case của bạn và đề xuất approach phù hợp (SaaS, Build, hoặc Hybrid).

Bài viết liên quan: