Các chỉ số vận hành của ứng dụng mã nguồn mở Spliit: mức sử dụng, chi phí, quyên góp từ cộng đồng
(spliit.app)- Nhân dịp tròn 1 năm kể từ khi bản hiện tại được phát hành công khai, Spliit, một ứng dụng mã nguồn mở để chia chi phí, đã công bố tình hình sử dụng, chi phí và quyên góp trong 12 tháng qua nhằm minh bạch vận hành
- Số lượt truy cập đạt 152 nghìn, và lượt truy cập hằng tuần tăng từ khoảng 200 lên 5 nghìn~6 nghìn; tỷ lệ thoát 33% cho thấy người dùng không chỉ dừng ở màn hình chính mà còn thực hiện hành động thực tế
- Tính đến thời điểm bài viết được đăng, người dùng đã tạo gần 15 nghìn nhóm và 162 nghìn khoản chi; kể từ tháng 1/2024, mỗi tuần có khoảng 300 nhóm và 2.000 khoản chi mới được tạo
- Chi phí vận hành khoảng 115 USD mỗi tháng, phần lớn đến từ chi phí lưu trữ cơ sở dữ liệu; do người dùng đến từ khắp thế giới, mức sử dụng cơ sở dữ liệu là ràng buộc chính trong việc tối ưu chi phí
- Spliit vẫn duy trì miễn phí và doanh thu phụ thuộc vào GitHub Sponsors và quyên góp qua Stripe; số tiền quyên góp chưa hoàn toàn trang trải toàn bộ chi phí nhưng đã ở mức gần đủ
Quy mô sử dụng của Spliit
- Spliit được tạo ra từ vài năm trước, nhưng phiên bản hiện đang có thể sử dụng mới chỉ bước sang năm đầu tiên phát hành công khai
- Tình hình sử dụng, chi phí và quyên góp được công bố sau khi một người dùng GitHub đề xuất chia sẻ các thông tin này vì mục đích minh bạch
- Trong 12 tháng qua, Spliit ghi nhận 152 nghìn lượt truy cập
- Ban đầu chỉ ở mức khoảng 200 lượt truy cập mỗi tuần
- Hiện nay ổn định ở mức 5 nghìn~6 nghìn lượt truy cập mỗi tuần
- Tỷ lệ thoát là 33%
- Phần lớn khách truy cập không rời đi chỉ sau khi xem trang chủ
- Họ tiếp tục các hành động như chuyển sang nhóm, tạo khoản chi hoặc đọc bài blog
Liên kết chia sẻ và nguồn truy cập
- Trong số 152 nghìn lượt truy cập, ít nhất 29 nghìn người đã sử dụng liên kết chia sẻ
- Luồng sử dụng phổ biến là một người tạo nhóm rồi chia sẻ liên kết cho các thành viên tham gia
- Reddit cũng mang lại nhiều lượt truy cập
- Spliit được nhắc đến trong các bài viết tìm lựa chọn thay thế cho Splitwise
- Các quốc gia có nhiều khách truy cập nhất là Germany, United States, India
- Chưa rõ vì sao ứng dụng lại được dùng nhiều hơn ở các quốc gia này
Nhóm và khoản chi do người dùng tạo
- Hai hành động cốt lõi mà người dùng thực hiện thường xuyên nhất trên Spliit là tạo nhóm và thêm khoản chi
- Tính đến thời điểm bài viết được đăng, người dùng đã tạo gần 15 nghìn nhóm và tổng cộng 162 nghìn khoản chi
- Theo dữ liệu theo dõi từ tháng 1/2024, mỗi tuần có khoảng 300 nhóm và 2.000 khoản chi mới được tạo
- Xét phân bố số khoản chi trên mỗi nhóm, có ít nhất 4.600 nhóm không có khoản chi nào, có thể xem là được tạo ra để thử ứng dụng
- Trong khoảng 10 nghìn nhóm còn lại, một nửa có hơn 5 khoản chi
Chi phí vận hành hằng tháng
- Chi phí vận hành của Spliit vào khoảng 115 USD mỗi tháng
- Phần lớn chi phí phát sinh từ lưu trữ cơ sở dữ liệu
- Cơ sở dữ liệu được lưu trữ trên Vercel
- Giá được tính dựa trên tổng thời gian đọc cơ sở dữ liệu trong tháng
- Chi phí ghi gần như không đáng kể
- Vì Spliit được sử dụng trên toàn thế giới nên cơ sở dữ liệu gần như hoạt động suốt cả tháng
- Chi phí cơ sở dữ liệu là hạng mục mà dự án muốn cải thiện, và có thể tồn tại nhà cung cấp cơ sở dữ liệu rẻ hơn, phù hợp hơn với trường hợp sử dụng của Spliit
Nguyên tắc miễn phí và quyên góp
- Mô hình kinh doanh của Spliit là tiếp tục tồn tại như một dự án mã nguồn mở, và trong tương lai vẫn sẽ miễn phí sử dụng
- Sau này có thể xuất hiện các tính năng premium, nhưng không theo hướng hạn chế cách dùng ứng dụng thông thường
- Hiện tại, nguồn thu duy nhất của Spliit là quyên góp
- Trong tháng đầu tiên, đã có người quyên góp 70 USD, và sau đó cũng có những người dùng quyên góp 5 USD hoặc 20 USD
- Số tiền quyên góp hiện vẫn chưa thể chi trả toàn bộ chi phí của dự án, nhưng đã đạt mức khá gần
Lý do bổ sung tính năng quyên góp
- Quyên góp không phải là điều bắt buộc để duy trì hoạt động của Spliit
- Người vận hành có công việc toàn thời gian và thu nhập đủ để trang trải cuộc sống
- Họ hài lòng khi tự đóng góp một phần chi phí cho cộng đồng
- Có hai lý do để bổ sung tính năng quyên góp
- Nhiều người dùng yêu thích dự án và hỏi cách để đáp lại
- Người vận hành muốn rằng ngay cả khi một ngày nào đó họ rời khỏi dự án, cộng đồng vẫn có thể duy trì nó mà không gặp vấn đề tài chính
Thời gian bảo trì và đóng góp từ cộng đồng
- Thời gian người vận hành dành cho Spliit là khoảng 5~10 giờ mỗi tháng
- Phần lớn các tính năng mới được thêm vào ứng dụng trong vài tháng gần đây không phải do người vận hành làm, mà đến từ các cộng tác viên trong cộng đồng
- Thời gian của người vận hành chủ yếu dành cho quản lý dự án
- Quản lý các đề xuất tính năng, báo cáo lỗi và câu hỏi trong issues
- Review và kiểm thử pull requests
- Triển khai tính năng mới để mọi người dùng đều có thể truy cập
- Có rất nhiều thời gian được đầu tư cho Spliit, nhưng phần đáng kể trong đó do các cộng tác viên khác đảm nhiệm
Cập nhật minh bạch trong tương lai
- Spliit hiện đang trang trải phần lớn chi phí lưu trữ nhờ tiền quyên góp, còn phần thiếu sẽ do người vận hành tự chi trả mỗi tháng
- Trong thời gian tới, dự án dự định tiếp tục duy trì các bản cập nhật minh bạch để chia sẻ định kỳ về tiến độ dự án và tình hình tài chính
- Có thể gửi câu hỏi tiếp theo tại hai nơi
1 bình luận
Ý kiến trên Hacker News
Tôi luôn tò mò mọi người dùng cơ sở dữ liệu nào cho kiểu mục đích này. Tôi khá thích SQLite, nhưng với ứng dụng thì tôi thường thích hướng tách rời và gần như stateless hơn
Dữ liệu hầu như luôn là thứ quan trọng nhất, nên tôi muốn hạ tầng ứng dụng có thể mở rộng, thay thế, vứt bỏ tùy ý mà không phải lo
Tôi cũng từng nghĩ đến Postgres VPS, nhưng đang dùng neon.tech tốt hơn mong đợi. Đặc biệt là GUI và branching rất ổn
Khi tuổi nhiều hơn và thời gian ít đi, tốc độ và sự tiện lợi ngày càng quan trọng hơn bản tính tiết kiệm đã ăn sâu. Cơ sở dữ liệu SaaS giúp làm việc nhanh hơn, nhưng hóa đơn theo tháng và sự biến động vẫn khiến tôi không thích
Bạn có thể xóa ứng dụng và triển khai ở nơi khác, Litestream sẽ kéo dữ liệu về lại và tiếp tục như chưa có chuyện gì xảy ra
Ở phần đầu bài này, tôi demo việc gắn Litestream vào ứng dụng của mình, rồi xóa instance Heroku và triển khai lại một instance mới trên Fly.io. Litestream chuyển toàn bộ dữ liệu sang bản triển khai mới: https://mtlynch.io/litestream/
Tôi không rõ bạn sẽ gặp thứ gì vượt quá dung lượng của một VPS nhỏ
Một VPS riêng cho cơ sở dữ liệu là hợp lý, nhưng nếu request được cache hợp lý thì với các dịch vụ không trọng yếu vẫn chịu được, chỉ cần làm backup chắc hơn
Đặc biệt là giữ mọi thứ luôn cập nhật, lo bảo mật và cấu hình đúng. Thiết lập ban đầu thì dễ, nhưng phần sau đó mới là cốt lõi; không biết hiện nay thường xử lý thế nào
Tôi đã dùng thử ứng dụng và rất thích điểm không cần tạo tài khoản. Bạn nhận một liên kết riêng tư rồi chia sẻ với nhóm; người mở link sẽ chọn mình là ai để “đăng nhập”
Tất nhiên có thể đăng nhập thành thành viên khác để lạm dụng hệ thống, nhưng có vẻ nhà phát triển hiểu nhóm người dùng của mình và chọn đánh đổi để có trải nghiệm không ma sát. Rất gọn
Lấy nhiều cảm hứng từ đó, tôi đang làm một ứng dụng để câu lạc bộ sách có thể mở “cuộc bầu chọn” cho cuốn sách tiếp theo. Tôi muốn hỗ trợ nhiều cách bỏ phiếu như xếp hạng lựa chọn, bỏ phiếu tán thành, bỏ phiếu chấm điểm, đa số phiếu, v.v.
[0] https://www.when2meet.com/
Trả lời câu hỏi giảm chi phí: nếu chạy trên một VPS Linux duy nhất thì có lẽ có thể hạ xuống 5–10 USD mỗi tháng
Điều thú vị là biểu đồ tăng trưởng lại tuyến tính. Ứng dụng rõ ràng có một mức traction nhất định và cũng có tính lan truyền, vậy tại sao lại không tăng theo cấp số nhân?
Thực tế chắc khoảng 100 USD, nhưng nói thật là đang cấp hơi dư khá nhiều. Dù vậy traffic của tôi còn lớn hơn nhiều so với phần mô tả trong blog
Tôi nghĩ cải thiện kiến trúc có thể giảm chi phí
Ở khoảng giữa bài, tác giả đưa ra tăng trưởng logistic như một mô hình khác phù hợp hơn với kiểu tăng trưởng này. Sau giai đoạn tăng nhanh ban đầu là đoạn tăng trưởng tuyến tính, rồi cuối cùng phẳng lại khi chạm “giới hạn sức chứa” hoặc “bão hòa thị trường”
Tôi đang host một ứng dụng tương tự ở netcup, Hetzner với 3 USD/tháng, và khi lên HN nó vẫn xử lý dễ dàng hơn 10.000 request/giờ
Bất kể con số thực tế là gì, tôi luôn tò mò các dự án như vậy trang trải chi phí duy trì thế nào
Một ý tưởng tôi từng quan tâm là xử lý việc này theo cách phi tập trung. Dự án nhận tiền, và nếu mỗi tháng không trả được hóa đơn thì nó chết
Nếu có đủ tiền dư, có lẽ có thể mua trái phiếu kho bạc Mỹ kỳ hạn phù hợp rồi tiêu dần theo thời gian
Trước đây chắc cần tự động hóa, nhưng trong tương lai gần, có khi một AI agent bị giới hạn có thể đóng vai trò như server và cứ để nó tự làm việc của mình
Mô hình trả theo mức dùng rất tốt khi doanh thu cũng tăng theo mức dùng. Với các dự án của tôi, tôi muốn có gói cước mà chi phí cố định dù cao hơn nhưng rủi ro chỉ nằm ở tính sẵn sàng chứ không nằm ở chi phí
Vì vậy với mô hình trả theo mức dùng, doanh thu thường không khớp kỳ vọng, còn gói theo bậc dễ thắng trên thị trường vì thu được nhiều tiền hơn
Ngoại lệ là những thứ như lưu trữ file, nơi tôi cảm giác mọi người thường đánh giá thấp dung lượng họ cần
Tôi thật sự thích spliit và dùng thường xuyên, nhiều lần mỗi tuần
Điều khiến tôi phát điên là nó hoạt động rất tệ trên kết nối di động chậm. Tôi muốn thêm hỗ trợ local-first hoặc offline-first, nhưng biết đó là thay đổi lớn
Dù vậy chỉ cache các trang như trang thêm khoản chi thôi cũng có lẽ đã cải thiện khá nhiều
Ý tưởng thì hay, nhưng nhìn số traffic thì một DigitalOcean droplet 4 USD/tháng cũng có vẻ cho kết quả tương tự
Dùng Vercel thành ra đã đốt hơn 1.000 USD. Có lẽ vì tôi già rồi nên không hiểu lối lập luận này
Chỉ cần cấu hình một VPS cơ bản một lần là ra cùng kết quả và chi phí cũng trung tính; mấy ứng dụng miễn phí nhỏ của tôi cũng chạy như vậy
Có lẽ với tác giả, 100 USD/tháng không phải gánh nặng lớn, hoặc họ ở tình huống sẵn sàng trả chừng đó cho sự tiện lợi
Chi phí web hosting thực ra gần như không đáng kể. Phần lớn chi phí nằm ở cơ sở dữ liệu
Một ứng dụng thật sự tuyệt vời. Rất vui vì tác giả chia sẻ chi tiết chi phí
Nếu các ngân hàng chịu tỉnh táo, tính năng này đã trở thành tính năng mặc định trong app ngân hàng dựa trên ACH/Zelle/FedNow rồi
Người tổ chức phải có thể tạo nhóm trong app ngân hàng và mời những người dùng có tài khoản ở các ngân hàng khác nhau
Yêu cầu thanh toán nên được xử lý bằng một cú nhấp, và không còn phải kiểm tra thủ công xem tiền đã vào Cash App, tài khoản ngân hàng hay Venmo chưa rồi lại đánh dấu khoản chi trong ứng dụng bên thứ ba
Thứ cần có là tích hợp nhà cung cấp thanh toán. Chỉ cần cho phép thanh toán tức thì bằng ACH hoặc thẻ tín dụng
Bản thân việc đó cũng có thể là một lựa chọn kiếm tiền
Tôi nghĩ tốt hơn là giữ mã nguồn mở và miễn phí, tiếp tục là một ứng dụng tiện lợi cho các giao dịch tiền mặt
Nếu dùng các giải pháp cơ sở dữ liệu serverless như Supabase hoặc NeonDB, có lẽ có thể tiết kiệm được khá nhiều tiền