SaaS đang chết hay tiến hóa trong kỷ nguyên AI 2026?

SaaS đang chết hay đang tiến hóa? Góc nhìn từ “cơn địa chấn” AI (2026)

TL;DR

• SaaS không biến mất, nhưng mô hình all‑in‑one nặng nề sẽ bị đào thải mạnh trong 1–2 năm tới.
• Rào cản thật sự không phải code, mà là làm cho khách hàng phụ thuộc và gắn chặt vào hệ thống.
• Doanh nghiệp chỉ dùng 10–20% tính năng SaaS, nên SaaS dạng lắp ghép (composable) đang nổi lên.
• Phần giao diện sẽ gần như miễn phí, nhưng API hạ tầng (thanh toán, email, dữ liệu) sẽ càng quyền lực.
• Cơ hội mới: bán thiết kế cấu trúc + lắp ghép hệ thống theo ngành, hơn là cố xây thêm một nền tảng all‑in‑one.

---

Lời tuyên bố “SaaS đã chết” là gì và vì sao đáng nghe?

Tuyên bố “SaaS đã chết” là lời cảnh báo về sự lỗi thời của mô hình SaaS all‑in‑one trong kỷ nguyên AI. Người đưa ra quan điểm này là Alex Becker — một doanh nhân nối tiếp đang vận hành nhiều công ty SaaS với doanh thu hàng tháng ở mức hàng tỷ đồng.

Ông không phủ nhận SaaS sẽ tồn tại. Điều ông nhấn mạnh là: nếu giữ nguyên cấu trúc hiện tại, rất nhiều công ty sẽ biến mất. Nhưng với những ai sẵn sàng đổi góc nhìn, đây lại là giai đoạn dễ “leo sóng” nhất trong thị trường phần mềm.

Khi quan sát thị trường SaaS từ CRM, marketing automation đến các hệ thống nội bộ, cả quốc tế lẫn Việt Nam, lập luận của Becker rất ăn khớp với những gì đang diễn ra: doanh nghiệp bắt đầu hoài nghi việc “thuê cả nhà máy” chỉ để dùng vài cái máy. Bài viết này bóc tách các luận điểm của ông theo từng lớp — rào cản thật sự của SaaS nằm ở đâu, vì sao all‑in‑one trở thành gánh nặng, và cơ hội mới cho người làm sản phẩm, developer, agency là gì.

“SaaS không chết, mà đang chuyển từ bán sản phẩm cố định sang bán dịch vụ thiết kế cấu trúc cho từng doanh nghiệp.”

---

Sụp đổ rào cản code: vì sao không phải gốc rễ khủng hoảng SaaS?

Sụp đổ rào cản code là hiện tượng AI làm cho việc lập trình trở nên rẻ, nhanh và dễ tiếp cận hơn bao giờ hết. Chỉ với vài dòng mô tả trong khung chat, AI có thể sinh ra nguyên một ứng dụng mẫu — từ giao diện đến logic xử lý cơ bản.

Nhiều người vì thế kết luận: “Code đã dễ thì ai cũng làm được SaaS, nên SaaS chết là đúng.” Becker phản bác thẳng lập luận đó. Ngay cả trước thời AI, bất cứ ý tưởng nào có khả năng mang về vài trăm triệu đến vài tỷ mỗi tháng đều lập tức thu hút vốn và đội ngũ kỹ sư. Khả năng code chưa bao giờ là rào cản quyết định.

Khi làm việc với các startup phần mềm trong nước, pattern này lặp đi lặp lại: ý tưởng nào chạm đúng nỗi đau doanh nghiệp thì luôn tìm được team build, kể cả phải thuê ngoài trọn gói. Vậy rào cản thật sự là gì?

“Rào cản cốt lõi của SaaS không phải là viết được code, mà là làm sao để khách hàng tiếp tục sử dụng và phụ thuộc vào hệ thống.”

AI khiến việc viết tính năng rẻ hơn và nhanh hơn. Nhưng đó chỉ là điều kiện nền, không phải nguyên nhân trực tiếp làm SaaS “khủng hoảng”. Vấn đề nằm sâu hơn ở mô hình sản phẩm và mức độ gắn dính của khách hàng.

---

Khách hàng phụ thuộc mới là “pháo đài” thật sự của một SaaS

Khách hàng phụ thuộc (customer dependency) là mức độ doanh nghiệp buộc phải bám vào một phần mềm để vận hành bình thường. Đây mới là nguồn sống thật sự của SaaS.

Becker dùng chính sản phẩm của mình — công cụ tracking quảng cáo Hyros — làm ví dụ. Khi mới ra mắt, Hyros có giá trị rõ ràng: theo dõi hiệu quả quảng cáo chi tiết hơn, giúp tối ưu ngân sách. Nhưng người dùng không tự động “dính” vào hệ thống.

Trong nhiều tháng, ông phải kèm khách rất sát: xem họ vướng ở đâu, không hiểu bước nào, không nhìn thấy kết quả ở điểm nào. Phải mất gần nửa năm tinh chỉnh, onboard từng khách hàng, đơn giản hóa workflow, làm rõ báo cáo — Hyros mới trở thành thứ mà khách không thể dễ dàng bỏ.

Khi quan sát các doanh nghiệp dùng CRM nội bộ, mô hình này lặp lại. Sản phẩm thắng thế không phải sản phẩm “nhiều tính năng nhất” — mà là sản phẩm khiến:

• Dữ liệu khách hàng được nhập đầy đủ theo thời gian.
• Quy trình bán hàng, chăm sóc, nhắc việc bám chặt vào hệ thống.
• Toàn bộ team được đào tạo và quen với cách làm việc mới.

Càng nhiều dữ liệu và quy trình bám vào, chi phí rời bỏ (switching cost) càng cao. Đó là “hào lũy” (moat) của SaaS, chứ không phải vài dòng code khó.

“Kinh doanh SaaS không phải cuộc chơi làm sản phẩm hay, mà là cuộc chơi khiến khách hàng phải lệ thuộc vào sản phẩm đó.”

AI có thể viết thêm tính năng, nhưng không tự động tạo ra mức độ phụ thuộc. Đây là điểm nhiều người hiểu lầm khi nói “AI giết SaaS”.

---

Nghịch lý all‑in‑one: khi sức mạnh trở thành gánh nặng

All‑in‑one platform là mô hình nền tảng gom càng nhiều tính năng càng tốt cho càng nhiều loại doanh nghiệp càng tốt — vừa CRM, vừa email marketing, vừa landing page, vừa đặt lịch, vừa mọi thứ.

Becker cho rằng cơn chấn động hiện tại của SaaS đến từ chính mô hình này. Để phục vụ hàng ngàn, hàng chục ngàn doanh nghiệp với ngành nghề, quy mô, quy trình khác nhau, nền tảng buộc phải:

• Liên tục thêm tính năng mới.
• Cho phép vô số cấu hình, quyền, vai trò.
• Hỗ trợ rất nhiều dạng workflow khác nhau.

Kết quả là hệ thống ngày càng nặng nề, phức tạp, khó học, khó triển khai.

Thực tế, nhiều doanh nghiệp Việt dùng các nền tảng lớn — từ CRM quốc tế đến nền tảng bán hàng và marketing nội địa — và chỉ khai thác 10–20% tính năng. Phần còn lại là:

• Các menu không ai đụng tới.
• Báo cáo ít ai xem.
• Tùy chọn cấu hình phức tạp tới mức không ai dám đổi.

Tuy vậy, doanh nghiệp vẫn phải gánh:

• 100% chi phí license theo đầu người hoặc theo gói.
• Thời gian đào tạo cho nhân sự mới.
• Chi phí vận hành, bảo trì, làm việc với support.

Doanh nghiệp đang mua cả “nhà máy phần mềm” nhưng thực tế chỉ dùng “vài chiếc máy”, trong khi vẫn gánh toàn bộ chi phí hạ tầng.

Trước đây, điều này gần như không thể tránh. Muốn quản lý khách hàng, gửi email, tạo landing page, đặt lịch trong một hệ thống ổn định, doanh nghiệp buộc phải chọn một nền tảng lớn.

Nhưng từ khi AI và các công cụ low‑code/no‑code phổ biến, câu hỏi mới bắt đầu xuất hiện:

• “Tại sao không chỉ xây đúng cái mình cần?”
• “Tại sao phải mua cả bộ, trong khi mình chỉ dùng vài mảnh?”

Chính câu hỏi này đang đe dọa trực tiếp mô hình all‑in‑one.

---

Composable SaaS: kỷ nguyên “lắp ghép phần mềm theo ý mình”

Composable SaaS là cách tiếp cận xây hệ thống bằng cách lắp ghép các khối chức năng nhỏ, tách rời, chỉ đúng những gì doanh nghiệp cần. Thay vì “mua một tòa nhà”, doanh nghiệp “chọn từng phòng” và lắp chúng lại bằng API và workflow.

Becker cho rằng đây là hình hài tương lai của SaaS: không mất đi, mà đổi trạng thái — từ nền tảng khổng lồ sang các “cụm chức năng may đo” cho từng công ty.

Trong thực hành, điều này trông như sau:

• Dùng một mẫu CRM mã nguồn mở làm lõi.
• Kết nối một công cụ đặt lịch riêng, tối ưu cho ngành đó.
• Dùng một dịch vụ email chuyên dụng để gửi số lượng lớn.
• Dùng một cổng thanh toán bên ngoài — ở Việt Nam là Momo, ZaloPay, VNPay — để xử lý giao dịch.
• Ghép tất cả lại qua API, và dùng AI để “code hộ” các phần nối.

Kết quả thử nghiệm với một doanh nghiệp dịch vụ nhỏ cho thấy cách lắp ghép này hoàn toàn khả thi: kết hợp Google Sheets, công cụ gửi Zalo/ZNS, cổng thanh toán nội địa và một form đặt lịch tùy chỉnh. Chi phí phần mềm hàng tháng thấp hơn đáng kể so với một nền tảng all‑in‑one, trong khi độ phù hợp với quy trình thực tế cao hơn rõ rệt.

Điểm mấu chốt: doanh nghiệp không cần nhiều tính năng, mà cần tổ hợp đúng tính năng phù hợp quy trình của riêng mình.

Khi AI kéo giá thành viết code và kết nối hệ thống xuống thấp, rào cản để “may đo” phần mềm cũng giảm theo. Mô hình all‑in‑one mất dần lợi thế “chỉ có tôi mới làm được đủ thứ” — vì giờ ai cũng có thể ghép được từ các mảnh nhỏ.

Một số tài liệu tham khảo hữu ích về xu hướng này:

• Khái niệm composable trong kiến trúc doanh nghiệp: https://www.gartner.com/en/information-technology/glossary/composable-enterprise
• Thảo luận về composable architecture trong SaaS: https://martinfowler.com/articles/micro-frontends.html

---

Lớp hạ tầng (infrastructure layer): nơi API càng ngày càng quyền lực

Lớp hạ tầng (infrastructure layer) là tầng cung cấp các năng lực lõi như thanh toán, email, SMS, lưu trữ dữ liệu, máy chủ, bảo mật. Đây là những phần “chân công trình” mà bề mặt UI có thể thay đổi, nhưng phần lõi vẫn cực kỳ khó thay thế.

Becker nhấn mạnh một điểm thú vị: phần giao diện và logic nhẹ có thể trở nên gần như miễn phí, nhưng hạ tầng phía sau sẽ càng tập trung vào tay một số ít nhà cung cấp mạnh.

Thanh toán trực tuyến là ví dụ điển hình. Doanh nghiệp nhỏ hoàn toàn có thể dựng form đặt hàng riêng bằng code hoặc no‑code, nhưng:

• Tự vận hành xử lý thẻ, ví, chuyển khoản là cực kỳ phức tạp.
• Đòi hỏi tiêu chuẩn bảo mật, tuân thủ quy định, quản lý rủi ro.
• Chịu áp lực vận hành 24/7, xử lý cao điểm.

Tương tự với email và SMS:

• Tạo một màn hình “viết email” thì rất dễ.
• Nhưng gửi ổn định hàng trăm ngàn email, vượt qua spam filter của Gmail hay Outlook, lại là câu chuyện hoàn toàn khác.

Càng nhiều hệ thống lắp ghép xuất hiện, nhu cầu về các API hạ tầng ổn định, tin cậy càng tăng. Người ta ghép mảnh nhỏ ở trên, nhưng tất cả đều dựa vào vài “trạm điện” lớn phía dưới.

Xu hướng này khớp với những gì các nền tảng lớn đang làm từ nhiều năm nay:

• Dịch vụ thanh toán như Stripe, PayPal (quốc tế) hoặc Momo, VNPay (Việt Nam).
• Dịch vụ email transactional như SendGrid, Amazon SES.
• Hạ tầng cloud như AWS, Google Cloud, Azure.

Một số tài liệu chính thức có thể tham khảo:

• Hạ tầng cloud và kiến trúc hiện đại: https://aws.amazon.com/architecture/
• Hệ thống email gửi số lượng lớn: https://docs.sendgrid.com/

Trong bối cảnh phần mềm lắp ghép, hai nhóm công ty hạ tầng sẽ càng mạnh:

• Nhóm xử lý dữ liệu phức tạp, yêu cầu độ chính xác cao.
• Nhóm cung cấp API nền tảng — thanh toán, email, nhắn tin, lưu trữ, phân quyền.

---

Mô hình mới: thiết kế framework + lắp ghép theo doanh nghiệp

Mô hình “thiết kế framework rồi lắp ghép theo doanh nghiệp” là hướng đi mà Becker cho là thực tế và có tiềm năng trong kỷ nguyên composable SaaS. Thay vì cố xây một SaaS all‑in‑one mới, ông khuyên nên:

1. Thiết kế một framework — bộ khung logic và cấu trúc chuẩn cho một loại doanh nghiệp hay quy trình cụ thể.
2. Dùng các công cụ sẵn có (CRM, booking, email, SMS, thanh toán…) để lắp thành hệ thống.
3. Tùy chỉnh bằng AI/code theo yêu cầu cụ thể rồi bàn giao.

Ở Việt Nam, mô hình này phù hợp với nhiều nhóm:

• Agency marketing triển khai hệ thống lead, chăm sóc, automation cho khách.
• Tư vấn vận hành muốn gắn tư vấn quy trình với phần mềm.
• Các team product nhỏ muốn chuyên sâu vào một ngành dọc — clinic, giáo dục, bất động sản.

Khi tư vấn cho doanh nghiệp vừa và nhỏ, điểm thuyết phục mạnh nhất của mô hình này không phải là “rẻ hơn SaaS all‑in‑one”. Điều khách hàng thật sự cần là:

“Hệ thống được thiết kế đúng theo quy trình thực tế của công ty đó, không bắt họ phải uốn quy trình để khớp với sản phẩm.”

Về doanh thu, mô hình này thường gồm:

• Phí thiết kế và triển khai ban đầu (project fee).
• Phí duy trì hệ thống hàng tháng (subscription) cho bảo trì, cập nhật, điều chỉnh.

Rào cản không nằm ở kỹ thuật — AI và các công cụ no‑code đã hỗ trợ rất nhiều. Rào cản nằm ở:

• Hiểu sâu ngành (domain knowledge).
• Kỹ năng hỏi và phân tích vấn đề của doanh nghiệp.
• Khả năng thiết kế cấu trúc và ưu tiên tính năng.

Nói cách khác, giá trị dịch vụ nằm ở “biết cần làm cái gì”, chứ không phải “code giỏi tới đâu”.

---

Đứng ở đâu trong làn sóng này? Gợi ý chiến lược thực tế

Chiến lược thích ứng với sự chuyển dịch SaaS là tập hợp những lựa chọn mà founder, developer, agency, và cả người mua phần mềm cần cân nhắc nghiêm túc trong 1–2 năm tới.

Ở phía cung — người làm SaaS, agency, lập trình viên:

• Nếu đang vận hành sản phẩm all‑in‑one, hãy soi lại tỷ lệ tính năng được sử dụng thật sự và khả năng tách nhỏ, lắp ghép lại.
• Nếu đang định khởi nghiệp SaaS, nên cân nhắc một ngành dọc cụ thể thay vì cố “ôm cả bầu trời tính năng”.
• Xây năng lực vibe coding — dùng AI để hiện thực hóa cấu trúc đã thiết kế, thay vì cắm đầu code tay từng chi tiết.

Ở phía cầu — doanh nghiệp dùng phần mềm:

• Đặt câu hỏi thẳng: “Chúng ta đang trả tiền cho bao nhiêu phần không dùng đến trong hệ thống hiện tại?”
• Xem xét các phương án lắp ghép với chi phí tương đương hoặc thấp hơn, nhưng khớp quy trình hơn.
• Hợp tác với những bên hiểu ngành và dám tùy biến theo quy trình cụ thể thay vì ép doanh nghiệp dùng khuôn sẵn.

Những doanh nghiệp thử nghiệm sớm mô hình “lắp ghép + tư vấn quy trình” thường nhận được ba lợi ích rõ ràng: tối ưu được các khâu tắc nghẽn trong conversion, giảm sự chống đối của nhân sự khi chuyển hệ thống vì mọi thứ gần với cách họ đang làm, và hiểu rõ hơn dòng chảy dữ liệu nội bộ từ marketing, bán hàng đến chăm sóc khách hàng.

Về bản chất, đây không chỉ là câu chuyện chọn phần mềm nào, mà là câu chuyện thiết kế lại cấu trúc vận hành dựa trên dữ liệu và tự động hóa.

---

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

Q: Vậy SaaS có thật sự “chết” trong vài năm tới không?

A: Không. Theo góc nhìn của Alex Becker, SaaS không biến mất — mà chuyển từ mô hình all‑in‑one sang mô hình lắp ghép theo cấu trúc. Những sản phẩm nặng nề, cố gắng phục vụ mọi loại doanh nghiệp giống nhau sẽ dễ bị tụt lại. Các giải pháp tinh gọn, đúng ngành và đúng quy trình sẽ có lợi thế hơn.

Q: AI viết code giỏi hơn thì có nghĩa là ai cũng làm được SaaS?

A: AI giúp giảm mạnh chi phí và thời gian lập trình, nhưng không thay thế được hiểu biết về vấn đề của doanh nghiệp. Rào cản thật sự nằm ở chỗ thiết kế cấu trúc hệ thống phù hợp, làm khách hàng phụ thuộc và gắn quy trình nội bộ vào đó. Điều này vẫn cần con người hiểu ngành và biết cách triển khai.

Q: Composable SaaS khác gì so với việc dùng nhiều phần mềm rời rạc?

A: Dùng nhiều phần mềm rời rạc thường dẫn tới dữ liệu rời rạc, workflow đứt đoạn. Composable SaaS là cách thiết kế có chủ đích: chọn các mảnh nhỏ — CRM, booking, email, thanh toán — rồi kết nối chúng lại bằng API và quy trình thống nhất. Trọng tâm không phải là số lượng công cụ, mà là cấu trúc kết nối.

Q: Cơ hội lớn nhất cho founder/developer trong bối cảnh này là gì?

A: Cơ hội lớn nhất là bán năng lực thiết kế framework và lắp ghép hệ thống theo ngành, thay vì cố xây một nền tảng khổng lồ. Người nào hiểu sâu một ngành dọc, biết đặt câu hỏi đúng, và dùng AI để nhanh chóng hiện thực hóa cấu trúc đó sẽ có lợi thế lớn. Doanh nghiệp sẵn sàng trả tiền cho “hệ thống đúng với mình”, không chỉ cho “một phần mềm nhiều tính năng”.

Q: Các công ty hạ tầng API có bị ảnh hưởng bởi xu hướng này không?

A: Ngược lại, họ thường được hưởng lợi. Càng nhiều hệ thống lắp ghép, nhu cầu với API thanh toán, email, SMS, lưu trữ dữ liệu, bảo mật càng tăng. Theo Becker, phần “giao diện” có thể trở nên gần như miễn phí, nhưng các nhà cung cấp API hạ tầng ổn định, tuân thủ và mở rộng tốt sẽ càng đóng vai trò trung tâm.

---

Kết luận: SaaS không chết, mà đang “lột xác” sang mô hình cấu trúc

Trong 1–2 năm tới, thị trường phần mềm nhiều khả năng sẽ dịch chuyển từ bán sản phẩm đóng gói sang bán dịch vụ thiết kế cấu trúc và lắp ghép hệ thống. Rào cản code đã bị AI bào mòn, nên lợi thế không còn nằm ở “viết được gì” — mà nằm ở “thiết kế đúng cái gì cho ai”.

Những ai đang vận hành hoặc chuẩn bị xây SaaS mà vẫn bám chặt mô hình all‑in‑one, cố chiều mọi loại khách hàng bằng một bộ tính năng khổng lồ, sẽ đối mặt với rủi ro cao. Ngược lại, những người dám chọn một ngành dọc cụ thể, hiểu sâu vấn đề và chủ động đóng vai kiến trúc sư hệ thống sẽ có cơ hội chiếm vị trí mạnh trong làn sóng mới.

SaaS không chết — nó đang tiến hóa. Câu hỏi không phải là “có tin vào SaaS nữa hay không”, mà là: đặt mình ở đúng tầng nào trong kiến trúc mới — sản phẩm đóng gói, dịch vụ lắp ghép, hay hạ tầng API — và xây lợi thế cạnh tranh ra sao. Người trả lời được câu hỏi này sớm sẽ là người định hình thế hệ doanh nghiệp phần mềm kế tiếp.