- Trước đây tôi từng hoài nghi về lập luận rằng SaaS sẽ bị LLM thay thế, nhưng tôi muốn chia sẻ trải nghiệm đã tự dùng mã của mình để thay thế dịch vụ hiển thị lời chứng thực từ LinkedIn/X giá 120 USD/năm chỉ trong 20 phút
- Đối tượng được thay thế là một dịch vụ có hệ thống thanh toán bị hỏng từ năm 2023 nhưng vẫn bị bỏ mặc, còn bộ phận hỗ trợ khách hàng thì chỉ gửi lại một liên kết bị lỗi
- Tận dụng Codex, tôi chuyển sang cách làm theo mô-đun: tách các lời chứng thực thành tệp JSON và tạo HTML ở thời điểm build, trong khi kết quả hiển thị cuối cùng giống hệt trước đây
- Với lập trình viên đây là một công việc nhanh và thú vị, nhưng với người không phải lập trình viên, việc kiểm chứng đầu ra mã do LLM tạo ra có thể là rào cản gia nhập
- Những micro SaaS mang tính tĩnh không cung cấp giá trị liên tục có nguy cơ là nhóm bị thay thế đầu tiên trong kỷ nguyên LLM
Sự hoài nghi trước đây về luận điểm LLM thay thế SaaS
- Cốt lõi của lý thuyết cho rằng SaaS sẽ bị LLM thay thế là: SaaS là sản phẩm phần mềm thuần túy, còn LLM làm giảm mạnh chi phí và thời gian xây dựng phần mềm tùy chỉnh, vì vậy phần lớn nhà cung cấp SaaS sẽ biến mất
- Lập luận phản biện là phần mềm nhân sự như Workday không chỉ là phần mềm đơn thuần, mà còn là dịch vụ bảo đảm tuân thủ quy định ở từng quốc gia (trợ cấp nghỉ phép, phiếu lương, v.v.) và được cập nhật liên tục theo thay đổi của môi trường bên ngoài lẫn nội bộ
Trải nghiệm dùng Shoutout.io và lý do rời bỏ
- Tôi đã dùng Shoutout.io trong 4 năm với mức 120 USD/năm để hiển thị mục lời chứng thực dựa trên các bài đăng LinkedIn và X trên pragmaticengineer.com
- Tôi chỉ đăng nhập khoảng một lần mỗi năm, và lần đăng nhập gần nhất là để kiểm tra hóa đơn hằng năm phục vụ quyết toán chi phí
- Mục thanh toán đã bị hỏng từ năm 2023 và bị bỏ mặc như vậy; tôi gửi email cho đội hỗ trợ nhưng chỉ nhận lại một liên kết lỗi
- Việc thậm chí không thể kiểm tra phí của năm tiếp theo là lý do trực tiếp khiến tôi rời bỏ dịch vụ SaaS này
Công việc thay thế trong 20 phút với Codex
- Cách tiếp cận là không xây lại toàn bộ SaaS cũ, mà chỉ tái dựng ca sử dụng cụ thể của riêng tôi: hiển thị lời chứng thực, thêm lời chứng thực mới và giữ nguyên thiết kế
- Tôi yêu cầu Codex lập kế hoạch loại bỏ phụ thuộc bên thứ ba và host ngay trong repository GitHub
- Tôi điều chỉnh sang mô hình mô-đun: quản lý lời chứng thực bằng tệp JSON riêng và tạo HTML ở bước build thời điểm biên dịch
- Tổng cộng mất 20 phút để thêm bước build cục bộ, thiết lập Netlify build trigger, kiểm thử, chỉnh UX, tạo schema và triển khai
- Kết quả cuối cùng nhìn giống hệt trước đây nhưng loại bỏ hoàn toàn phụ thuộc bên thứ ba
- Đến lúc đội hỗ trợ khách hàng gửi lại liên kết đúng (sau 2 giờ) thì tôi đã hoàn tất migration
Hàm ý đối với kỹ sư phần mềm
- Khi cập nhật sau này, lập trình viên sẽ quen với việc dùng dòng lệnh và AI agent để chèn lời chứng thực vào codebase và kiểm chứng kết quả, nhưng với người không phải lập trình viên thì việc xác minh đầu ra mã của LLM là một rào cản gia nhập
- Tốc độ mà lập trình viên tự “port” một SaaS sang code riêng nhanh hơn nhiều so với người không phải lập trình viên
- Ở lần thử đầu tiên, Codex đã triển khai sai bằng mô hình flexbox, và tôi phải tự quyết định framework bố cục UI
- Người không phải lập trình viên cũng có thể xử lý được, nhưng có lẽ sẽ mất nhiều thời gian hơn
- Việc tự viết lại chức năng của bên thứ ba là một trải nghiệm thú vị và giàu tính học hỏi, đồng thời là cơ hội để cảm nhận năng lực thực tế của công cụ
Hàm ý đối với doanh nghiệp SaaS
- Việc xây lại toàn bộ một SaaS và chỉ xây lại một ca sử dụng cụ thể khác nhau rất lớn về độ khó
- Shoutout có nhiều hơn gấp 10 lần tính năng như thêm trích dẫn từ hơn 10 nền tảng, xác thực, thanh toán, v.v.
- Những SaaS tĩnh không cung cấp giá trị liên tục sau khi hiển thị lời chứng thực là nhóm dễ bị thay thế nhất
- Ngược lại, nếu có các chức năng hỗ trợ kinh doanh theo thời gian thực như tuân thủ, phân tích, cảnh báo thì việc thay thế sẽ khó hơn nhiều
- Khả năng lợi nhuận của mô hình kinh doanh mua bán SaaS có thể suy giảm
- Shoutout được một indie developer xây dựng năm 2020, bán cho một product studio năm 2022, rồi lại được bán tiếp cho một nhà phát triển khác vào năm 2025
- Từ góc nhìn người dùng, không có thay đổi nào ngoài việc hệ thống thanh toán bị hỏng
- Những bên mua lại có thể đã kỳ vọng tăng trưởng doanh thu mà không cần đầu tư, nhưng nếu sản phẩm bị bỏ mặc thì người dùng sẽ rời đi và thời điểm có thể dễ dàng thay thế bằng LLM sẽ đến
- Đây là thời đại mà việc bỏ mặc “Broken Windows” trở nên kém được chấp nhận hơn rất nhiều so với trước đây
3 bình luận
Chi phí bảo trì cũng là một khoản tốn kém mà
Việc triển khai phần mềm luôn phải được nhìn dưới góc độ "TCO" trong vòng "5 năm". Nếu không thì thực sự chỉ là chất thêm những 'quả bom' sẽ nổ về sau.
Đây là bài do người dùng viết à? Nếu tự xây xong thì về sau chức năng đó sẽ phải tiếp tục được quản lý để vận hành nội bộ thay vì thuê nhà cung cấp bên ngoài, vậy cái này là miễn phí, không tốn thời gian và tiền bạc sao??