เปิดโค้ดสตาร์ทอัพของผมที่ล้มเหลวหลังผ่านไป 3 ปี
(dylanhuang.com)- Konfig เริ่มต้นในฐานะ สตาร์ทอัพเครื่องมือสำหรับนักพัฒนา ที่ช่วยให้การผสานรวม API ง่ายขึ้น แต่หลังจาก 3 ปีก็ปิดตัวลง และเปิดเผย codebase ที่มีทั้งโค้ดผลิตภัณฑ์และผลงานด้านการดำเนินงาน
- ผลิตภัณฑ์หลักคือ SDK Generator ที่สร้างไลบรารีไคลเอนต์จากสเปก OpenAPI และต่อมาขยายไปถึงเอกสารและสภาพแวดล้อมทดสอบ API แบบโต้ตอบ
- แม้มีการตอบรับจากลูกค้าสตาร์ทอัพบางราย แต่ด้วยความยากในการปิดสัญญาและระดับราคาที่ต่ำ จึงยากที่จะขยายให้เป็น ธุรกิจที่เติบโตเร็วมาก ได้
- ต่อมาได้ pivot ไปเป็นผลิตภัณฑ์ AI แบบ vertical B2B SaaS แต่แม้จะผ่านการสัมภาษณ์และกระบวนการขายหลายครั้ง ก็ยังไม่พบ แรงส่งจากตลาด (traction) ที่ทำให้มั่นใจได้ว่าจะเป็นธุรกิจขนาดใหญ่
- repository ที่เปิดเผยเป็นสภาพ ณ เวลาปิดบริษัทตามเดิม โดยไม่มีการจัดระเบียบหรือแก้ไข และรวมทั้งโค้ดผลิตภัณฑ์ การทดลอง pivot สคริปต์ขาย การตั้งค่าการ deploy และเว็บไซต์การตลาด
เครื่องมือสำหรับนักพัฒนา API ที่ Konfig กำลังสร้าง
- Konfig เป็น สตาร์ทอัพเครื่องมือสำหรับนักพัฒนา API ที่เริ่มต้นปลายปี 2022 โดยมุ่งทำให้วิธีที่นักพัฒนาจัดการกับ API ง่ายขึ้น
- เป้าหมายคือปรับปรุงเครื่องมือรอบ ๆ การสร้าง SDK การทำเอกสาร และการทดสอบ
- ผลิตภัณฑ์หลักคือ SDK Generator
- รับสเปก OpenAPI เป็นอินพุต แล้วสร้างไลบรารีไคลเอนต์สำหรับหลายภาษาโปรแกรมมิ่ง
- ต่อมาขยายไปเป็นเครื่องมือทำเอกสาร API และสภาพแวดล้อมทดสอบ API แบบโต้ตอบ
ข้อจำกัดในการเติบโตและการ pivot ไปสู่ AI
- มี traction จากลูกค้าสตาร์ทอัพบางราย แต่ไม่สามารถต่อยอดเป็น ธุรกิจที่เติบโตเร็วมาก ได้
- การปิดสัญญากับลูกค้าเป้าหมายทำได้ยาก และแม้จะมี ROI ที่พิสูจน์ได้ ระดับราคาก็ยังต่ำเกินไป
- หลังการพัฒนาของ generative AI จึงมองว่าสามารถแก้ปัญหาที่ก่อนหน้านี้แก้ได้ยาก และ pivot ไปเป็น ผลิตภัณฑ์ AI แบบ vertical B2B SaaS
- ได้ทำการสัมภาษณ์ผู้ใช้และขายสำหรับหลายไอเดีย แต่ไม่พบ traction ที่มากพอจะทำให้มั่นใจว่าเป็นทิศทางที่จะต่อยอดเป็นธุรกิจขนาดใหญ่
repository ที่เปิดเผยตามสภาพ ณ วันที่ปิดตัว
- repository สาธารณะคือ konfig-dev/konfig
- repository ถูกเปิดเผยตามสภาพ ณ เวลาที่บริษัทปิดตัว
- ไม่มีการจัดระเบียบ
- ไม่มีการขัดเกลา
- ไม่มีการแก้ไข
- codebase แสดงสภาพโค้ดของสตาร์ทอัพจริงที่ไม่ได้ถูกกรอง
ผลิตภัณฑ์หลักที่สร้างตลอด 3 ปี
- SDK Generator: ตัวสร้าง SDK บนฐาน OpenAPI
- Markdown and OpenAPI Documentation: เอกสารบนฐาน Markdown และ OpenAPI
- API Demos (Markdown Based Jupyter Notebooks): เดโม API ในรูปแบบ Jupyter Notebook บนฐาน Markdown
- SDKs for Public APIs: ชุด SDK สำหรับ API สาธารณะ
โค้ดดำเนินงานและการทดลองที่เปิดเผยด้วย
- รวมโค้ดที่เกี่ยวข้องกับการขายและการตลาดด้วย
- Shell script for generating cold outbound message: เชลล์สคริปต์สำหรับสร้างข้อความ cold outbound
- Programmatic SEO Scripting: สคริปต์ programmatic SEO
- Marketing website: เว็บไซต์การตลาด
- ยังมีผลงานที่เกี่ยวข้องกับลูกค้าและการขายหลงเหลืออยู่
- References to live customer deployments and pre-sales artifacts: การอ้างอิงถึงการ deploy ของลูกค้าจริงและผลงาน pre-sales
- Custom Notion Database Integration: การผสานรวมฐานข้อมูล Notion แบบกำหนดเอง
- สามารถตรวจดูการดำเนินงานผลิตภัณฑ์และเครื่องมือพัฒนาได้ด้วย
- Product Documentation: เอกสารผลิตภัณฑ์
- Modified Changeset Bot: Changeset Bot ที่ถูกแก้ไขเพื่อรองรับการตั้งค่า monorepo แบบกำหนดเอง
- SDK Generator Integration Tests using Earthly: การทดสอบ integration ของ SDK Generator โดยใช้ Earthly
- Python Code Formatting Service: บริการจัดรูปแบบโค้ด Python
- render.com deployment configuration: การตั้งค่า deploy
render.yaml
- การ pivot ไป AI และการทดลองอื่น ๆ ก็อยู่ใน repository ด้วย
- AI Pivot Experimentation: การทดลอง pivot ไป AI
- API Documentation Generator Tool using LLMs/HTMX/Django: เครื่องมือสร้างเอกสาร API โดยใช้ LLM, HTMX, Django
- Python script for cropping blog post images: สคริปต์ Python สำหรับครอปรูปภาพบทความบล็อก
บันทึกย้อนคิดจากผู้ก่อตั้ง
- Dylan Huang ออกจากงานในเดือนมีนาคม 2022 เพื่อทุ่มเทให้สตาร์ทอัพ และลงมือทำแม้รู้ว่ามีโอกาสล้มเหลว
- เขามองความล้มเหลวครั้งนี้เป็นประสบการณ์ที่สอนสิ่งต่าง ๆ มากกว่าความสำเร็จ
- ขั้นต่อไปคือการสำรวจโอกาสใหม่ ๆ มองหาตำแหน่งที่เหมาะในตลาดงาน และเรียนรู้กับเติบโตต่อไป
- ยังเปิดโอกาสไว้สำหรับการกลับมาท้าทายตัวเองด้วยการสร้างอะไรสักอย่างด้วยตัวเองอีกครั้งในสักวันหนึ่ง
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ถ้าตั้งเป้าเป็น ธุรกิจขนาดเล็ก แทน “ธุรกิจขนาดใหญ่” ที่ “เติบโตแบบพุ่งแรง” ไม่รู้ว่าตอนนี้คงมีผลิตภัณฑ์เฉพาะกลุ่มดี ๆ เหลืออยู่มากแค่ไหน
ในประเทศพัฒนาแล้ว สตาร์ทอัพ 2–3 คนจะอยู่รอดได้ต้องขายไลเซนส์เดือนละ 10 ดอลลาร์ให้ได้จำนวนมหาศาล และยังต้องคิดถึงต้นทุนค่าเสียโอกาสด้วย
ถ้าตั้งเป้าตั้งแต่แรกให้เป็นธุรกิจเล็ก ๆ ที่ยั่งยืนแล้วสำเร็จ ก็หลีกเลี่ยงการลงทุนได้ แต่ถ้าในช่วงกลางถึงท้ายของบริษัทเพิ่ง pivot ไปทิศทางใหม่โดยสิ้นเชิง ก็มีโอกาสสูงว่าเผาเงินสำรองไปเกือบหมดแล้ว
ปีนี้รายได้อยู่ที่ 400,000 ดอลลาร์ กำไร 150,000 ดอลลาร์ อัตราการเติบโต 40% และแนวโน้มการขายก็ดีกว่าต้นปีมาก ปีหน้าคาดว่าจะโตแรงต่อ และยังห่างไกลจากภาวะตลาดอิ่มตัว จึงยังมีพื้นที่ให้เติบโตได้อีกหลายปี
ถ้ารวมเงินเดือนกับ 1/3 ของกำไร ปีนี้ก็เท่ากับ 100,000 ดอลลาร์ และถ้าโต 40% บริษัทจะโตเป็นสองเท่าทุก 2 ปี ถ้าเป็นไปได้ด้วยดี แค่เงินเดือนกับกำไรก็ดีมากแล้ว แถมยังมีโอกาสขายกิจการที่ทำให้ผู้ก่อตั้งได้เงินหลายล้านดอลลาร์อีกด้วย
การพยายามสร้าง บริษัทแบบ Google กับการพยายามสร้างบริษัทแบบ Basecamp ทั้งสองแบบก็ใช้ได้ แค่เป็นบริษัทคนละประเภทกัน
กลับกัน การประเมินความเสี่ยงของการสร้าง “ธุรกิจความเสี่ยงต่ำ” ต่ำเกินไปก็ทำได้ง่าย และทุกธุรกิจล้วนยาก ขอปรบมือให้ Konfig
ในฐานะลูกค้าของ Konfig เสียดายมาก เราอาจเป็นลูกค้ารายแรกก็ได้ และเหมือนจะถูกพูดถึงใน commit แรก ๆ ด้วย
Dylan กับ Anh-Tuan ช่วยแก้ปัญหาจริงหลายอย่างให้เราได้ยอดเยี่ยมมาก พวกเขาให้ SDK ที่สร้างขึ้นมา พร้อมเอกสาร/บทเรียนที่โฮสต์ไว้สวยงามในที่เดียว และทำให้ผู้ใช้เรียก API ของเราเพื่อทดลองกับข้อมูลจริงได้ทันที
ก่อนมี Konfig เราเขียน SDK ที่ครอบ API ด้วยมือแบบไม่เป็นระบบ และโฮสต์เอกสารไว้บน ReadMe แต่เพราะข้อกำหนดเรื่องการลงนามคำขอของ API เรา มันจึงทำงานแบบอินเทอร์แอคทีฟได้ไม่ดี
เพราะ Konfig เปิดเป็นโอเพนซอร์ส ตอนนี้เราจึงโฮสต์เอกสารเองได้แล้ว: https://docs.snaptrade.com/
ผมนับถือทีมนี้มากจริง ๆ และคิดว่าน่าจะดีถ้าพวกเขาหาวิธีไปต่อได้ไม่ทางใดก็ทางหนึ่ง
ถ้าคุณกำลังทำผลิตภัณฑ์ที่ลูกค้าชอบเหมือน Konfig แต่รายได้ไม่โตเท่าที่จำเป็น การพิจารณา ขึ้นราคาให้สูงขึ้น ก็น่าลอง เราคงยอมจ่าย 2–3 เท่าของที่ Konfig เรียกเก็บ และเมื่อเราเติบโตก็คงจ่ายมากขึ้นอีก แต่พวกเขาไม่เคยขอ และไม่ได้ทำการคิดเงินตามการใช้งานอย่างค่ารายเดือนต่อ SDK หรือค่ารายเดือนต่อเดโมด้วย
วัฒนธรรมสตาร์ทอัพอเมริกันนี่แปลกจริง ๆ ไม่ใช่ทุกอย่างจำเป็นต้องขยายตัวด้วยความเร็วสูงสุด และไม่ใช่ทุกอย่างจำเป็นต้องยิ่งใหญ่
ธุรกิจควรโฟกัสที่ ความยั่งยืน มากกว่า ไม่ใช่ทำแบบ pivot สามครั้งใน 2–3 ปีแล้วปิดบริษัท
ถ้าบอกผู้ก่อตั้งสตาร์ทอัพในยุโรปจำนวนมากว่า “อีก 5 ปีบริษัทจะนิ่งอยู่ที่พนักงาน 15–20 คน มีกระแสเงินสดที่มั่นคง และจ่ายเงินให้ตัวเองปีละ 200,000–250,000 ดอลลาร์” พวกเขาคงมองว่าเป็นความสำเร็จครั้งใหญ่ แต่ในสหรัฐฯ โดยเฉพาะถ้ารับเงิน VC มาแล้ว อาจถูกมองว่าเป็นความล้มเหลว
ผมเคยได้ยินนักลงทุน VC ในซิลิคอนแวลลีย์พูดตรง ๆ ว่า “ถ้าคุณมองว่าการขายบริษัทในราคา 50 ล้านดอลลาร์เป็นความสำเร็จ แปลว่า mindset ของคุณผิด และผมไม่อยากทำงานด้วย”
ถ้าพอใจกับความสำเร็จเล็ก ๆ และการเติบโตที่มั่นคง โดยไม่ท้าทายใหญ่และไม่ยอมรับความเสี่ยงใหญ่ ก็ไม่มีทางได้รางวัลใหญ่ สำหรับตัวบุคคลอาจดีต่อสุขภาพใจกว่า แต่ต่อ เศรษฐกิจโดยรวม อาจเป็นผลเสีย
น่าสนใจที่วัฒนธรรมนี้ยอมรับแนวคิดแบบ “move fast and break things” ซึ่งดูเหมือนจะใช้กับวงการเทคโนโลยีเป็นหลัก รวมถึงการที่นักธุรกิจที่ล้มเหลวมาหลายครั้งถูกเรียกว่า “serial entrepreneur” ด้วย และคงยากจะมองว่าการขายบริษัทที่ไม่ยั่งยืนเป็นความสำเร็จ
ลองคิดดูว่าถ้าคนที่ล้มเหลวในกีฬาหลายชนิดเรียกตัวเองว่า “serial athlete” จะให้ความรู้สึกยังไง ก็ตลกดี
ถ้าไม่รับเงิน VC เส้นทางไปสู่จุดที่ยืนได้ด้วยตัวเองจะยากและยาวกว่ามาก เว้นแต่จะหาเงินเลี้ยงตัวเองได้ด้วยวิธีอย่าง consulting โมเดลในที่นี้คือ 37 Signals แต่พวกเขาเป็นบริษัทที่สร้าง Rails จึงเป็นกรณีพิเศษมาก
และแม้จะไปถึงจุดนั้นแล้ว คู่แข่งที่รับเงิน VC ก็อาจบุกเข้ามาด้วยคอนเนกชันและเงินทุนที่ดีกว่า แล้วเหยียบคุณจนแบนได้
วงจรการขาย B2B ให้บริษัทใหญ่ยาวอย่างไร้เหตุผล และระดับราคาที่ขายให้ SME ได้ก็ไม่พอ
แม้เราจะส่งมอบคุณค่าและช่วยประหยัดเวลาลูกค้าได้ แต่การอธิบายคุณค่านั้นยากเสมอ
ของคนอื่นมักดูดีกว่าเสมอ แต่ถ้าการทำธุรกิจ B2B หมายถึงต้องทนลำบากซ้ำ ๆ เพื่อให้ยังเปิดไฟอยู่ได้เป็นเวลาหลายปี ต้องคุยเรื่องคล้าย ๆ กันกับลูกค้าคนละรายทุกเดือน และต้องอธิบายซ้ำ ๆ ปีละ 10 ครั้งว่าทำไมมันถึงมีคุณค่า ก็เข้าใจได้ว่าทำไมคนถึงไม่อยากติดอยู่ในนั้น burnout ก็มาได้เร็วเช่นกัน
ดังนั้นจึงเข้าใจได้ว่าทำไมผู้คนถึงอยากหาไอเดียธุรกิจที่คุณค่าชัดเจนและคนตะโกนว่า “เอาเงินฉันไป”
อย่างแรกคือผลตอบแทนจากการลงทุน ถ้าจะดึงเงินคนอื่นเข้ามา คนเหล่านั้นย่อมคาดหวังผลตอบแทน และนักลงทุนที่ฉลาดจะกระจายพอร์ต จึงรู้ว่าการลงทุนจำนวนมากจะล้มเหลว ดังนั้นเพื่อชดเชยการขาดทุน พวกเขาจึงกดดันให้ทุกบริษัทที่ลงทุนเติบโตให้ใหญ่ที่สุดเท่าที่เป็นไปได้ และให้บริษัทที่ทำผลงานระดับสุดยอดเพียงไม่กี่รายมาชดเชยความล้มเหลว
การเติบโตแนวตั้งแบบนี้ไม่ได้เห็นเฉพาะในสตาร์ทอัพ แต่ยังเห็นในบริษัทใหญ่ด้วย ผมคิดว่าพิธีรีตอง กฎระเบียบที่มากเกินไป และระบบราชการมีบทบาทมากในเรื่องนี้ ถ้าต้องผ่านขั้นตอนมากมายอย่างใบอนุญาต การตั้งค่าบัญชีภาษีและเงินเดือน และถ้าจะเข้าตลาดหลักทรัพย์ก็ต้องผ่านขั้นตอนมากกว่านั้นอีก การขยายขอบเขตกิจกรรมของบริษัทที่ตั้งมั่นอยู่แล้วอาจถูกกว่าและเสี่ยงน้อยกว่าการแยกออกมาตั้งบริษัทใหม่มาก
น่าจะเคยเป็นคู่แข่งกัน ผมเป็นผู้ก่อตั้ง ReadMe.com และเรามีเอกสาร API กับ SDK ฯลฯ
ผมไม่แน่ใจนักว่าทำไมเราถึงประสบความสำเร็จ แต่ผมเองก็ผ่านการเริ่มต้นผิดทางมามากมาย และค่อย ๆ iterate ปรับปรุงไอเดียหลักทีละน้อยจนไปถึงจุดที่ผู้คนตื่นเต้นอย่างเห็นได้ชัด
เพราะรู้ว่าตลาดนี้ยาก ผมจึงทุ่มเวลาและแรงไปกับงานที่ไม่ใช่วิศวกรรมมากมายด้วย และโดยเฉพาะเมื่อเราเปิดเผยตัวตนอย่างตรงไปตรงมามากขึ้น Hacker News ก็เป็นมิตรกับเราเสมอ
อยากฟังเพิ่มเติม เลยจะติดต่อไปเป็นการส่วนตัว
โดยรวมแล้ว ขอแสดงความยินดีกับความพยายามทั้งหมดที่ทุ่มลงไป การเริ่มบริษัทและเชื่อมั่นในตัวเองเป็นเรื่องยากอย่างมหาศาล และคุณควรภูมิใจได้
ผมคิดว่าเราจะได้เห็นผลลัพธ์แบบนี้อีกมากในอนาคตอันใกล้ เมื่อ ฟองสบู่ AI แตก เรื่องคล้าย ๆ กันคงเกิดซ้ำ
“เราเห็นว่าการนำ generative AI มาใช้กับผลิตภัณฑ์ B2B SaaS แนวตั้งอาจช่วยแก้ปัญหาที่ก่อนหน้านี้แก้ไม่ได้ จึงลองทำ เราสร้างและเสนอไอเดียหลายอย่าง แต่ปฏิกิริยาของผู้ใช้ไม่ได้เป็นบวกพอจะทำให้มั่นใจว่านี่คือทิศทางที่ถูกต้องสำหรับการสร้างธุรกิจขนาดใหญ่”
ถ้าตามต้นฉบับเป๊ะ ๆ ความประทับใจแรกคือ “คนเขียนบทความนี้ฝังตัวอยู่ลึกในวัฒนธรรมกระแสชั่วคราวและแคบมากจนรู้สึกต่อต้านโดยสัญชาตญาณ และแม้เพิ่งล้มเหลวอย่างสิ้นเชิงก็ยังไม่สามารถหลุดออกจากมันในเชิงจิตวิทยาได้”
เรื่องผลิตภัณฑ์ที่ยังไม่ลงตัวพยายามหาแนวทาง pivot แล้วเลือก AI เป็นคำตอบจนล้มเหลว ไม่ใช่เรื่องแรก
เคยพูดไปแล้ว แต่ควรค่าแก่การย้ำ เมื่อเรารู้ว่า AI ทำอะไรได้ดีและทำอะไรไม่ได้ดี เราจะเริ่มปฏิบัติกับ AI ในฐานะ เครื่องมือ ไม่ใช่เป้าหมาย และการคิดไอเดียผลิตภัณฑ์ก็จะนิ่งขึ้น
ดังนั้นผมคิดว่าปัญหาในที่นี้ไม่ใช่ product-market fit
ไม่ค่อยแน่ใจว่าควรมองเรื่องนี้อย่างไรดี ด้านหนึ่งก็ขอปรบมือให้กับการทบทวนตนเอง การเผชิญหน้ากับความจริงที่ไม่สบายใจ และการสร้างชุดเครื่องมือที่ค่อนข้างกว้าง
แต่ถ้าดูข้างในแล้ว มันคือเครื่องมือที่ครอบเครื่องมืออีกที เครื่องมือจัดหมวดหมู่ API ดูเหมือนจะโยนงานหนักส่วนใหญ่ไปให้ OpenAI
“คุณคือ classifier ระดับโลก จงจับ API เหล่านี้ให้เข้ากับหนึ่งในกลุ่มเหล่านี้”
ไฟล์ที่เหลือเป็นโค้ด wiring กับขอบเขต model·view·controller ที่ค่อนข้างพร่าเล็กน้อย เห็นว่ามีเทสต์ด้วย และคิดว่าน่าจะสำคัญสำหรับการ wrap เครื่องมือที่มีการเปลี่ยนแปลงจำนวนมากซึ่งอยู่นอกเหนือการควบคุมของตัวเอง แต่ในทางปฏิบัติกลับอยู่แค่ระดับตรวจว่ามี dependency และ compile ไม่ล้มเหลว คล้าย functional test
contextLoads()ที่ IntelliJ ให้มาเป็นค่าเริ่มต้นมีวิสัยทัศน์ และก็สอดคล้องกับ กฎพาเรโต แต่ระหว่างที่กำลังตรวจสอบสมมติฐานว่าตลาดไม่ได้สนใจจะดูแลรักษาของตัวเอง กลับรู้สึกว่าภายในเองก็ยังแก้ปัญหาการดูแลรักษาของตัวเองไม่ได้
ถ้าพวกเขาแก้เหตุผลนั้นให้ตัวเองได้ก่อน ก็น่าจะแก้ให้คนอื่นได้ด้วย แต่ดูเหมือนเป็น ภาวะกลืนไม่เข้าคายไม่ออก ที่ต้องมีผลิตภัณฑ์ที่ถูกใช้งานจริงก่อน จึงจะรู้สึกถึงความเจ็บปวดและเข้าใจผู้ใช้ปลายทางได้
สตาร์ทอัพที่ล้มเหลวไม่ใช่เรื่องน่าอาย พวกเราส่วนใหญ่ยังไม่มีแม้แต่ความกล้าที่จะลอง
คงคาดหวังความสนใจในโค้ดได้ยาก คุณค่าของโค้ดบริษัทที่ไม่มีธุรกิจและคนอยู่ด้วย ถ้าไม่มีอาวุธลับทางเทคนิคพิเศษอะไร ก็ถือว่าค่อนข้างติดลบ
ต่อให้มีส่วนที่ยอดเยี่ยมทางเทคนิค ผู้คนก็น่าจะพยายามเข้าใจแค่ว่าส่วนนั้นทำงานอย่างไร มากกว่าจะเอาโค้ดไปใช้เอง
อย่างไรก็ตาม ลูกค้ารายหนึ่งสามารถ deploy แพลตฟอร์มเอกสาร ของเราเองได้สำเร็จ ระหว่างหาวิธีรับมือกับผลกระทบจากการปิดตัวของ Konfig
ถ้าไม่มีแผนธุรกิจที่จะสร้างรายได้ได้เร็ว หรือไม่มีเงินลงทุนก้อนใหญ่ ก็ไม่ควรสร้างสตาร์ทอัพเทคโนโลยี โดยทั่วไปถ้าไม่มีเซนส์ขั้นต่ำว่าธุรกิจจะไปทางไหน ก็ยากที่จะหาเงินลงทุน และคนสายเทคนิคส่วนใหญ่มักเข้าใจด้านธุรกิจไม่เพียงพอ
บริษัทส่วนใหญ่ไม่ใช่สตาร์ทอัพ แต่เป็นแค่บริษัท มีรายได้และจ่ายใบแจ้งหนี้ สตาร์ทอัพคือบริษัทที่อยู่ได้ด้วยเวลาและเงินที่ยืมมาโดยยังไม่มีรายได้ และโดยเฉพาะถ้าเงินนั้นเป็นเงินของตัวเอง ก็จำเป็นต้องมีแผน
บริษัทที่ได้รับเงินลงทุนจาก VC ส่วนใหญ่ล้มเหลว งานของ venture capital คือทำให้บริษัทที่จะล้มเหลวล้มเหลวเร็ว และประคองธุรกิจของตัวเองด้วยบริษัทส่วนน้อยที่ไม่ล้มเหลวและเติบโตแบบระเบิด “การเร่งการเติบโต” หรือ “การระดมทุน” ไม่ได้แปลว่าอยู่บนเส้นทางสู่ความสำเร็จ แต่แปลว่าคุณขึ้นไปอยู่บนจุดที่ต้องเอาชนะความน่าจะเป็น และเวลาเหลือไม่มาก
ถ้าเป็นบริษัทที่ประสบความสำเร็จและมีรายได้ ก็ไม่จำเป็นต้องมี venture capital ถ้าอย่างนั้นก็ควรถามว่าทำไมถึงคุยกับพวกเขา ถ้าการสร้างรายได้เป็นเรื่องยาก venture capital ก็แก้เรื่องนั้นให้ไม่ได้
VC จำนวนมากขี้เกียจ และมักสนใจก็ต่อเมื่อประสบความสำเร็จไปแล้ว จึงเกิดพลวัตแปลก ๆ ที่บริษัทที่ได้รับเงินลงทุนตั้งแต่แรกกลับล้มเหลว ส่วนบริษัทที่ไม่ได้รับเงินลงทุนกลับประสบความสำเร็จ
บริษัทปัจจุบันดำเนินงานแบบ bootstrap เต็มรูปแบบมาเป็นปีที่ 4 แล้ว เราต่อสู้กับเรื่องรายได้ แทรกงานลงในเวลาที่ทำได้ และผมยังใช้ชีวิตหลัก ๆ ด้วยงานที่ปรึกษาข้าง ๆ บริษัทมีปีที่ประสบความสำเร็จที่สุดติดต่อกัน 3 ปี และใกล้ถึงจุดที่ผมจะเลิกเป็นที่ปรึกษาแล้วมาทุ่มให้ธุรกิจได้ แต่เป็นการเดินทางที่ยาวนาน
สำหรับโอเพนซอร์ส สิ่งที่ไม่ใช่โค้ดเฉพาะธุรกิจหรือทรัพย์สินทางปัญญาหลักก็เปิดเผย เหตุผลสำคัญอีกอย่างคือไม่อยากสร้างงานจุกจิกเดิม ๆ ซ้ำเมื่อเริ่มบริษัทถัดไป เคยเจอมาแล้วว่าสิ่งเหล่านั้นทำให้ช้าลง
ในสตาร์ทอัพมีคนจำนวนมากที่หมกมุ่นกับทรัพย์สินทางปัญญา แต่ในความเป็นจริง ซอฟต์แวร์ส่วนใหญ่ไม่ได้มีคุณค่าขนาดนั้น ถึงอย่างนั้นการสร้างมันก็ต้องใช้เวลา เงิน และพลังงาน
ดังนั้นผมจึงเปิดเผยเครื่องมือและเฟรมเวิร์กจำนวนมากที่ผมจะเป็นผู้ใช้หลักเอง เพื่อจะได้ใช้ต่อในโปรเจกต์ถัดไปด้วย
การ dump โค้ดเองอาจน่าสนใจ แต่ดูเหมือนยังไม่มีไลเซนส์ติดไว้ ถ้าใส่ ไลเซนส์โอเพนซอร์ส ให้ถูกต้อง ก็น่าจะมีประโยชน์ขึ้นมาก
ตลาดเครื่องมือสำหรับนักพัฒนานั้นยากจริง ๆ
การตัดสินใจด้านสถาปัตยกรรมแทบทุกอย่างกลายเป็นว่า “ถ้าจะแก้ปัญหานี้ ใช้เครื่องมือโอเพนซอร์สอะไรได้บ้าง”
ไม่มีใครอยากจ่ายเงิน และนั่นก็ไม่เป็นไร
ดังนั้นแม้จะมีความต้องการมหาศาลในด้านอื่น ๆ บริษัทจำนวนมากก็ยังไปทำสตาร์ทอัพเครื่องมือสำหรับนักพัฒนา
ถ้ามีวิธีให้ developer ที่มีประสบการณ์และอยากเริ่มทำอะไรบางอย่าง สามารถค้นพบคนที่มีปัญหา ความเชี่ยวชาญในโดเมน และความตั้งใจจะก่อตั้งธุรกิจได้ โดยไม่ต้องพึ่งแค่ความบังเอิญกับ networking ก็น่าจะปลดล็อกคุณค่าได้มาก
ดังนั้นเครื่องมือเชิงพาณิชย์ส่วนใหญ่จึงมีอายุการใช้งานในแง่ประโยชน์ค่อนข้างจำกัด และโดยมากก็เป็นแค่ของที่มีไว้ก็ดี
อีกทั้ง developer จำนวนมากเป็นลูกจ้างและไม่มีงบส่วนตัวสำหรับเครื่องมือ ตลาดจึงแคบลงเหลือ essentially developer ฟรีแลนซ์หรือผู้จัดการที่จ้าง developer
ผู้จัดการทีมตรวจค่าใช้จ่ายแบบนี้ละเอียด และโดยทั่วไปงบก็ไม่ได้มาก บริษัทส่วนใหญ่ไม่มีสิ่งที่เรียกว่างบเครื่องมือส่วนตัวสำหรับ developer
ฟรีแลนซ์เองก็มักใช้เครื่องมือที่บริษัทที่จ่ายเงินให้พวกเขาใช้อยู่ และส่วนใหญ่เป็นเครื่องมือฟรี เครื่องมือเสียเงินยังต้องใส่ใจถึงไลเซนส์สำหรับ contractor ด้วย ทำให้การใช้ฟรีแลนซ์ซับซ้อนขึ้น จึงมีแนวโน้มหลีกเลี่ยงเครื่องมือพวกนั้นเพื่อให้ทุกอย่างเรียบง่าย
ก็รู้ด้วยว่า developer ไปรวมตัวกันที่ไหน และอะไรใช้ได้ผล จึงดูเหมือนทุกอย่างโอเค
แต่เหมือนที่พูดไป developer จำนวนมากไม่อยากจ่ายเงิน และจะมองหาโซลูชันโอเพนซอร์สที่ทำงานที่ต้องการได้ แม้จะสะดวกน้อยกว่านิดหน่อย ยิ่งกว่านั้นอีกฝ่ายคือคนที่งานและชีวิตคือการสร้างซอฟต์แวร์ คำตอบจึงอาจกลายเป็น “เดี๋ยวทำเองก็ได้”
ไม่มีธุรกิจที่รวมบริการหลายอย่างไว้ในบิลใบเดียวหรือ? หรือยังต้องใช้ AWS, Azure, GCloud อยู่ดี?