3 điểm bởi GN⁺ 2024-04-08 | 2 bình luận | Chia sẻ qua WhatsApp
  • Lago, công ty có trụ sở tại Paris, cùng với việc ra mắt chính thức đã công bố thành quả chuyển hướng thành nền tảng tính phí mã nguồn mở dành cho nhà phát triển, đồng thời huy động khoảng 22 triệu USD ($22m) qua hai vòng gọi vốn
  • Vòng Series A 15 triệu USD mới nhất do FirstMark dẫn dắt, còn vòng seed 7 triệu USD trước đó do SignalFire dẫn dắt; Y Combinator, New Wave, Script và các nhà đầu tư cá nhân cũng tham gia
  • Đội ngũ ban đầu định xây dựng “Zapier” cho các nhóm marketing, nhưng sau khi bài viết trên Hacker News về vấn đề tính phí cho nhà phát triển nhận được phản hồi lớn, họ đã pivot sang nền tảng tính phí
  • Mistral.ai, Together.ai và Juni tham gia với tư cách khách hàng ban đầu trong giai đoạn beta kín; Lago nhắm đến các startup xử lý mô hình giá đăng ký, dựa trên mức sử dụng và hybrid
  • Trong thị trường có Stripe, Adyen, Salesforce, Zoho, Paddle..., Lago lấy khả năng mở rộng và triển khai tính phí tùy biến làm điểm khác biệt

Ra mắt chính thức và cấu trúc đầu tư

  • Startup Lago có trụ sở tại Paris, cùng với việc ra mắt chính thức nền tảng tính phí mã nguồn mở, đã công bố huy động tổng cộng 22 triệu USD
  • Khoản đầu tư gồm hai vòng
    • Vòng Series A 15 triệu USD mới nhất do FirstMark dẫn dắt
    • Vòng seed 7 triệu USD trước đó do SignalFire dẫn dắt
  • Y Combinator, New Wave và Script cũng tham gia với tư cách nhà đầu tư
  • Các nhà đầu tư cá nhân bao gồm Meghan Gill, phụ trách kiếm tiền tại MongoDB; Romain Huet, cựu nhân sự Stripe và phụ trách quan hệ nhà phát triển tại OpenAI; cùng Clément Delangue, CEO Hugging Face
  • Theo nguồn tin, định giá của Lago ở mức khoảng 100 triệu USD

Beta kín và khách hàng ban đầu

  • Trước khi ra mắt chính thức, Lago vận hành dưới dạng beta kín
  • Khách hàng ban đầu bao gồm các startup như Mistral.ai, Together.ai và Juni
  • Trọng tâm là giúp nhà phát triển có thể tự điều chỉnh hệ thống tính phí cho phù hợp với dịch vụ mới
  • Hỗ trợ đo lường dữ liệu sử dụng để xử lý gói đăng ký hoặc các mô hình giá khác

Pivot từ công cụ marketing sang nền tảng tính phí

  • Lago không phải là công ty định xây dựng nền tảng tính phí ngay từ đầu
  • Hai đồng sáng lập Anh-Tho Chuong và Raffi Sarkissian khởi nghiệp sau khi làm việc tại Qonto, rồi tham gia cohort Y Combinator Summer 2021
  • Khi vào YC, họ chưa có sản phẩm; sau đó chọn ý tưởng “Zapier” dành cho các nhóm marketing
  • Trong thị trường công nghệ marketing cạnh tranh khốc liệt, sản phẩm ban đầu hầu như không tạo được sức kéo
  • Để thu hút sự chú ý, Sarkissian đăng một bài trên Hacker News về vấn đề tính phí cho nhà phát triển
    • Tiêu đề là “Billing systems are a nightmare for engineers”
    • Nội dung gắn với trải nghiệm từng xây dựng sản phẩm giải quyết vấn đề tính phí tại Qonto
  • Khi nhiều người dùng chia sẻ vấn đề tính phí của họ, Lago chuyển hướng sang giải quyết bài toán tính phí cho nhà phát triển

Chiến lược mã nguồn mở nhắm vào tính phí phức tạp

  • Lago cho rằng đã có nhiều giải pháp cho các mô hình giá và tính phí đơn giản, nhưng tính phí phức tạp vẫn chưa có đủ lời giải
  • Các công ty xây dựng sản phẩm dựa trên AI đang tìm mô hình kinh doanh khả thi, và nhiều trường hợp cân nhắc cách tiếp cận hybrid kết hợp đăng ký cố định với giá dựa trên mức sử dụng
  • Cách này cần công cụ có thể tích hợp với sản phẩm do nhà phát triển xây dựng, đồng thời nhận diện và áp dụng dữ liệu sử dụng
  • Nhiều công ty tự xây hệ thống tính phí như Qonto, nhưng kỹ sư không thích việc này và chi phí thuê kỹ sư chuyên trách cũng lớn
  • Timothée Lacroix, đồng sáng lập kiêm CTO của Mistral.ai, cho biết lý do chọn Lago là niềm tin vào hệ sinh thái mã nguồn mở, và Lago giúp họ theo kịp tốc độ phát hành cũng như tập trung vào công việc cốt lõi

Cục diện cạnh tranh và các mảng mở rộng tiếp theo

  • Thị trường tính phí đã có các giải pháp từ những công ty công nghệ lớn như Stripe, Adyen, Salesforce, Zoho và Paddle
  • Cũng có các nhà cung cấp hiện hữu chọn cách tiếp cận mã nguồn mở
    • FOSSBilling
    • ChargeBee
    • Kill Bill
    • jBilling của AppDirect
    • Open Source Billing
  • Lago cho rằng ngay cả trong thị trường nhiều cạnh tranh, vẫn có cơ hội ở khả năng mở rộng và triển khai tính phí tùy biến theo từng startup
  • Trong tương lai, bên cạnh mở rộng mảng kinh doanh hiện tại, công ty sẽ xem xét hai lĩnh vực
    • Phân tích dữ liệu liên quan đến ý tưởng marketing ban đầu: cung cấp thông tin về khách hàng tiêu thụ và thanh toán cho gì, cũng như mô hình thanh toán ra sao
    • Mảng thanh toán, ở phía đối diện của tính phí
  • Khả năng tự xây dựng toàn bộ payment stack là thấp; nhiều khả năng Lago sẽ tập trung vào điều phối thanh toán, giúp người dùng dùng công cụ thanh toán họ muốn đồng thời tích hợp tốt với nền tảng tính phí

2 bình luận

 
xguru 2024-04-08

Lago đã rất nhiệt tình trong việc so sánh mình với Stripe... đúng là cũng gọi được khá nhiều vốn đầu tư nhỉ.
Họ cũng từng công khai những bài viết như Mức giá thực tế của Stripe: bài nhập môn.

Nhưng mà việc một API billing là mã nguồn mở thì đúng là vẫn có gì đó hơi không ăn khớp.

 
GN⁺ 2024-04-08
Ý kiến trên Hacker News
  • Tôi đã định dùng thử cho một sản phẩm SaaS mới, nhưng khá bất ngờ vì gói giá bắt đầu từ 3.000 USD/tháng
    Có vẻ như hướng đi đang bị ngược. Những nhóm nhỏ như tôi không muốn tự host, mà muốn một giải pháp được quản lý sẵn. Các công ty lớn thì có quy mô nên ngược lại lại có khả năng tự host

    • Tôi hiểu ý, nhưng chiến lược này cũng có thể hiệu quả. Ở công ty trước, ban đầu chúng tôi bắt đầu với Stripe; doanh thu còn ít nên chi phí gần như không đáng kể và tích hợp cũng dễ
      Vài năm sau, khi khối lượng giao dịch tăng lên, chúng tôi muốn đàm phán lại hợp đồng. Nếu khi đó có thể tích hợp lại sang Lago, nó có lẽ đã trở thành quân bài thương lượng khi gia hạn hợp đồng Stripe. Chúng tôi đang trả 30.000 USD/tháng tiền phí Stripe, nên một phương án thay thế 3.000 USD/tháng hoàn toàn có thể đáng giá. Trường hợp của chúng tôi hơi khác vì là bán lẻ chứ không phải tính phí SaaS, nhưng tôi thấy có những trường hợp hợp lý về mặt tài chính
    • Tôi cũng rơi vào đúng cái bẫy đó. Tính phí theo mức sử dụng là nỗi đau lớn với chúng tôi nên đã kỳ vọng nhiều vào Lago, nhưng nếu có thể thuê ngoài thì tôi không muốn tự vận hành hạ tầng
      Tôi đã nói chuyện với khoảng 5 nhà cung cấp API tính phí theo mức sử dụng, và thực tế là gần như không ai quan tâm đến thị trường dưới 1.000 USD/tháng nơi chúng tôi sẽ ở trong giai đoạn tăng trưởng năm tới. Hơn nữa, Lago và các bên khác tuy quảng cáo là “không chia sẻ doanh thu” nhưng lúc nào cũng đưa ra giá theo tỷ lệ doanh thu. Về mặt kỹ thuật thì không phải chia sẻ doanh thu, nhưng chi phí tăng gần như tuyến tính theo doanh thu
    • Chỉ khi chiến lược là nhắm vào phân khúc thấp của thị trường thì hướng đi mới bị ngược. Ở đây không có vẻ là chiến lược đó
    • Mức giá này có vẻ cho thấy họ nhắm tới khách hàng lớn của Stripe đang chi hơn 3.000 USD/tháng tiền phí
      Nếu chiến lược giá là tránh những khách hàng nhỏ, tốn nhiều chi phí hỗ trợ và lợi nhuận thấp, để Stripe chịu lỗ với nhóm đó rồi chỉ chọn lấy những khách hàng tốt đã trưởng thành trên Stripe, thì khá khôn ngoan
    • Thị trường họ nhắm tới có thể là cỡ những con cá hồi tầm trung
  • Tôi nghĩ bán cho lập trình viên sẽ khó. Lập trình viên không chịu chi tiền và thường muốn tự làm, kể cả khi chi phí cơ hội cao gấp 10 lần
    Và ngay khi họ cố kiếm tiền bằng cách nào đó, sẽ có làn sóng rời bỏ quy mô lớn vì bị xem là “phản bội” như vụ Redis. Tôi biết vì chính tôi cũng là kiểu lập trình viên đó

    • Tính phí theo mức sử dụng rất khó. Tôi đã xem xét Lago khá nghiêm túc, nhưng nó không phù hợp với mảng API B2C của tôi
      Tôi nhất thiết cần cổng thông tin khách hàng, nhưng đó là tính năng premium, và gói premium tối thiểu là 1.500 USD/tháng. Với doanh thu của tôi thì khó biện minh được. Tuy vậy, Lago chủ ý tránh tính phí theo tỷ lệ doanh thu nên buộc phải thu phí cơ bản cao. Stripe Billing tính phí theo tỷ lệ, và với một doanh nghiệp đang tăng trưởng thì hóa đơn Stripe vượt 1.500 USD chỉ là vấn đề thời gian
      Tôi cũng đã xem xét tính phí theo mức sử dụng của Stripe Billing, nhưng nó không đáp ứng yêu cầu của tôi. Tôi đang dùng Stripe Billing cho các khoản tính phí cố định
      Yêu cầu chính xác là tôi muốn bán trước credit API bao gồm trong gói đăng ký. Ví dụ, nếu người dùng đăng ký gói credit 10 USD/tháng, họ trả trước 10 USD rồi dùng lượng credit tương ứng. Stripe Billing không hỗ trợ thu tiền trước cho tính phí theo mức sử dụng, mà chỉ thu sau khi kỳ thanh toán kết thúc. Một số người dùng có thể lợi dụng hệ thống bằng cách hủy rồi không trả tiền, nên không phù hợp với tôi. Tôi nhớ Lago có hỗ trợ thu tiền trước
      Tôi cũng muốn trộn linh hoạt credit theo gói đăng ký và credit trả trước. Khi người dùng vượt hạn mức trong tháng, họ thích nạp một lần hơn là nâng cấp lên gói cao nhất. Tôi cũng cần kiểm soát loại credit nào bị trừ trước, nhưng cả Stripe Billing lẫn Lago đều gặp vấn đề ở chỗ này
      Tôi cũng muốn hỗ trợ càng nhiều phương thức thanh toán càng tốt, đặc biệt là các ví Trung Quốc như Alipay và WeChat cho credit trả trước. Lago không có kế hoạch triển khai việc này, và tôi thậm chí đã nửa cân nhắc tự triển khai nó trong Lago. Với B2B, WeChat và Alipay có thể không quá quan trọng
      Ngoài ra, tôi thích code có kiểm thử hồi quy rất chặt chẽ; nhờ tính năng test clock, Stripe Billing vượt xa Lago ở điểm này. Lago không có chức năng tua thời gian để kiểm thử vòng đời subscription. Nếu tin tưởng sản phẩm thì có thể chỉ cần kỳ vọng nhận callback đúng lúc, nên điều này có thể ít quan trọng hơn
      Dù vậy, tôi thấy các lập trình viên của Lago trên Slack dành thời gian trả lời cả những câu hỏi kỹ thuật rất sâu. Nếu tôi vận hành một startup B2B, đặc biệt vào thời điểm có nhiều trường hợp tài khoản Stripe bị đình chỉ, có lẽ tôi sẽ cố tìm cách điều chỉnh để dùng Lago
    • Đây là lỗi suy nghĩ điển hình rằng người khác cũng giống mình. Tôi cũng là lập trình viên, nhưng sẵn sàng trả tiền cho những thứ giúp tiết kiệm thời gian
      Và tôi nghĩ đây chẳng phải là giả thuyết cốt lõi của Lago sao. Lập trình viên muốn phần mềm billing mã nguồn mở có thể tự sửa khi cần, thay vì phụ thuộc vào một nhà cung cấp độc quyền như Stripe. Ý tưởng đó không hề vô lý
    • Không phải lập trình viên không chi tiền. Tôi tin rằng tư duy kinh tế là một yếu tố cơ bản của kỹ thuật. Nếu không suy nghĩ theo hướng kinh tế, có thể bạn đang làm gì đó, nhưng có lẽ không phải là kỹ thuật
      Như bình luận bên cạnh, tôi sẵn sàng trả tiền cho những thứ tạo ra giá trị và tiết kiệm thời gian. Ngay từ đầu tôi chưa từng nghĩ đến việc tự xây hệ thống billing
    • Nếu họ chưa giải quyết được vấn đề này rồi thì tôi nghĩ họ đã không gọi được số vốn đầu tư ở mức đó
  • Có thể là vì tôi đã già nên cảm nhận của tôi về ý nghĩa của mã nguồn mở không còn thích nghi được với những thay đổi thực tế nữa, nhưng cứ thấy mã nguồn mở và “đầu tư $22M” xuất hiện trong cùng một câu là tôi lập tức nghĩ “mã nguồn mở cái gì chứ”

    • Có hướng dẫn nào về cách tạo phần mềm mã nguồn mở mà không kiếm tiền từ nó không? Hay cứ nhận vốn VC là không còn thật sự là mã nguồn mở nữa?
      Tôi đã thấy tâm lý này rất nhiều, đặc biệt là cả từ những cựu binh mã nguồn mở như rich harris. Trớ trêu là hiện anh ấy cũng đang nhận lương từ tiền VC. Một mặt tôi cũng muốn phàn nàn, muốn nói rằng mọi người nên tạo phần mềm mở chỉ vì niềm vui xây dựng và chia sẻ. Nhưng sống trong thế giới thực rất tốn kém, và việc kỳ vọng ai đó dành đêm và cuối tuần để làm ra phần mềm mà tôi dùng hữu ích, thậm chí có thể trực tiếp kiếm tiền từ đó, rồi chỉ nhận lại sao GitHub, có vẻ vừa kém hiệu quả vừa không công bằng.
    • Đồng ý, nhưng đồng thời tôi cũng không biết phương án thay thế là gì. Cứ làm trong thời gian rảnh, xin vài đồng quyên góp, rồi để $corporate bán nó như một dịch vụ mà không trả lại gì sao?
      Trong bối cảnh Lago, tôi không rõ lợi ích của mã nguồn mở ngoài quảng bá và thiện cảm của developer là gì. Dạo này làm mã nguồn mở là rơi vào thế tiến thoái lưỡng nan, và nếu đây là tương lai mang lại vòng đời dài hơn cùng hỗ trợ tốt hơn thì có lẽ đành chấp nhận.
    • Nếu tôi sai thì mong được sửa, nhưng SUSE, Red Hat, Databricks cũng kiểu này không phải sao? Tôi hiểu đây là mô hình cung cấp công cụ mã nguồn mở hữu ích, rồi kiếm tiền từ các dịch vụ xung quanh nó để duy trì phát triển.
    • Ý là “mã nguồn mở cho đến khi VC tăng áp lực kiếm tiền”. Sau đó họ đổi sang giấy phép hạn chế hơn và phá hỏng cả các contributor hiện có lẫn toàn bộ cộng đồng.
    • Tôi không muốn tranh cãi với trực giác “mã nguồn mở cái gì chứ”, nhưng có thể thử giải thích vì sao lại có cảm giác đó.
      Tinh thần khi mã nguồn mở bắt đầu vào giữa thập niên 1970 là chia sẻ phần mềm miễn phí. Tiền khi đó đến dưới dạng tài trợ nghiên cứu từ đại học hoặc doanh nghiệp, chứ không có mô hình kinh doanh. Đến năm 1998, tiền bắt đầu đổ vào thực sự khi RedHat, MySQL và những công ty khác đặt hỗ trợ và dịch vụ trả phí lên trên phần mềm tự do. Từ giữa thập niên 2000, nhờ điện toán đám mây, ý tưởng kiếm tiền từ mã nguồn mở trở nên phổ biến. Với SaaS, người dùng không biết hoặc không quan tâm bên trong là mã nguồn mở hay phần mềm độc quyền, nên mã nguồn mở cũng bước lên cùng một sân chơi.
      Có vài lý do khiến VC thích mã nguồn mở. Tôi là nhà đầu tư xuất thân từ kỹ sư machine learning; cá nhân tôi cũng có chút hoài niệm vì từng dùng các dự án mã nguồn mở tuyệt vời như spaCy thời đại học, và tôi đồng cảm với các giá trị như cộng đồng, minh bạch, đóng góp lại. Đồng thời, công việc của VC là kiếm tiền.
      Công ty mã nguồn đóng chi rất nhiều tiền cho sales và marketing. Developer thường không thích bị bán hàng, và họ cần tự lựa chọn hơn là bị thuyết phục. Nếu một công ty giành được thiện cảm của developer, phần mềm của họ sẽ được kéo vào giai đoạn xem xét mua mà không cần chi hàng triệu đô cho sales và marketing, nên mô hình kinh doanh hiệu quả hơn. Khả năng phòng thủ cũng mạnh hơn. Doanh nghiệp lớn có thể đổ tiền vào đội ngũ sales mặc vest để bán sản phẩm, nhưng không thể mua được tình yêu của developer. Muốn có điều đó cần trải nghiệm developer xuất sắc và quan hệ tốt với developer.
      Tuy vậy, kiếm tiền từ mã nguồn mở khó hơn SaaS rất nhiều. Với SaaS, người ta nói về product-market fit. Nếu tìm được từ 5 khách hàng trở lên sử dụng theo cùng một cách, mua theo cùng một cách và nhận cùng một giá trị, tạo được tính dự đoán, VC sẽ rót tiền để mở rộng sales. Với mã nguồn mở, vấn đề này phức tạp gấp 3 lần. Project-community fit nhìn qua GitHub Stars, product-market fit nhìn qua lượt tải xuống, value-market fit nhìn qua doanh thu. Thêm nữa, người mua có thể khác developer hoặc người dùng. Phần lớn sản phẩm mã nguồn mở tuyệt vời thất bại ở value-market fit.
      Hầu hết founder công ty mã nguồn mở thất bại trong việc thu lại giá trị. Vì việc đó quá khó, hoặc vì cảm giác mã nguồn mở phải là “phần mềm miễn phí” khiến họ trì hoãn kiếm tiền. Và khi bắt đầu kiếm tiền thì đã quá muộn. Nếu suốt nhiều năm bạn đã nhận sữa miễn phí, liệu bạn có mua cả con bò không? Một lý do khác là họ không biết cách làm. Các cách điển hình để kiếm tiền từ mã nguồn mở là bán hỗ trợ và dịch vụ, open core bán tính năng độc quyền, SaaS bán hosting và công cụ. Ví dụ có RedHat, Confluent, Elastic, Databricks.
      Nói đơn giản theo tiêu chí của các công ty mã nguồn mở thành công, bản miễn phí cần có mọi tính năng mà một developer cần để hoàn thành công việc. Sản phẩm trả phí cần cung cấp các tính năng bổ sung cần thiết để một nhóm hoàn thành công việc.
      Tôi thích mã nguồn mở, và thấy rất tiếc khi những founder cực kỳ thông minh cùng vô số contributor dồn tâm huyết tạo ra sản phẩm mà vẫn không thể mở rộng và không được đền đáp. Thương mại hóa có thể giúp việc đó, nhưng thật sự rất khó. Những người đóng góp và tạo ra mã nguồn mở coi trọng cộng đồng và muốn cho đi miễn phí, nên bản thân ý nghĩ kiếm tiền đã khiến họ không thoải mái. Khi không thoải mái, con người quay về nơi quen thuộc, và với đa số kỹ sư, đó là code. Vì vậy ta có những phần mềm mã nguồn mở tuyệt vời với rất nhiều tính năng hay, cùng những founder đã trì hoãn kiếm tiền quá lâu. Đến một lúc nào đó vượt qua điểm không thể quay lại, lại thêm một công ty đầy hứa hẹn chết đi, và dù sản phẩm có tuyệt đến đâu, nhà đầu tư sẽ không đầu tư nếu họ không thể lấy lại tiền.
  • Nếu vẫn phải trả phí xử lý thì lợi thế ở đây là gì?
    Nếu phải duy trì stack thanh toán riêng và tuân thủ PCI, tôi nghĩ đó sẽ là một sự xao nhãng khổng lồ.

    • Đây là giải pháp thay thế Stripe Billing, chứ không phải bản thân mạng lưới thanh toán cốt lõi của Stripe. Thực tế là khi dùng Lago, bạn sẽ dùng Stripe hoặc một phương thức thanh toán tương tự: https://docs.getlago.com/guide/payments/overview
      Việc theo dõi thanh toán định kỳ, hóa đơn, thay đổi gói có tính theo tỷ lệ, và các edge case của tính phí theo mức sử dụng là rất khó. Và Stripe Billing API trong nhiều trường hợp cũng không mượt lắm. Có thêm một lớp mới trong lĩnh vực này là điều đáng mừng.
    • Thật ra tuân thủ PCI phần lớn đã là vấn đề được giải quyết. Nếu dùng thứ như https://verygoodsecurity.com và bọc một proxy trước Lago cùng phần self-hosting, bạn có thể thuộc mức tuân thủ PCI dễ nhất.
      Nói thêm, tôi là người sáng lập Very Good Security và đã làm CEO trong 8 năm.
    • Dù vậy người ta vẫn sẽ nói blockchain không có ứng dụng gì
  • Có một mã nguồn mở tương tự viết bằng Rust là https://hyperswitch.io
    Lago được viết bằng Ruby, và tôi cũng tìm thấy vài hệ thống billing mã nguồn mở khác viết bằng Java. Có ai biết cái nào viết bằng Node.js không?

    • Vì sao việc dịch vụ được viết bằng ngôn ngữ nào lại quan trọng? Dù sao bạn cũng đâu tương tác trực tiếp với codebase của Stripe hay Lago
    • Hyperswitch có vẻ chỉ làm thanh toán chứ không phải billing
  • Paris có vẻ thực sự là một điểm nóng để tạo ra các startup fintech mới

    • Hoàn toàn đồng ý, nhưng thành tích thì không tốt, và một phần có thể được giải thích bởi sự hỗ trợ của EU. Không có ý nói bản thân hỗ trợ của EU là xấu, nhưng châu Âu không có đủ nhà sáng lập “đói khát”, và điều này khá dễ hiểu nếu xét đến mức sống cao. Đó là nghịch lý
      Ngược lại, cũng có những phản ví dụ xuất phát từ France với ý định rất tốt. Chẳng hạn Semmle [1] đã được GitHub mua lại để phân tích tĩnh kho mã. Inria [2] cũng rất xuất sắc, nhưng vấn đề không phải là nghiên cứu, mà là làm thế nào để cạnh tranh ở cấp độ kinh doanh với các công ty kiểu Mỹ
      [1] https://en.wikipedia.org/wiki/Semmle
      [2] https://www.inria.fr/en
  • Họ đang dùng meme Drake trong README trên GitHub
    https://github.com/getlago/lago
    https://imgur.com/a/gsrhUXm
    Tôi không ngờ lại thấy tài liệu kỹ thuật bị meme hóa… trời ạ

    • Có cảm giác bạn mới vào ngành sau năm 2015. Ngay cả các phân tích rất kỹ thuật như Jepsen Reports, vốn đánh giá các tuyên bố kỹ thuật kiểu Cassandra DB, cũng chèn rất nhiều meme giữa nội dung kỹ thuật. Slide thuyết trình thì lúc nào cũng có ảnh mèo hoặc chó
    • Tài liệu kỹ thuật từ lâu đã có meme dưới nhiều hình thức khác nhau. Chúng vô hại và còn phát tín hiệu về trí tuệ/cảm xúc, nên tôi thấy vui. Cái gì cũng quá nghiêm túc không phải là điều hay
    • Nhưng thứ tự các khung bị sai thì hơi kỳ
    • Meme đã tồn tại trong tài liệu kỹ thuật từ lâu ngang với thời gian kỹ sư và tài liệu tồn tại
    • Bạn chưa từng tra cứu đệ quy trong K&R à? Tôi nhớ Google cũng từng tham gia trò đùa đó
  • Có ai biết giải pháp thay thế Stripe Payments thực sự không? Stripe không muốn làm việc với chúng tôi, và chỉ muốn làm với đối thủ nguồn đóng, nên chúng tôi bị kẹt với PayPal

    • Bạn có thể thử https://mollie.com
      Nhân tiện, tôi làm việc ở đó
    • Trên thị trường có nhiều lựa chọn. Tuy nhiên mỗi bên đều có ưu/nhược điểm, và API rất có thể khó xử lý hơn
  • Cái này không phải là lựa chọn thay thế Stripe
    Billing, hóa đơn, thanh toán, quyền truy cập, subscription đều là những thứ khác nhau

    • Thực ra chúng tôi đang bắt đầu từ billing, và về dài hạn có tầm nhìn trở thành một open revenue hub. Các bước lớn được tóm tắt ở đây: https://www.getlago.com/blog/lago-raises-22-millions
      Nghĩa là chúng tôi muốn cung cấp một lựa chọn mở thay thế cho toàn bộ RevOps. Thay vì bước vào một hệ sinh thái nguồn đóng như Stripe, chúng tôi muốn cho phép bạn xây dựng stack tùy chỉnh và gắn các công cụ long-tail, use case, hệ thống nội bộ theo cách tiếp cận “kết hợp những công cụ tốt nhất”. Stripe có 21 sản phẩm, và nhiều nhà sáng lập không nhận ra rằng họ không chỉ dùng “Stripe payments”, mà đang dùng 3–6 sản phẩm trong số đó, mỗi sản phẩm thường lấy một phần doanh thu
  • Họ đã gọi được 15M ở Series A, và định giá chưa được công bố nhưng có tin đồn là 100M
    Theo Crunchbase, 7M là vòng seed nhận được năm 2023. Nhìn vào đoạn cuối của bài được liên kết thì có vẻ họ không định thay thế toàn bộ Stripe. Dù sao đây cũng là một câu chuyện thú vị về một startup pivot thành công bắt đầu từ một bài HN đầy nhiệt huyết

    • Trước hết chúng tôi đang tập trung xây dựng một giải pháp thay thế Billing cho một trong các dịch vụ cốt lõi của Stripe. Đặc biệt là billing trong các mô hình tính phí kết hợp hoặc dựa trên mức sử dụng, những mảng mà Stripe còn yếu