Giới thiệu: Tại Sao Tôi Thử Nghiệm Này
Tôi không bắt đầu với mục tiêu xây dựng một SaaS hoàn thiện, sẵn sàng cho nhà đầu tư. Tôi chỉ đơn giản là muốn giải quyết một nhu cầu của bản thân.
AI có chi phí cao. Đặc biệt là đối với sinh viên. Tôi đã nhìn vào các chi phí đăng ký và tự hỏi: Tại sao quyền truy cập lại phải bị khóa sau những gói giá trên 20 đô la/tháng mà hầu hết sinh viên không thể biện minh cho? Đồng thời, tôi không muốn tái tạo bánh xe bằng cách xây dựng mọi thứ từ đầu — thanh toán, xác thực, bảng điều khiển, tất cả những mã ghép đó mất hàng tuần trước khi bạn có thể đến với sản phẩm thực sự.
Vì vậy, tôi đã tự hỏi: Tôi có thể đi được bao xa trong một cuối tuần chỉ bằng cách kết nối các công cụ có sẵn?
Spoiler: Rất xa. Thực sự là đủ xa để có một nền tảng AI có khả năng đăng ký hoạt động và sử dụng được.
Đây là câu chuyện về cách tôi kết hợp OpenWebUI, Supabase, LemonSqueezy và Cloudflare để xây dựng một SaaS nhỏ nhưng thực sự.
Công Nghệ: Các Thành Phần Tôi Mượn Thay Vì Xây Dựng
Thay vì viết dịch vụ tùy chỉnh cho mọi thứ, tôi đã dựa vào những công cụ đã giải quyết các phần nhàm chán.
-
OpenWebUI → Đây là giao diện, bộ não của hoạt động. Nó cung cấp cho tôi một frontend chat và tổ chức mà không cần tôi phải thiết kế từ đầu. Bên cạnh đó, tôi có thể cắm mô hình của riêng mình, nhúng sách giáo khoa cho việc dạy kèm, và nói chung là làm cho nó cảm giác như một trợ lý AI dành cho sinh viên mà không phải chạm vào từng dòng mã.
-
Supabase → Xác thực và cơ sở dữ liệu trong một gói gọn gàng. Ngay từ đầu, tôi đã có đăng nhập, đăng ký, đặt lại mật khẩu và một nơi để theo dõi người dùng. Không cần phải khởi động một cụm Postgres của riêng mình hay xử lý các token JWT một cách thủ công — Supabase đã xử lý điều đó.
-
LemonSqueezy (cộng với một webhook) → Xử lý thanh toán. Tôi không muốn chạm vào tuân thủ PCI, và Stripe có thể là quá mức nếu bạn chỉ đang thử nghiệm ý tưởng. LemonSqueezy cho phép tôi thiết lập các mức đăng ký — $5 cho sinh viên, $10 cho tiêu chuẩn, $20 cho chuyên nghiệp — và tôi đã nối webhook của họ vào quy trình của mình để các thanh toán thành công tự động đồng bộ với Supabase.
-
Cloudflare Worker → Là keo dán. Worker này lắng nghe các webhook từ LemonSqueezy, giao tiếp với Supabase và cập nhật quyền truy cập của người dùng. Nó thực sự là bộ dịch giữa phần tiền và phần xác thực. Thêm vào đó, Cloudflare Workers rẻ, toàn cầu và nhanh chóng. Tôi không phải lo lắng về việc lưu trữ một backend.
Đó là tất cả. Bốn thành phần chuyển động. Không có máy chủ tùy chỉnh cho logic kinh doanh. Không tái tạo màn hình đăng nhập. Chỉ là keo dán.
Kiến Trúc (Đơn Giản Nhưng Hiệu Quả)
Dưới đây là cách mà nó hoạt động:
- Người dùng truy cập vào trang web → Đăng ký qua Supabase Auth.
- Họ chọn một gói → Thanh toán qua LemonSqueezy xử lý việc thanh toán.
- Webhook kích hoạt → Cloudflare Worker nhận sự kiện, xác minh nó và cập nhật Supabase.
- Quyền truy cập được mở khóa → OpenWebUI kiểm tra Supabase để xem họ đang ở mức nào, sau đó cung cấp quyền truy cập phù hợp.
Tôi đã vẽ điều này bằng hộp và mũi tên, và thực sự trông nó quá đơn giản. Nhưng đơn giản là mục đích. Càng ít backend tùy chỉnh tôi viết, tôi càng có thể nhanh chóng phát hành.
Bài Học Rút Ra Trên Đường Đi
-
Mã ghép tốt hơn mã xanh.
Nếu tôi cố gắng tự mã hóa xác thực + thanh toán + các mức người dùng, tôi vẫn sẽ đang gỡ lỗi. Bằng cách kết nối các dịch vụ với nhau, tôi có thể tập trung vào sản phẩm thực — cung cấp quyền truy cập AI hợp lý. -
Quy mô khiến tôi ngạc nhiên.
Tôi đã thực hiện một bài kiểm tra tải: 10.000 người dùng giả lập, 10 tin nhắn mỗi người, kích hoạt mỗi 2 giây. Chiếc máy tính mini HP ProDesk đang chạy relay đạt khoảng 70% CPU, 56% RAM, và không bị sập. Điều này thật sự hiệu quả khi xem xét việc tải nặng được chuyển cho các điểm cuối Nebius. Điều đó có nghĩa là ngay cả phần cứng khiêm tốn cũng có thể chuyển tải nhiều lưu lượng nếu các điểm tắc nghẽn ở nơi khác. -
Các sự đánh đổi là có thật.
Mặt trái của các stack keo dán là sự phụ thuộc. Nếu LemonSqueezy thay đổi sơ đồ webhook của họ, tôi sẽ phải điều chỉnh worker của mình. Nếu Supabase gặp sự cố, việc đăng nhập sẽ bị ảnh hưởng. Nhưng cho một MVP? Hoàn toàn đáng giá. -
Thời gian của nhà phát triển là tiền tệ thực sự.
Chắc chắn, cuối cùng tôi có thể xây dựng hệ thống xác thực hoặc thanh toán của riêng mình. Nhưng thời gian tiết kiệm được khi thuê ngoài cho Supabase và LemonSqueezy có giá trị hơn nhiều so với chi phí máy chủ. -
Người dùng không quan tâm backend có đẹp không.
Chừng nào mà việc đăng ký, thanh toán và quyền truy cập hoạt động một cách trơn tru, không ai quan tâm liệu bạn có mã hóa nó bằng Go hay nối nó lại bằng băng keo và Workers.
Điều Gì Làm Nên Một "Nền Tảng Thực Sự?"
Câu hỏi này đã đến với tôi trong khi nghe một bài nói chuyện: điều gì thực sự làm nên một nền tảng? Hiện tại, hệ thống của tôi về mặt kỹ thuật chỉ là một loạt các phần gắn liền — một trang web, POS, xác thực, webhook và OpenWebUI được nối lại với nhau.
Nhưng nếu bạn xem xét kỹ, những gì tôi thực sự có là:
- Một điểm vào đáng tin cậy (xác thực)
- Một động cơ kiếm tiền (thanh toán)
- Một cơ chế phân phối (OpenWebUI + mô hình)
- Một vòng phản hồi (SEO + tăng trưởng tự nhiên)
Liệu điều đó có đủ để trở thành một nền tảng không? Tôi nghĩ là có. Nó không đẹp, nhưng nó khả dụng, có thể mở rộng và giải quyết một vấn đề: quyền truy cập AI hợp lý cho sinh viên.
Một nền tảng không cần phải hoàn hảo. Nó chỉ cần cung cấp giá trị và có thể mở rộng. Và nền tảng của tôi làm được cả hai điều đó.
Hướng Đi Tiếp Theo
MVP này chỉ là bước đầu tiên. Đây là những gì đang trên lộ trình:
- Gói miễn phí: Cung cấp cho sinh viên một cái nhìn trước khi họ quyết định.
- Nhiều mô hình hơn: Mở rộng ra ngoài các gia sư cốt lõi vào các công cụ sáng tạo, trợ lý viết luận và thậm chí là tạo hình ảnh.
- TTS + thông báo: Hiện tại, bạn thậm chí có thể hack hệ thống bằng cách chỉnh sửa tin nhắn AI và để TTS đọc to chúng. Bước tiếp theo là làm cho các tính năng như vậy trở nên có chủ đích.
- Phần cứng mở rộng tốt hơn: Cuối cùng, tôi sẽ thay thế các máy tính mini bằng một bộ X99 dual E5 với 128GB RAM và GPU cho các tải công việc hình ảnh. Điều này sẽ cho phép tôi chạy Stable Diffusion tại chỗ với giới hạn hàng ngày + thông báo danh sách chờ.
Trong dài hạn, tôi thích ý tưởng về các cụm chủ quyền (đúng vậy, thậm chí trên một chiếc thuyền một ngày nào đó). Nhưng hiện tại, mục tiêu rất đơn giản: giữ chi phí thấp, giữ quyền truy cập hợp lý và tiếp tục phát triển.
Kết Luận
Tôi không xây dựng điều này để gây ấn tượng với các nhà đầu tư. Tôi xây dựng nó vì sinh viên không nên phải trả giá cao cho SaaS để sử dụng AI. Và điều thú vị là? Tôi không cần một đội ngũ lớn hoặc hàng triệu đô la tài trợ để có thể vận hành. Tôi chỉ cần kết hợp những công cụ phù hợp.
Nếu bạn đang nghĩ đến việc xây dựng một cái gì đó — đừng chờ đợi cho đến khi bạn có kiến trúc “hoàn hảo”. Hãy sử dụng những gì đã có. Kết dính nó, thử nghiệm, phát hành. Người dùng thực sự không quan tâm đến sự tinh tế. Họ quan tâm đến việc liệu nó có hoạt động hay không và liệu nó có đáng để trả tiền không.
Và đối với tôi, câu trả lời cho đến nay là có.
Bạn thì sao? Bạn đã bao giờ xây dựng một sản phẩm chủ yếu từ mã ghép chưa? Bạn có tin tưởng một stack như thế này để mở rộng không? Tôi rất muốn nghe ý kiến của bạn.