Gần đây, cụm từ "SaaS đã chết" đang được nhắc đến rất nhiều. Lập luận đưa ra là vì chúng ta đang sống trong thời đại AI có thể viết mã, chúng ta nên ngừng trả phí SaaS hàng tháng và tự xây dựng những gì mình cần ngay tại công ty.
Tại công ty của tôi, Emooove, chúng tôi đã dành vài tháng qua để toàn tâm toàn ý xây dựng các hệ thống nội bộ. Vì đã thực sự làm điều đó, tôi đã trải qua cả những thành công lẫn những bài học chua cay. Hôm nay, tôi muốn chia sẻ góc nhìn của mình về câu chuyện "SaaS đã chết" dựa trên trải nghiệm thực tế đó.
Nói rõ là, tôi viết bài này từ góc nhìn của một người dùng/người xây dựng hệ thống, không phải nhà cung cấp SaaS.
Một kỷ nguyên tuyệt vời khi ai cũng có thể xây dựng hệ thống
Trước tiên, như một tiền đề, sự xuất hiện của Claude Code đã thực sự mang đến một kỷ nguyên mà "ai cũng có thể xây dựng hệ thống". Điều này không hề phóng đại.
Tại Emooove, một trưởng nhóm tuyển dụng mới chỉ làm việc với chúng tôi được hai tháng đã xây dựng một hệ thống ATS (Hệ thống quản lý ứng viên) nội bộ. Cô ấy không phải kỹ sư và không có chút kinh nghiệm kỹ thuật nào. Dù vậy, cô ấy đã tạo ra một hệ thống vận hành được, đảm nhận mọi thứ từ nhập ứng viên đến quản lý tuyển chọn và cả dashboard.
Hơn nữa, chúng tôi hiện đang phát triển một hệ thống nội bộ để nâng cao hiệu quả vận hành và chất lượng cho mảng kinh doanh cốt lõi — dịch vụ đại lý bán hàng. Cá nhân tôi dành toàn tâm cho việc này mỗi ngày, và chưa đầy hai tuần kể từ khi bắt đầu, tôi cảm thấy chúng tôi sắp tạo ra một thứ khá tốt.
Có thể hiểu được vì sao người ta muốn nói "SaaS đã chết" khi bạn có thể tự xây dựng nội bộ một thứ mà nếu dùng SaaS sẽ tốn hàng chục đến hàng trăm nghìn yên mỗi tháng.
Tuy nhiên, mọi chuyện không hề suôn sẻ
Đây là điểm chính. Khi chúng tôi thực sự thử làm, mọi thứ không hề màu hồng.
1. Việc bảo trì khó khăn khôn lường
Dù tốt hay xấu, bạn có thể xây dựng mọi thứ "làm đến đâu hay đến đó", nên chúng nhanh chóng thành hình. Tuy nhiên, vì các yêu cầu chưa được xác định đầy đủ, nên có rất nhiều điểm sạn.
Trong trường hợp hệ thống ATS của chúng tôi, chúng tôi gặp những vấn đề như:
- Các hồ sơ đáng lẽ phải được nhập vào thì lại không được nhập.
- Số liệu trên dashboard bị lỗi một cách khó hiểu.
- Các nút quan trọng bị thiếu, khiến hoạt động bị ngừng trệ.
Chúng tôi gặp rất nhiều "thiếu sót mà chỉ đến khi bắt đầu sử dụng mới nhận ra". Với hệ thống hỗ trợ bán hàng nội bộ, thậm chí có một buổi sáng chúng tôi đột nhiên không truy cập được, màn hình không mở lên.
Tất nhiên, những điều này có thể được khắc phục ở một mức độ nào đó bằng cách xác định yêu cầu kỹ lưỡng hơn hoặc vừa làm vừa cải tiến. Tuy nhiên, trong thời gian đó, hoạt động kinh doanh bình thường sẽ bị gián đoạn. Nếu bạn bắt đầu xây dựng với kỳ vọng rằng nó sẽ "dễ dàng và nhanh chóng", bạn sẽ rơi vào tình thế khó khăn. Tôi nhận ra rằng bạn không nên bắt đầu với tư duy "xây là xong", mà phải là "xây rồi liên tục sửa chữa".
Vì quy mô tuyển dụng của chúng tôi nhỏ nên chúng tôi vẫn xoay xở được kể cả khi ATS ngừng hoạt động một thời gian. Nhưng tôi rùng mình khi nghĩ nếu đây là một hệ thống có nhiều bên liên quan. Khi số lượng người dùng và phạm vi ảnh hưởng tăng lên, thiệt hại từ một lần sự cố cũng lớn hơn, và mức độ khó tăng vọt.
Dù bạn có thể chấp nhận điều này với hệ thống nội bộ, bạn nên cực kỳ thận trọng khi xây dựng bất cứ thứ gì để bán ra ngoài hoặc hướng ra thế giới bên ngoài, như biểu mẫu liên hệ chẳng hạn.
2. UI/UX không bao giờ được trau chuốt
Tôi nhận ra điều này khi tự mình xây dựng hệ thống: chất lượng hoàn thiện chỉ ở mức trung bình.
Các màn hình mà AI tạo ra ban đầu trông có vẻ "ổn", nhưng khi thực sự sử dụng, các chi tiết lại không mượt mà. Dù cuối cùng bạn vẫn có thể làm cho nó trông đẹp bằng cách đưa ra yêu cầu lặp đi lặp lại, điều đó đòi hỏi sự cầu toàn ám ảnh và thời gian. Hầu hết mọi người sẽ có xu hướng chấp nhận dở chừng.
Giao diện của SaaS được trau chuốt vì các nhà thiết kế chuyên nghiệp đã dành nhiều năm để phản ánh phản hồi của người dùng; đó không phải thứ bạn có được miễn phí.
3. Vấn đề bảo mật
Đây là phần đáng sợ nhất.
Ngay cả người không phải kỹ sư cũng có thể dùng Claude Code để xây dựng chức năng và UI/UX với thái độ "làm đại cho xong". Nhưng liệu có thể xử lý bảo mật theo cách tương tự không? Ít nhất với tôi, là không. Xác thực, quản lý phân quyền, xử lý lỗ hổng — "chạy được" và "an toàn" là hai chuyện hoàn toàn khác nhau.
Trong trường hợp của chúng tôi, may mắn là có một người từng làm kỹ sư bảo mật, nên chúng tôi đảm bảo để người đó phụ trách phần này. Dù vậy, vẫn còn một chút lo lắng. Chỉ nghĩ đến việc một tổ chức không có chuyên gia đưa thông tin khách hàng lên một hệ thống được xây dựng một cách tùy hứng rồi công khai nó, tôi đã toát mồ hôi lạnh.
Lối tư duy nhị phân "sống hay chết" là sai lầm
Tôi đã liệt kê những điểm tiêu cực của việc phát triển nội bộ, nhưng thành thật mà nói, cũng có rất nhiều điều tốt:
- Bạn có thể xây dựng thứ phù hợp hoàn hảo với doanh nghiệp của mình.
- Nếu muốn sửa gì đó, bạn có thể làm ngay hôm sau.
- Gần như không có chi phí hàng tháng.
- Công ty tích lũy được bí quyết (know-how) và sự tự tin rằng "chúng ta có thể tự xây dựng hệ thống".
Vấn đề là cố gắng đơn giản hóa thành câu hỏi "SaaS sẽ sống hay chết?". Việc áp dụng SaaS hay tự xây dựng nội bộ phụ thuộc vào tình hình của từng công ty. Dựa trên kinh nghiệm của tôi, đây là năm điểm cần cân nhắc:
Điểm 1: Bạn có kỹ sư nội bộ không?
Nếu không, bạn sẽ thất bại ở những lĩnh vực như bảo mật mà người không phải kỹ sư không thể xử lý một cách tùy hứng. Điều đáng sợ nhất là có thể xây dựng các chức năng mà không hề nhận ra những nguy hiểm. Bước ngoặt nằm ở việc liệu bạn có tìm được một người giàu kinh nghiệm để rà soát các phần quan trọng hay không.
Điểm 2: Số lượng các bên liên quan
Nếu có quá nhiều bên liên quan, thiệt hại khi xảy ra sự cố sẽ rất lớn, và mức độ khó tăng lên chóng mặt. Ngược lại, các tổ chức nhỏ có thể thử nghiệm dễ dàng hơn vì nếu hệ thống ngừng hoạt động thì chỉ cần xin lỗi là xong. Việc bắt đầu với những hoạt động có phạm vi ảnh hưởng nhỏ là điều thực tế.
Điểm 3: Hệ thống hướng ngoại so với hệ thống nội bộ
Với hệ thống nội bộ, rủi ro sẽ có giới hạn nếu có chuyện xảy ra. Tuy nhiên, với bất cứ thứ gì hướng ra ngoài, một vụ rò rỉ thông tin duy nhất cũng có thể gây hậu quả không thể đảo ngược. Trong khi SaaS cho phép bạn chuyển một phần trách nhiệm sang nhà cung cấp, thì với phát triển nội bộ, mọi thứ đều thuộc trách nhiệm của bạn. Giá trị của "sự yên tâm đã được kiểm chứng" từ SaaS càng lớn hơn với bất cứ thứ gì hướng ra bên ngoài.
Điểm 4: Bạn có thể bố trí nhân lực cho việc bảo trì không?
Việc bảo trì diễn ra nhiều hơn bạn tưởng tượng. Phát triển nội bộ không phải là "xây là xong" mà là "liên tục sửa chữa". Bạn có thể bắt đầu với sự nhìn xa trông rộng đó không? Nếu bắt đầu với thái độ nửa vời, bạn sẽ bị vùi đầu vào việc sửa lỗi và việc này sẽ gây áp lực lên hoạt động kinh doanh cốt lõi của bạn.
Điểm 5: Bạn có thích/muốn làm phát triển AI không?
Cuối cùng, mọi thứ đều quy về điểm này. Việc này tẻ nhạt và khó khăn hơn bạn nghĩ, và thật bực bội khi AI không nghe lời (cười). Liệu bạn có thể kiên trì đến cùng bất chấp điều đó không? Đây là một kỷ nguyên tuyệt vời cho những ai yêu thích nó, nhưng tôi không nghĩ đó là thứ có thể duy trì chỉ bằng ý thức trách nhiệm.
Tổng kết: SaaS không chết. Chỉ là có thêm nhiều lựa chọn hơn.
Tôi đã dùng từ "thất bại" trong tiêu đề, nhưng chính xác hơn thì đó là "suýt thất bại nhiều lần". Chúng tôi tiếp tục phát triển nội bộ vì chúng tôi có những kỹ sư giàu kinh nghiệm, tổ chức của chúng tôi vẫn còn nhỏ, hệ thống chủ yếu dùng nội bộ, chúng tôi sẵn sàng cam kết bảo trì, và trên hết, tôi muốn làm điều đó. Có thể nói chúng tôi đang làm vì chúng tôi đang ở trong một môi trường thuận lợi khi cả năm điểm đều được đáp ứng.
Ngược lại, nếu một công ty không đáp ứng được những điều kiện này hiểu theo nghĩa đen câu nói "SaaS đã chết" và cố gắng tự xây dựng các hoạt động cốt lõi nội bộ, thì công ty đó sẽ thực sự thất bại.
SaaS không chết. Chỉ là lựa chọn "tự xây dựng" giờ đây đã mở ra cho tất cả mọi người. Hãy bình tĩnh đánh giá tình hình công ty và sử dụng cả SaaS lẫn tự phát triển nội bộ. Đó chẳng phải là cách đúng đắn để đối mặt với kỷ nguyên vừa tiện lợi vừa đầy bất trắc này hay sao?
