- Câu chuyện kinh nghiệm thực tế của một lập trình viên solo đã tự phát triển và bảo trì toàn bộ dịch vụ bằng Rails, đồng thời đạt ARR (doanh thu định kỳ) 1 triệu euro mỗi năm
- Ban đầu chỉ khởi đầu với một MVP cơ bản, nhưng sau đó đã phát triển thành một cấu trúc có thể duy trì lâu dài thông qua viết lại toàn bộ và cải tổ kiến trúc
- Cốt lõi nằm ở triết lý nhất quán, các thành phần cấu thành của Rails, cùng khả năng hỗ trợ di động thông qua Turbo Native
- Một kiến trúc hiệu quả có thể vận hành với chi phí máy chủ dưới 1.500 euro/tháng trong khi vẫn gánh được toàn bộ lưu lượng và mức sử dụng
- Cuối cùng, tác giả bán một phần cổ phần cho nhà đầu tư định hướng dài hạn và tuyển lập trình viên thứ hai sau 14 năm, mở ra một giai đoạn mới
Ứng dụng thực chiến của The One-Person Framework
Đạt 1 triệu euro ARR chỉ với Rails
- Đầu năm 2022, PlanGo đã vượt mốc 1 triệu euro ARR (doanh thu định kỳ hàng năm), và đây là một thành tựu tưởng như trong mơ đối với một dịch vụ được xây dựng bằng một codebase Rails duy nhất và một lập trình viên duy nhất
- Mọi lĩnh vực ngoài kỹ thuật — xây dựng tầm nhìn, thu hút khách hàng, chiến lược tăng trưởng — do đồng sáng lập và đội hỗ trợ khách hàng đảm nhiệm, nhưng từ thiết kế kiến trúc, triển khai, vận hành đến hiện thực frontend/backend đều do một mình tác giả thực hiện
- Điều mà DHH gọi là “One Person Framework”, tức một cấu trúc nơi một lập trình viên có thể quản lý toàn bộ ứng dụng, đã được chứng minh là thực tế chứ không chỉ là lý thuyết
- Triết lý kiến trúc của Rails — từ thiết kế cơ sở dữ liệu, business logic đến UI frontend đều có thể thực hiện trong một bộ công cụ nhất quán — đặc biệt có lợi cho các startup nhỏ hoặc người khởi nghiệp một mình
- Bài viết này dành cho những người như sau:
- Lập trình viên Rails: những người đang băn khoăn liệu ngày nay có còn có thể một mình tạo ra sản phẩm lớn hay không
- Nhà sáng lập công nghệ: những người đang phải gánh nhiều vai trò và cảm thấy quá tải
- Những người coi trọng tinh thần craftsmanship và lựa chọn công nghệ
Bối cảnh lúc bắt đầu
- Tác giả bắt đầu làm quen với Rails vào năm 2011, khi là một lập trình viên 21 tuổi và đang làm dự án PHP(CodeIgniter)
- Không có chiến lược lớn nào cả, chỉ đơn giản là muốn thử dùng Rails theo xu hướng
- Từ ý tưởng marketing của đồng sáng lập, họ triển khai chiến lược ưu đãi ai đăng ký trong tuần ra mắt sẽ được dùng miễn phí 1 năm
- Họ nghĩ chỉ vài chục người đăng ký, nhưng thực tế là hơn 500 người đã đăng ký chỉ trong tuần đầu tiên
- Vì sản phẩm mới chỉ ở mức MVP, ngay lập tức hàng trăm yêu cầu tính năng, câu hỏi và yêu cầu hỗ trợ đổ về
- Máy chủ vẫn chạy ổn, nhưng nhu cầu từ khách hàng bùng nổ khi sản phẩm còn chưa hoàn thiện
- Cả hai đồng sáng lập đều đang có công việc chính nên không thể phản ứng toàn thời gian
- Kết quả là họ rơi vào tình huống buộc phải làm nhiều người dùng đầu tiên thất vọng
- Trải nghiệm này khiến họ nhận ra sâu sắc rằng “phát triển phần mềm” và “vận hành một doanh nghiệp phần mềm” là hai bài toán hoàn toàn khác nhau
- Chỉ hiện thực tính năng là chưa đủ; bài học rút ra là cần có khả năng hỗ trợ khách hàng bền vững, quản lý kỳ vọng và hệ thống vận hành dịch vụ
Vừa làm vừa học
- Tác giả bắt đầu phát triển bằng cách tham khảo tutorial Rails và Stack Overflow, nhưng xây dựng một ứng dụng chịu trách nhiệm cho doanh nghiệp thật của khách hàng trong môi trường production là câu chuyện ở một đẳng cấp hoàn toàn khác
- Code Rails thời kỳ đầu có những sai lầm điển hình của người mới như sau:
- Phương thức controller dài hơn 200 dòng
- Model khổng lồ với vai trò lẫn lộn
- Câu lệnh SQL kém hiệu quả
- Không có test
- Giá trị cấu hình và secret key bị commit vào Git
- Dù có thể hiện thực tính năng, toàn bộ ứng dụng vẫn phụ thuộc vào code chắp vá và cấu trúc thiếu ổn định
- Các tính năng như xác thực người dùng, upload file, tạo PDF, admin UI, xử lý email... đều được triển khai nhanh bằng Gem, nhưng theo thời gian mỗi Gem lại tạo ra thêm độ phức tạp và vấn đề mới
- Khi dùng
.round(2), "banker's rounding" được áp dụng khác với kỳ vọng, gây lỗi tính toán tiền tệ
- Vì giao cả phép tính đơn giản cho Gem bên ngoài, vấn đề phát sinh từ việc thiếu hiểu biết bản chất về xử lý số
- Khoảng năm 2013, khi kinh nghiệm vận hành sản phẩm tăng lên thì technical debt cũng tăng rất nhanh, khiến việc phát triển tính năng mới ngày càng khó khăn
Viết lại toàn bộ
- Viết lại toàn bộ (Full Rewrite) thường bị xem là một lựa chọn rủi ro và kém hiệu quả, nhưng năm 2014 tác giả quyết định xây lại từ đầu trên nền Rails 4
- Trong nhiều tháng, tác giả vừa duy trì ứng dụng cũ vừa tập trung phát triển codebase mới song song
- Kiến trúc được đơn giản hóa, số lượng phụ thuộc Gem giảm xuống còn chưa tới một nửa, đồng thời đưa test vào các chức năng cốt lõi
- Cấu trúc mới gọn gàng và nhanh hơn trước, đồng thời được thiết kế ở mức một lập trình viên part-time vẫn có thể bảo trì được
- Bản rewrite này sau đó trở thành nền tảng kỹ thuật để một lập trình viên solo có thể vận hành trong hơn 10 năm
Rails là siêu năng lực
- PlanGo được vận hành bởi đúng một lập trình viên cho tới năm 2025, và yếu tố cốt lõi tạo nên điều đó chính là Rails
- Nhờ các đặc tính cấu trúc của Rails như Convention over Configuration, integration test, ActiveRecord, ActiveStorage, ActiveJob..., tác giả có thể giảm thiểu các quyết định không cốt lõi và tập trung vào việc tạo ra giá trị chính
- Sau khi áp dụng Turbolinks và Hotwire, họ có thể xây dựng UI hiện đại mà không cần framework JS phức tạp
- Thời điểm bắt đầu phát triển vào năm 2011, nhu cầu ứng dụng di động gần như không có, nhưng về sau ứng dụng iOS/Android đã trở thành giao diện chính của PlanGo
- Họ đã thử nhiều framework như Titanium, RubyMotion, Objective-C và gặp phải bài toán cân bằng giữa chất lượng và tốc độ
- Sau khi áp dụng Turbo Native, năng suất tăng mạnh và chỉ với kiến thức native cơ bản cũng có thể tận dụng codebase Rails để tạo ra ứng dụng chất lượng cao
- Cách tiếp cận này đặc biệt lý tưởng cho các ứng dụng B2B hoặc SaaS, vì có thể đạt hiệu năng và trải nghiệm native với chi phí phát triển nhỏ
- Kết quả là họ đạt hơn 100.000 lượt tải ứng dụng mỗi năm, thậm chí có lúc xếp hạng trên Duolingo trên App Store Hà Lan
- Tất cả các ứng dụng đều được phát triển và bảo trì bởi một lập trình viên Rails duy nhất
- Các chỉ số chính:
- Code Ruby: 36.170 dòng
- Code JavaScript: 13.495 dòng
- Độ phủ test: 40%
- Người dùng hoạt động hằng ngày: 6.332
- Số request mỗi phút vào giờ cao điểm: 7.000
- Chi phí vận hành máy chủ mỗi tháng: dưới €1.500
- Việc duy trì kiến trúc monolith có cấu trúc là một trong những quyết định đúng đắn nhất; có thể triển khai đơn giản bằng Capistrano và dễ debug mà không có độ phức tạp của microservices
- Với nhà sáng lập công nghệ, Rails không chỉ là một framework mà còn là siêu năng lực giúp một người làm được công việc của cả một đội
Vượt qua cột mốc 1 triệu euro
- Cuối năm 2022, một bước ngoặt bất ngờ xuất hiện: một nhà đầu tư nước ngoài tỏ ra quan tâm tới PlanGo và gửi đề nghị mua lại
- Khi đó, PlanGo đã vượt €1M ARR theo mô hình bootstrap, đồng thời vẫn duy trì cấu trúc lợi nhuận bền vững và vận hành hiệu quả mà không cần vốn bên ngoài
- Đề nghị này trở thành dịp để đội ngũ tự đặt câu hỏi: "Chúng ta muốn gì trong tương lai?"
- Họ xem xét nhiều khả năng: giữ nguyên cách vận hành hiện tại, scale up bằng vốn bên ngoài hay bán hoàn toàn
- Dù tình yêu dành cho doanh nghiệp vẫn còn rất lớn, họ cũng bắt đầu nhận ra rằng nếu có thêm nguồn lực và chuyên môn thì việc biến cơ hội thành hành động sẽ dễ dàng hơn nhiều
- Xét về mặt hiện thực hóa lợi ích tài chính, việc thu hồi một phần giá trị đã tích lũy hơn 10 năm trong khi vẫn tiếp tục phát triển doanh nghiệp là một lựa chọn hợp lý
- Cuối cùng, họ chọn hình thức hợp tác với một quỹ evergreen tại Hà Lan có giá trị và định hướng dài hạn phù hợp
- Bán một phần cổ phần nhưng vẫn giữ quyền điều hành và cổ phần chi phối
- Có thêm nguồn lực mà vẫn không làm tổn hại đến cấu trúc và văn hóa hiện có
- Quyết định này không phải là một đợt exit ngắn hạn hay mở rộng quá quyết liệt, mà là một phần của chiến lược tăng trưởng ổn định dựa trên doanh nghiệp bền vững và lấy khách hàng làm trung tâm
- Sau đó, họ bước vào một giai đoạn mới, vẫn giữ nguyên cách tiếp cận dựa trên Rails nhưng theo đuổi tích cực hơn những cơ hội trước đây khó thực hiện
Những điều đã học được
- Dưới đây là những bài học rút ra sau 14 năm vận hành PlanGo với tư cách là một nhà sáng lập công nghệ solo
- Embrace Rails conventions
- Điều quan trọng là đừng cố đi ngược lại triết lý và quy ước của Rails
- “Rails Way” là cách giải quyết vấn đề đã được kiểm chứng, và càng đi theo nó thì càng có thể tập trung vào giá trị riêng của sản phẩm
- Less is more
- Gem hay thư viện JS có thể giúp hiện thực tính năng nhanh, nhưng đồng thời cũng làm tăng độ phức tạp và khả năng hỏng hóc
- Trước khi thêm một dependency mới, nhất định phải tự hỏi: "Điều này có thực sự cần không?"
- Find a community
- Với lập trình viên solo, việc kết nối với những lập trình viên Rails khác là cực kỳ quan trọng
- Ví dụ, cộng đồng mà tác giả có được khi xây dựng Spina CMS tuy không phải đồng nghiệp trực tiếp, nhưng đã trở thành một mối liên kết quý giá để chia sẻ kiến thức và nhận phản hồi
- Technical debt isn't always bad
- Đôi khi một lựa chọn thực dụng để vào thị trường nhanh lại tốt hơn sự hoàn hảo về mặt kỹ thuật
- Điều cốt lõi là phân biệt rõ khi nào chủ động chấp nhận technical debt và khi nào cần trả nó
- You can go far alone
- Với Rails, một lập trình viên cũng có thể thiết kế, mở rộng và triển khai một sản phẩm ở quy mô của cả đội
- Không cần bị trói buộc bởi quan niệm phổ biến rằng nhất định phải có cả một đội ngũ
Phía trước
- Đối tác đầu tư mới đồng ý với mô hình vận hành tinh gọn của PlanGo, nhưng đưa ra đúng một điều kiện: bổ sung thêm một lập trình viên Rails
- Vấn đề không nằm ở việc cố chấp làm solo, mà ở độ khó của chính quá trình onboarding một lập trình viên mới vào codebase đã phát triển suốt 14 năm
- Codebase đó không chỉ là quá trình tiến hóa của PlanGo, mà còn là lịch sử phát triển cá nhân từ người mới đến người thành thạo của chính tác giả,
nơi đan xen các quyết định và phong cách code của nhiều phiên bản khác nhau của chính mình theo từng thời kỳ
- Khi tuyển được lập trình viên Rails thứ hai gặp tại Rails World (Canada), họ đã tạo ra thay đổi mang tính cấu trúc và tác động tích cực
- Loại bỏ rủi ro kỹ thuật là điểm lỗi đơn lẻ
- Có thêm góc nhìn và ý tưởng mới
- Nâng cao chất lượng code thông qua pair programming
- Sự kích thích trí tuệ từ việc cộng tác với một đồng nghiệp lập trình nói cùng một ngôn ngữ
- Trong tương lai, họ không có kế hoạch xây dựng một đội phát triển lớn
- Như những gì đã được chứng minh cho đến nay, chỉ với cách tiếp cận dựa trên Rails, một đội nhỏ nhưng mạnh vẫn có thể tạo ra phần mềm có ý nghĩa
- Tuy vậy, họ cũng cảm nhận rõ rằng ngay cả lập trình viên solo hiệu quả nhất cũng có thể phát triển hơn nữa khi có đồng đội tốt
- Hành trình của PlanGo là một ví dụ cho thấy One-Person Framework của Rails thực sự hoạt động,
đồng thời là bằng chứng rằng một đội nhỏ với công cụ phù hợp có thể xây dựng một doanh nghiệp nghiêm túc theo tiêu chuẩn của chính mình
- Dù là một lập trình viên solo đang làm sản phẩm đầu tiên hay một đội nhỏ đang cân nhắc tech stack, hy vọng câu chuyện này sẽ cho thấy những khả năng có thể đạt được khi tận dụng Rails đến mức tối đa
4 bình luận
Tôi đã thử tạo một podcast bằng phần Audio Overview của NotebookLM cho nội dung này.
https://notebooklm.google.com/notebook/…
Mức này là khá tuyệt rồi. Tôi sẽ cần trau chuốt thêm nữa.
Wow.. thật sự quá đỉnh.. tự nhiên đến mức này luôn
Và thông tin thật sự rất dễ tiếp thu...
Ý kiến trên Hacker News
Có người dùng có trải nghiệm tương tự Django đang vận hành ứng dụng của riêng mình
Có người cho rằng con người quan trọng hơn framework
Có người chia sẻ kinh nghiệm dùng Rails và Phoenix
Có người nói rằng họ đã có một bài trình bày về việc Rails 7+ giúp solo developer xây dựng cả những ứng dụng nhiều tham vọng
Có người chia sẻ trải nghiệm từng có đối tác mới muốn bổ sung thêm lập trình viên Rails
Có người đang xây dựng ứng dụng bằng AdonisJS
Có người cho rằng Rails có nhiều điểm tốt hơn Django
Có solo developer đang xây dựng ứng dụng bằng Rails
Có người cho rằng nên tránh việc viết lại toàn bộ
Có người nghĩ rằng framework không quá quan trọng