Công khai mã nguồn startup của tôi sau khi thất bại sau 3 năm

 (dylanhuang.com)
3 điểm bởi GN⁺ 2024-12-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • Konfig khởi đầu là một startup công cụ dành cho nhà phát triển giúp việc tích hợp API trở nên dễ dàng hơn, nhưng đã đóng cửa sau 3 năm và công khai codebase chứa mã sản phẩm cùng các đầu ra vận hành
  • Sản phẩm cốt lõi là SDK Generator tạo thư viện client từ đặc tả OpenAPI, sau đó mở rộng sang công cụ tài liệu hóa và môi trường kiểm thử API tương tác
  • Dù có phản hồi từ một số khách hàng startup, công ty khó phát triển thành một doanh nghiệp tăng trưởng siêu tốc do độ khó trong ký hợp đồng và mức giá thấp
  • Sau đó công ty pivot sang sản phẩm AI vertical B2B SaaS, nhưng qua nhiều cuộc phỏng vấn và quy trình bán hàng vẫn không tìm được phản ứng thị trường (traction) đủ để tin rằng đây sẽ là một doanh nghiệp lớn
  • Kho lưu trữ công khai được mở nguyên trạng tại thời điểm đóng cửa, bao gồm mã sản phẩm, các thử nghiệm pivot, kịch bản bán hàng, cấu hình triển khai và website marketing mà không qua dọn dẹp hay chỉnh sửa

Công cụ phát triển API mà Konfig từng xây dựng

  • Konfig là một startup công cụ cho nhà phát triển API bắt đầu vào cuối năm 2022, tập trung vào việc đơn giản hóa cách các nhà phát triển làm việc với API
  • Mục tiêu là cải thiện việc tạo SDK, tài liệu hóa và các công cụ xung quanh kiểm thử
  • Sản phẩm chủ lực là SDK Generator
    • Nhận đặc tả OpenAPI làm đầu vào và tạo thư viện client cho nhiều ngôn ngữ lập trình
    • Sau đó mở rộng sang công cụ tài liệu hóa API và môi trường kiểm thử API tương tác

Giới hạn tăng trưởng và cú pivot sang AI

  • Có traction từ một số khách hàng startup, nhưng không thể dẫn tới một doanh nghiệp tăng trưởng siêu tốc
  • Rất khó ký hợp đồng với khách hàng tiềm năng, và dù có ROI có thể chứng minh được thì mức giá vẫn quá thấp
  • Sau sự phát triển của AI tạo sinh, công ty tin rằng có thể giải quyết những vấn đề trước đây khó xử lý nên đã pivot sang sản phẩm AI vertical B2B SaaS
  • Nhiều ý tưởng đã được đem ra phỏng vấn người dùng và bán hàng, nhưng không tìm thấy traction đủ mạnh để tạo niềm tin rằng đó là hướng đi dẫn tới một doanh nghiệp khổng lồ

Kho lưu trữ được công khai nguyên trạng tại thời điểm đóng cửa

  • Kho lưu trữ công khai là konfig-dev/konfig
  • Kho lưu trữ được công khai đúng nguyên trạng tại thời điểm công ty đóng cửa
    • Không dọn dẹp
    • Không trau chuốt
    • Không chỉnh sửa
    • Codebase cho thấy tình trạng mã startup thực tế, không qua lọc bỏ

Các sản phẩm chính được xây dựng trong 3 năm

Mã vận hành và các thử nghiệm cũng được công khai

Hồi tưởng của nhà sáng lập

  • Dylan Huang rời công việc vào tháng 3 năm 2022 để toàn tâm cho startup, và đã chấp nhận thử thách dù biết có khả năng thất bại
  • Anh xem thất bại lần này là một trải nghiệm dạy cho mình nhiều điều hơn cả thành công
  • Bước tiếp theo là khám phá những cơ hội mới, tìm vị trí phù hợp trên thị trường tuyển dụng và tiếp tục học hỏi, phát triển
  • Anh cũng để ngỏ khả năng một ngày nào đó sẽ снова tự mình xây dựng điều gì đó

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-18
Ý kiến trên Hacker News

  • Tôi tự hỏi nếu họ nhắm tới một doanh nghiệp nhỏ thay vì một “doanh nghiệp khổng lồ” “tăng trưởng siêu tốc”, thì đến giờ đã còn lại bao nhiêu sản phẩm ngách xuất sắc

    • Nói vậy thì dễ, nhưng khi thực sự làm thì rất khó, vì phải trụ gần như không lương trong 3–5 năm và kỳ vọng kết quả tương tự một doanh nghiệp đã gọi được vốn
      Ở các nước phát triển, để một startup 2–3 người sống sót thì phải bán được cực kỳ nhiều giấy phép 10 USD/tháng, và cũng phải tính cả chi phí cơ hội
    • Nếu nhận đầu tư để trang trải chi phí cần thiết hằng tháng, thì từ góc nhìn nhà đầu tư, phải có khả năng tăng trưởng siêu tốc thì bài toán danh mục mới hợp lý
      Nếu ngay từ đầu nhắm tới một doanh nghiệp nhỏ và bền vững rồi thành công thì có thể tránh gọi vốn, nhưng nếu đến giai đoạn giữa/cuối của công ty mới pivot sang một hướng hoàn toàn mới, thì nhiều khả năng đã đốt gần hết khoản dự phòng
    • Với kết quả như vậy, đi làm ở một công ty lớn để nhận mức đãi ngộ tương tự mà không chịu rủi ro nghe hợp lý hơn
    • Tôi cũng thắc mắc điểm này. Tôi là một trong 3 đồng sáng lập của một công ty bootstrap làm consulting ở khu vực chi phí sinh hoạt thấp; trong vài năm qua chúng tôi đã trả lương 50.000 USD/năm cho mỗi founder, và dù không đặc biệt may mắn hay có phán đoán kinh doanh xuất chúng, công ty vẫn đang làm khá tốt
      Doanh thu năm nay là 400.000 USD, lợi nhuận 150.000 USD, tăng trưởng 40%, và triển vọng kinh doanh cũng tốt hơn rất nhiều so với đầu năm. Chúng tôi kỳ vọng tiếp tục tăng trưởng mạnh vào năm sau, thị trường còn xa mới bão hòa nên vẫn còn dư địa tăng trưởng trong vài năm tới
      Cộng lương với 1/3 lợi nhuận thì năm nay là 100.000 USD, và với mức tăng trưởng 40% thì công ty cứ 2 năm lại tăng gấp đôi. Nếu thuận lợi, chỉ riêng lương và lợi nhuận đã khá ổn, thêm vào đó còn có cơ hội bán công ty để các founder kiếm được vài triệu USD
    • Ở đây tôi cảm thấy có hàm ý kiểu “Thấy chưa, tôi đã nói là khó mà!”
      Muốn xây một công ty như Google hay một công ty như Basecamp đều ổn, chỉ là hai loại công ty khác nhau
      Ngược lại, rất dễ đánh giá thấp rủi ro khi xây một “doanh nghiệp rủi ro thấp”, và mọi doanh nghiệp đều khó. Xin vỗ tay cho Konfig

  • Là khách hàng của Konfig, tôi thật sự thấy tiếc. Có lẽ chúng tôi là khách hàng đầu tiên, và hình như còn được nhắc tới trong các commit ban đầu
    Dylan và Anh-Tuan đã giải quyết rất xuất sắc nhiều vấn đề thực tế cho chúng tôi. Họ cung cấp SDK được sinh ra tự động cùng tài liệu/tutorial được host đẹp mắt ở cùng một nơi, và cho phép gọi API của chúng tôi để người dùng có thể thử nghiệm ngay với dữ liệu thật
    Trước Konfig, chúng tôi tự viết các SDK bọc quanh API một cách thủ công và lộn xộn; tài liệu thì host bằng ReadMe, nhưng do yêu cầu ký request của API nên phần tương tác không hoạt động tốt
    Nhờ Konfig công bố mã nguồn mở, hiện chúng tôi đang tự host tài liệu: https://docs.snaptrade.com/
    Tôi rất tôn trọng đội ngũ này, và ước gì họ đã tìm được cách nào đó để tiếp tục
    Nếu bạn đang vận hành một sản phẩm giống Konfig, được khách hàng yêu thích nhưng doanh thu không tăng đủ mức cần thiết, thì cũng đáng cân nhắc tăng giá cao hơn. Chúng tôi sẵn sàng trả gấp 2–3 lần mức Konfig tính, và khi tăng trưởng còn sẽ trả nhiều hơn, nhưng họ không yêu cầu; họ cũng không xây mô hình tính phí theo mức sử dụng như phí hằng tháng theo từng SDK hay hằng tháng theo từng demo

    • Tôi biết đến Konfig thông qua sản phẩm của bạn. Tài liệu quá tốt nên tôi không thể không tìm xem phía sau dùng gì, và nó thật sự tốt hơn Swagger hay Redoc
    • Tôi tò mò không biết các bạn đã thử dùng trực tiếp https://github.com/OpenAPITools/openapi-generator chưa
    • Nếu muốn một giải pháp thay thế tài liệu API gọn nhẹ, tôi khuyên dùng Scalar. Đơn giản, dễ dùng, nhưng tốt hơn tài liệu Swagger rất nhiều

  • Văn hóa startup ở Mỹ thật sự kỳ lạ. Không phải thứ gì cũng cần mở rộng siêu tốc, và không phải thứ gì cũng cần trở nên khổng lồ.
    Kinh doanh nên tập trung nhiều hơn vào tính bền vững, chứ không phải kiểu pivot ba lần trong 2–3 năm rồi đóng cửa.

    • Một mặt thì đúng, nhưng mặt khác, rất có thể chính sự tập trung ám ảnh vào “không scale cực lớn thì là thất bại” đã đẩy hệ sinh thái startup Mỹ lên vị thế hiện nay và là lý do nó đi trước phần còn lại của thế giới rất xa.
      Nếu nói với nhiều nhà sáng lập startup châu Âu rằng “sau 5 năm, công ty chững lại ở mức 15–20 nhân viên, có dòng tiền ổn định và trả cho bản thân 200.000–250.000 USD mỗi năm”, họ sẽ coi đó là một thành công lớn. Ở Mỹ, đặc biệt nếu đã nhận vốn VC, điều đó có thể bị xem là thất bại.
      Tôi từng nghe một nhà đầu tư mạo hiểm ở Silicon Valley nói thẳng rằng “nếu bạn coi việc bán công ty với giá 50 triệu USD là thành công thì mindset của bạn sai, và tôi không muốn làm việc cùng bạn.”
      Nếu không dám nhận những thử thách lớn và rủi ro lớn, mà hài lòng với thành công nhỏ và tăng trưởng ổn định, bạn sẽ không bao giờ nhận được phần thưởng lớn. Điều đó có thể lành mạnh hơn cho cá nhân, nhưng có thể không tốt cho toàn bộ nền kinh tế.
    • Những doanh nghiệp nhỏ có lợi nhuận, tức các công ty có vẻ nhàm chán với đội ngũ nhỏ và mục tiêu dài hạn, dường như ít khi lên trang nhất HN vì họ không đặt ra những mục tiêu lớn đến phi thực tế.
      Điều thú vị là văn hóa này chấp nhận lối nghĩ kiểu “di chuyển nhanh và phá vỡ mọi thứ”, nhưng có vẻ chủ yếu chỉ áp dụng trong ngành công nghệ. Việc một doanh nhân thất bại nhiều lần được gọi là “nhà sáng lập nối tiếp” cũng vậy; thật khó coi việc bán một công ty không bền vững là thành công.
      Nghĩ đến cảnh một người thất bại ở nhiều môn thể thao tự gọi mình là “vận động viên nối tiếp” thì khá buồn cười.
    • Vấn đề là ngay khi nhận vốn mạo hiểm, bạn sẽ bị đẩy về phía mở rộng siêu lớn.
      Nếu không nhận vốn VC, con đường đi đến trạng thái tự nuôi sống được sẽ khó hơn và lâu hơn rất nhiều, trừ khi bạn có thể tự tài trợ bằng cách làm tư vấn hay tương tự. Hình mẫu ở đây là 37 Signals, nhưng họ là công ty tạo ra Rails nên là một ngoại lệ rất lớn.
      Và ngay cả khi đạt đến điểm đó, một đối thủ đã nhận vốn VC vẫn có thể lao vào với quan hệ và tiền bạc tốt hơn rồi nghiền nát bạn.
    • Tôi đang ở châu Âu và làm việc tại một công ty gặp đúng những khó khăn tương tự.
      Chu kỳ bán hàng B2B cho doanh nghiệp lớn dài đến vô lý, còn mức giá có thể bán cho doanh nghiệp vừa và nhỏ thì không đủ.
      Dù chúng tôi mang lại giá trị và tiết kiệm thời gian cho khách hàng, việc giải thích giá trị đó luôn khó.
      Cỏ bên kia đồi luôn xanh hơn, nhưng nếu làm B2B mà trong nhiều năm phải lặp đi lặp lại cùng một nỗi vất vả để giữ đèn sáng, mỗi tháng lại có những cuộc trò chuyện tương tự với khách hàng khác nhau và mỗi năm phải giải thích y hệt 10 lần vì sao thứ này có giá trị, thì tôi cũng hiểu vì sao người ta không muốn mắc kẹt trong đó. Burnout cũng có thể đến rất nhanh.
      Vì vậy tôi cũng hiểu mong muốn tìm một ý tưởng kinh doanh có giá trị rõ ràng đến mức mọi người hét lên “cầm tiền của tôi đi”.
    • Có một vài yếu tố khiến các công ty phương Tây chuộng mở rộng theo chiều dọc hơn là theo chiều ngang.
      Thứ nhất là ROI. Khi kéo tiền của người khác vào, tất nhiên họ kỳ vọng lợi nhuận; nhà đầu tư khôn ngoan sẽ đa dạng hóa danh mục nên họ biết nhiều khoản đầu tư sẽ thất bại. Vì vậy, để bù đắp thua lỗ, họ gây áp lực để mọi khoản đầu tư tăng trưởng lớn nhất có thể, để một số ít công ty đạt hiệu suất vượt trội bù cho các thất bại.
      Kiểu tăng trưởng theo chiều dọc này không chỉ thấy ở startup mà cả ở doanh nghiệp lớn. Tôi cho rằng chủ nghĩa hình thức, quy định quá mức và quan liêu đóng vai trò lớn ở đây. Nếu phải đi qua vô số thủ tục như giấy phép, thuế, thiết lập tài khoản lương, và muốn niêm yết còn phải làm thêm nhiều thủ tục nữa, thì việc mở rộng phạm vi hoạt động của một công ty đã có chỗ đứng có thể rẻ hơn và ít rủi ro hơn rất nhiều so với tách ra lập công ty mới.

  • Có lẽ chúng tôi từng là đối thủ. Tôi là nhà sáng lập ReadMe.com, và chúng tôi cung cấp tài liệu API, SDK, v.v.
    Tôi không rõ cụ thể vì sao chúng tôi thành công, nhưng bản thân tôi cũng đã trải qua vô số khởi đầu sai, rồi lặp đi lặp lại cải tiến ý tưởng cốt lõi từng chút một cho đến khi chạm tới điểm khiến mọi người phấn khích rõ rệt.
    Vì biết thị trường này khó, tôi đã dành rất nhiều thời gian và công sức cho những việc không phải engineering; đặc biệt, mỗi khi chúng tôi thể hiện một cách chân thật hơn, Hacker News luôn đối xử rất thiện chí với chúng tôi.
    Tôi định liên hệ riêng để nghe thêm.
    Nhìn chung, xin chúc mừng vì tất cả nỗ lực đã bỏ ra. Bắt đầu một công ty và tin vào chính mình là việc cực kỳ khó, và bạn có quyền tự hào.

    • Lý do ReadMe thành công hơn Konfig có thể là vì bắt đầu sớm hơn 8 năm. Konfig là một ý tưởng hay và triển khai cũng tốt, nhưng có thể đơn giản là timing không phù hợp.
    • Nhân tiện, hiệu ứng chuyển tiếp CSS trên màn hình đăng nhập của ReadMe vẫn là một trong những yếu tố branding mạnh nhất mà tôi nhớ được. Dù ai nghĩ ra nó thì cũng thật sự xuất sắc.

  • Tôi nghĩ trong tương lai gần chúng ta sẽ thấy kết quả này rất nhiều. Khi bong bóng AI xì hơi, những chuyện tương tự có lẽ sẽ lặp lại.

    • Nếu viết như thế này thì tôi có lẽ đã tôn trọng nỗ lực đó hơn:
      “Chúng tôi tin rằng có thể tận dụng generative AI trong sản phẩm vertical B2B SaaS để giải quyết những vấn đề trước đây chưa giải được, nên đã thử. Chúng tôi tạo ra và đề xuất nhiều ý tưởng, nhưng phản ứng của người dùng không đủ tích cực để khiến chúng tôi tin chắc rằng đó là hướng đúng để xây dựng một doanh nghiệp lớn.”
      Giữ nguyên như bản gốc thì ấn tượng đầu tiên là: “người viết bài này chìm quá sâu trong một văn hóa trào lưu nhất thời và hẹp đến mức gây phản cảm theo bản năng, và ngay cả sau khi thất bại hoàn toàn vẫn chưa thoát ra khỏi đó về mặt tâm lý.”
    • Mở mã nguồn code rồi bỏ cuộc là AI pivot tối thượng. Vì các model mới sẽ học từ những gì bạn đã làm và một ngày nào đó làm tốt hơn.

  • Đây không phải lần đầu có câu chuyện một sản phẩm chưa thật khớp cố tìm hướng pivot, chọn AI làm câu trả lời rồi thất bại.
    Tôi đã nói trước đây nhưng đáng để nhắc lại. Khi hiểu AI làm tốt điều gì và không làm tốt điều gì, chúng ta sẽ bắt đầu coi AI là công cụ chứ không phải mục tiêu, và việc nghĩ ra ý tưởng sản phẩm cũng sẽ ổn định hơn.

    • Chúng ta đã biết rồi. AI giỏi bịa ra những nội dung nghe có vẻ hợp lý, nhưng yếu trong việc tạo ra kết quả chịu được sự thật hoặc kiểm chứng.
    • Bản thân sản phẩm thì ổn. Tôi từng ở một startup sẵn sàng trả tiền và nhận được nhiều giá trị từ sản phẩm tạo SDK từ đặc tả OpenAPI đó.
      Vì vậy tôi cho rằng vấn đề ở đây không phải là product-market fit.
    • Ý là AI không thể tự động hóa thứ gì đó để cứu một ý tưởng sản phẩm tệ sao? Kiểu làm hiệu quả hơn một việc mà không ai muốn thì không phải là kinh doanh.
    • Khái niệm API nên biến mất, và cứ để các AI nói chuyện với nhau bằng ngôn ngữ tự nhiên là được.

  • Không rõ nên nhìn nhận chuyện này như thế nào. Một mặt, tôi hoan nghênh sự tự phản tỉnh, việc đối diện với những sự thật khó chịu, và việc họ đã tạo ra một bộ công cụ khá rộng
    Nhưng nhìn vào bên trong thì đây là công cụ bọc quanh công cụ. Công cụ phân loại API có vẻ chuyển phần lớn công việc nặng sang OpenAI
    “Bạn là bộ phân loại đẳng cấp thế giới. Hãy xếp các API này vào một trong các nhóm này.”
    Phần còn lại là mã nối dây và ranh giới giữa model·view·controller hơi bị mờ. Tôi cũng thấy có test, và nghĩ rằng điều đó sẽ quan trọng khi bọc các công cụ có nhiều thay đổi ngoài tầm kiểm soát, nhưng thực tế chỉ ở mức kiểm tra xem có phụ thuộc và biên dịch không lỗi hay không, giống như test chức năng contextLoads() mà IntelliJ cung cấp mặc định
    Có tầm nhìn và cũng phù hợp với quy luật Pareto, nhưng trong lúc kiểm chứng giả thuyết rằng thị trường không quan tâm đến việc bảo trì thứ của họ, cảm giác là nội bộ chính họ cũng chưa giải quyết được vấn đề bảo trì của mình
    Nếu họ có thể tự giải quyết lý do đó trước, họ có lẽ đã có thể giải quyết cho người khác; nhưng để làm vậy lại cần có một sản phẩm được dùng thực tế để cảm nhận nỗi đau và đồng cảm với người dùng cuối — trông như một nghịch lý

  • Một startup thất bại không phải là điều đáng xấu hổ. Phần lớn chúng ta thậm chí không có can đảm để thử
    Khó kỳ vọng mã nguồn sẽ được quan tâm nhiều. Giá trị của mã từ một công ty thiếu phần kinh doanh và con người, nếu không có vũ khí bí mật đặc biệt về kỹ thuật, là khá tiêu cực
    Ngay cả khi có phần nào đó xuất sắc về kỹ thuật, nhiều khả năng mọi người chỉ cố hiểu riêng phần đó hoạt động thế nào, chứ không dùng chính mã nguồn

    • Tôi là nhà sáng lập Konfig. Đồng ý 100%. Tôi sẽ không khuyên ai tự giải mã Konfig rồi triển khai nó
      Tuy vậy, một khách hàng đã triển khai thành công nền tảng tài liệu của chúng tôi trong hạ tầng của họ, trong lúc tìm cách xử lý hệ quả của việc Konfig đóng cửa
    • Điều tôi đã học được một cách khó khăn sau vài lần làm các startup ngày càng ít thất bại hơn là như sau
      Đừng lập startup công nghệ nếu bạn không có kế hoạch kinh doanh tạo doanh thu nhanh hoặc một khoản đầu tư khổng lồ. Thường thì nếu không có tối thiểu cảm nhận về việc doanh nghiệp sẽ đi về đâu, bạn cũng khó gọi vốn; còn dân kỹ thuật nhìn chung không hiểu đủ khía cạnh kinh doanh
      Phần lớn công ty không phải startup, mà chỉ là công ty. Họ có doanh thu và trả hóa đơn. Startup là công ty sống bằng thời gian và tiền đi vay khi chưa có doanh thu; đặc biệt nếu đó là tiền của chính bạn thì cần có kế hoạch
      Phần lớn công ty nhận vốn mạo hiểm đều thất bại. Công việc của quỹ đầu tư mạo hiểm là khiến các công ty sẽ thất bại thất bại thật nhanh, và duy trì hoạt động của chính họ bằng số ít công ty không thất bại mà tăng trưởng bùng nổ. “Tăng tốc” hay “gọi vốn” không có nghĩa là bạn đang trên con đường thành công, mà là bạn đã bước lên một vị trí phải thắng xác suất và không còn nhiều thời gian
      Nếu là công ty thành công có doanh thu, bạn không cần vốn mạo hiểm. Khi đó nên tự hỏi tại sao mình lại nói chuyện với họ. Nếu việc tạo doanh thu là khó, vốn mạo hiểm không sửa được điều đó
      Nhiều quỹ đầu tư mạo hiểm lười biếng và chỉ quan tâm sau khi bạn đã thành công. Vì vậy nảy sinh một động lực kỳ lạ: công ty nhận vốn sớm thì thất bại, còn công ty không nhận được vốn lại thành công
      Công ty hiện tại đã vận hành hoàn toàn bootstrap sang năm thứ 4. Chúng tôi vật lộn với doanh thu, nhét việc vào mọi khoảng thời gian có thể, còn tôi chủ yếu sống bằng tư vấn bên lề. Công ty đã có 3 năm liên tiếp là những năm thành công nhất, và sắp đến mức tôi có thể ngừng làm tư vấn để tập trung vào doanh nghiệp, nhưng đó là một hành trình dài
      Về mã nguồn mở, những gì không phải mã đặc thù cho doanh nghiệp hay tài sản trí tuệ cốt lõi thì tôi công khai. Một lý do lớn là tôi không muốn phải tạo lại cùng những việc lặt vặt khi bắt đầu công ty tiếp theo. Tôi đã trải qua việc những thứ đó làm chậm mình như thế nào
      Nhiều người trong startup ám ảnh với tài sản trí tuệ, nhưng trên thực tế phần lớn phần mềm không có giá trị đến vậy. Dù thế, để tạo ra nó vẫn tốn thời gian, tiền bạc và năng lượng
      Vì vậy tôi công khai nhiều công cụ, framework, v.v. mà chính tôi sẽ là người dùng chính. Để tiếp tục dùng chúng trong các dự án sau

  • Bản dump mã nguồn tự nó có thể thú vị, nhưng có vẻ chưa gắn giấy phép. Nếu gắn một giấy phép mã nguồn mở đúng cách thì sẽ hữu ích hơn nhiều

    • Khoảng một giờ sau bình luận, tệp MIT LICENSE đã được thêm vào

  • Thị trường công cụ cho lập trình viên thật sự khó
    Gần như mọi quyết định kiến trúc đều trở thành “có thể dùng công cụ mã nguồn mở nào để giải quyết vấn đề này?”
    Không ai muốn trả tiền, và điều đó cũng ổn

    • Đúng là vậy, nhưng phần lớn lập trình viên hầu như không nhận ra các vấn đề ngoài vấn đề họ đang gặp, và các vấn đề đó thường là vấn đề về công cụ cho lập trình viên
      Vì thế, dù ở các lĩnh vực khác có nhu cầu rất lớn, lại có nhiều công ty tạo startup công cụ cho lập trình viên
      Nếu các lập trình viên giàu kinh nghiệm muốn bắt đầu điều gì đó có một cách để tìm ra những người có vấn đề, chuyên môn miền và ý chí khởi nghiệp — ngoài tình cờ và networking — thì có lẽ sẽ mở khóa được rất nhiều giá trị
    • Bán công cụ cho lập trình viên là khó. Bạn phải cạnh tranh với vô số công cụ mã nguồn mở liên tục thích nghi và thay đổi, còn ý tưởng hay thì nhanh chóng bị hấp thụ và sao chép
      Vì vậy phần lớn công cụ thương mại có vòng đời hữu dụng hạn chế, và nhìn chung chỉ dừng ở mức “có thì tốt”
      Ngoài ra nhiều lập trình viên là người làm thuê và không có ngân sách cá nhân cho công cụ. Thị trường thực chất bị thu hẹp vào các lập trình viên tự do hoặc các quản lý thuê lập trình viên
      Các quản lý đội nhóm xem xét các khoản chi này rất kỹ và thường cũng không có nhiều ngân sách. Ở phần lớn công ty, không tồn tại thứ gọi là ngân sách công cụ cá nhân cho lập trình viên
      Freelancer nhìn chung cũng dùng công cụ mà công ty trả tiền cho họ đang dùng, và phần lớn là công cụ miễn phí. Công cụ trả phí còn phải lo cả giấy phép cho nhà thầu, khiến việc dùng freelancer trở nên phức tạp hơn. Vì vậy họ có xu hướng tránh các công cụ như vậy để giữ mọi thứ đơn giản
    • Xa hơn nữa, công cụ cho lập trình viên khó đến mức dễ bị hiểu nhầm. Việc làm công cụ cho lập trình viên rất dễ trông như công thức chiến thắng cho một công ty hay startup. Vì chính bạn cũng là lập trình viên, và rất có thể đã phát hiện một vấn đề mình từng trực tiếp gặp trong quá khứ
      Bạn cũng biết lập trình viên tụ tập ở đâu và thứ gì có hiệu quả với họ, nên mọi thứ trông đều ổn
      Nhưng như đã nói, nhiều lập trình viên không muốn trả tiền, và sẽ tìm một giải pháp mã nguồn mở làm được việc cần làm dù kém tiện hơn một chút. Hơn nữa, vì đối tượng là những người mà công việc và cuộc sống là tạo ra phần mềm, câu trả lời cũng có thể trở thành “thôi tự mình làm”
    • Không hoàn toàn đúng. Chỉ là tôi không muốn lãng phí thời gian để xử lý 50 hóa đơn 10 đô la
      Không có doanh nghiệp nào gom nhiều dịch vụ vào một hóa đơn à? Hay vẫn phải dùng AWS, Azure, GCloud?