- บันทึกประสบการณ์จริงของนักพัฒนาเดี่ยวที่ พัฒนาและดูแลทั้งบริการด้วย Rails เพียงคนเดียว จนทำรายได้ประจำต่อปี ARR 1 ล้านยูโร ได้สำเร็จ
- ช่วงแรกเริ่มต้นด้วย MVP ขั้นพื้นฐาน เท่านั้น แต่ค่อย ๆ เติบโตเป็นโครงสร้างที่ดูแลต่อได้ผ่าน การเขียนใหม่ทั้งระบบและปรับปรุงสถาปัตยกรรม
- หัวใจสำคัญคือ แนวคิดที่สม่ำเสมอของ Rails, องค์ประกอบต่าง ๆ และความสามารถในการรองรับมือถือผ่าน Turbo Native
- เป็นโครงสร้างที่มีประสิทธิภาพจนรองรับทั้งทราฟฟิกและปริมาณการใช้งานทั้งหมดได้ โดย มีค่าเซิร์ฟเวอร์ต่ำกว่า 1,500 ยูโรต่อเดือน
- ท้ายที่สุดได้ ขายหุ้นบางส่วนให้แก่นักลงทุนที่มองระยะยาว และ จ้างนักพัฒนาคนที่สองหลังผ่านไป 14 ปี เปิดฉากสู่ช่วงใหม่ของบริษัท
ประสบการณ์ใช้งาน The One-Person Framework ในโลกจริง
ทำ ARR 1 ล้านยูโรได้ด้วย Rails เพียงตัวเดียว
- ต้นปี 2022 PlanGo ทำ ARR (รายได้ประจำต่อปี) แตะ 1 ล้านยูโร ซึ่งสำหรับบริการที่สร้างขึ้นจาก codebase Rails เดียวและนักพัฒนาเพียงคนเดียว ถือเป็นความสำเร็จราวกับความฝัน
- งานทุกอย่างนอกเหนือจากด้านเทคนิค—การวางวิสัยทัศน์ การหาลูกค้า กลยุทธ์การเติบโต—เป็นหน้าที่ของ ผู้ร่วมก่อตั้งและทีมซัพพอร์ตลูกค้า แต่ ตั้งแต่การออกแบบสถาปัตยกรรมไปจนถึง deployment, operations และการพัฒนาทั้ง frontend/backend ผู้เขียนทำเองทั้งหมด
- แนวคิด “One Person Framework” ที่ DHH พูดถึง หรือโครงสร้างที่นักพัฒนาเพียงคนเดียวสามารถดูแลทั้งแอปพลิเคชันได้ ถูกพิสูจน์แล้วว่าไม่ใช่แค่ทฤษฎี แต่ทำได้จริง
- ปรัชญาเชิงโครงสร้างของ Rails—ตั้งแต่การออกแบบฐานข้อมูล business logic ไปจนถึง frontend UI ที่ทำได้ภายใต้ชุดเครื่องมือที่สอดคล้องกัน—เหมาะอย่างยิ่งกับทีมเล็กหรือผู้ก่อตั้งเดี่ยว
- บทความนี้เขียนขึ้นสำหรับคนแบบต่อไปนี้:
- นักพัฒนา Rails: คนที่กำลังสงสัยว่าทุกวันนี้ยังสร้างโปรดักต์ใหญ่ ๆ คนเดียวได้หรือไม่
- ผู้ก่อตั้งสายเทคนิค: คนที่ต้องรับหลายบทบาทพร้อมกันจนรู้สึกหนักเกินไป
- คนที่ให้ความสำคัญกับความประณีตและการเลือกเทคโนโลยี
สถานการณ์ในช่วงเริ่มต้น
- ผู้เขียนเริ่มเข้าสู่ Rails ในปี 2011 ตอนอายุ 21 ปี ขณะทำโปรเจกต์ PHP(CodeIgniter) อยู่ก่อนแล้ว
- ไม่ได้มีกลยุทธ์ใหญ่โตอะไร แค่เริ่มจาก แรงจูงใจง่าย ๆ ว่าอยากลองใช้ Rails ตามกระแส
- ด้วยไอเดียด้านการตลาดของผู้ร่วมก่อตั้ง จึงใช้กลยุทธ์โปรโมชันว่า ผู้สมัครในสัปดาห์เปิดตัวจะได้ใช้งานฟรี 1 ปี
- เดิมคาดว่าจะมีเพียงไม่กี่สิบคน แต่ความจริงคือ สัปดาห์แรกมีผู้สมัครมากกว่า 500 คน
- เพราะยังเป็นโปรดักต์ระดับ MVP จึงเกิด คำขอฟีเจอร์ คำถาม และคำร้องขอความช่วยเหลือจากผู้ใช้หลายร้อยรายการ ไหลเข้ามาทันที
- ตัวเซิร์ฟเวอร์ยังทำงานได้ดี แต่ ตัวโปรดักต์ยังไม่พร้อมในขณะที่ความต้องการจากลูกค้าหลั่งไหลเข้ามาอย่างหนัก
- ผู้ร่วมก่อตั้งทั้งสองคน ยังมีงานประจำอยู่ จึงไม่สามารถรับมือแบบเต็มเวลาได้
- ผลคือหลีกเลี่ยงไม่ได้ที่จะทำให้ผู้ใช้ช่วงแรกจำนวนมากผิดหวัง
- ประสบการณ์นี้ทำให้ตระหนักอย่างชัดเจนว่า “การพัฒนาซอฟต์แวร์” กับ “การดำเนินธุรกิจซอฟต์แวร์” เป็นคนละเรื่องกันโดยสิ้นเชิง
- บทเรียนที่ได้คือ การทำฟีเจอร์อย่างเดียวไม่พอ แต่ต้องมี ระบบตอบสนองลูกค้า การจัดการความคาดหวัง และการปฏิบัติการบริการที่ยั่งยืน
เรียนรู้ไปพร้อมกับการสร้าง
- แม้จะเริ่มพัฒนาด้วยการอ้างอิง Rails tutorial และ Stack Overflow แต่ การสร้างแอปที่ต้องรับผิดชอบธุรกิจจริงของลูกค้าใน production นั้นเป็นงานคนละระดับ
- โค้ด Rails ช่วงแรกมี ความผิดพลาดแบบมือใหม่ที่พบได้บ่อย เช่น:
- เมธอดในคอนโทรลเลอร์ยาวเกิน 200 บรรทัด
- โมเดลขนาดใหญ่ที่ปนเปหน้าที่หลายอย่าง
- SQL query ที่ไม่มีประสิทธิภาพ
- ไม่มี test code
- ค่าคอนฟิกและ secret key ถูก commit ลง Git
- แม้จะทำฟีเจอร์ได้ แต่ทั้งแอปพลิเคชันก็ยัง พึ่งพาโค้ดแบบแก้เฉพาะหน้าและโครงสร้างที่ไม่มั่นคง
- ฟีเจอร์ต่าง ๆ เช่น user authentication, file upload, การสร้าง PDF, admin UI และการจัดการอีเมล ถูก เร่งทำให้เสร็จด้วยการพึ่งพา Gem แต่เมื่อเวลาผ่านไป Gem แต่ละตัวก็สร้างความซับซ้อนและปัญหาใหม่เพิ่มขึ้น
- ตอนใช้
.round(2) กลับพบว่าเกิด "banker's rounding" จนคำนวณจำนวนเงินผิดพลาด
- การมอบหมายแม้แต่การคำนวณง่าย ๆ ให้ Gem ภายนอก สุดท้ายทำให้เกิดปัญหาจาก ความเข้าใจพื้นฐานเรื่องการจัดการตัวเลขที่ไม่ลึกพอ
- ราวปี 2013 เมื่อประสบการณ์ในการรันโปรดักต์เพิ่มขึ้น หนี้ทางเทคนิคก็เพิ่มขึ้นอย่างรวดเร็ว และการพัฒนาฟีเจอร์ใหม่ก็ยากขึ้นเรื่อย ๆ
เขียนใหม่ทั้งระบบ
- ปกติแล้วการเขียนใหม่ทั้งระบบ (Full Rewrite) มักถูกมองว่าเป็นทางเลือกที่เสี่ยงและไม่มีประสิทธิภาพ แต่ในปี 2014 ผู้เขียนตัดสินใจ สร้างใหม่ตั้งแต่ต้นบน Rails 4
- เป็นการทำงานเข้มข้นอยู่หลายเดือน โดย ดูแลแอปเดิมไปพร้อมกับพัฒนา codebase ใหม่ในเวลาเดียวกัน
- มีการทำสถาปัตยกรรมให้ง่ายขึ้น ลดการพึ่งพา Gem ลงเหลือน้อยกว่าครึ่ง และ เพิ่มการทดสอบให้กับฟีเจอร์หลัก
- โครงสร้างใหม่นั้น เรียบง่ายและเร็วกว่าเดิม โดยเฉพาะถูกออกแบบให้ นักพัฒนาเดี่ยวแบบพาร์ตไทม์ยังดูแลรักษาได้
- การ rewrite ครั้งนี้กลายเป็น รากฐานทางเทคนิคที่ทำให้นักพัฒนาเดี่ยวสามารถดูแลระบบต่อได้ยาวนานกว่า 10 ปี
Rails คือพลังพิเศษ
- PlanGo ถูกดูแลโดยนักพัฒนาเพียงคนเดียวจนถึงปี 2025 และปัจจัยหลักที่ทำให้สิ่งนี้เป็นไปได้ก็คือ Rails
- ด้วยคุณลักษณะเชิงโครงสร้างของ Rails เช่น Convention over Configuration, integration test, ActiveRecord, ActiveStorage และ ActiveJob ทำให้ ลดการตัดสินใจที่ไม่ใช่สาระสำคัญ และโฟกัสกับการสร้างคุณค่าหลักได้
- หลังนำ Turbolinks และ Hotwire มาใช้ ก็สามารถ สร้าง UI สมัยใหม่ได้โดยไม่ต้องพึ่ง JS framework ที่ซับซ้อน
- ในช่วงเริ่มพัฒนาปี 2011 ความต้องการแอปมือถือแทบไม่มี แต่หลังจากนั้น แอป iOS/Android กลายเป็นอินเทอร์เฟซหลักของ PlanGo
- ผู้เขียนลองหลายเฟรมเวิร์ก เช่น Titanium, RubyMotion และ Objective-C พร้อมเผชิญปัญหา การหาสมดุลระหว่างคุณภาพกับความเร็ว
- หลังนำ Turbo Native มาใช้ productivity ก็เพิ่มขึ้นอย่างมาก และ แค่มีความรู้ native development ระดับพื้นฐานก็สามารถสร้างแอปคุณภาพสูงจาก codebase Rails ได้
- วิธีนี้เหมาะอย่างยิ่งกับ แอปแบบ B2B หรือ SaaS เพราะสามารถ ได้ทั้งประสิทธิภาพและประสบการณ์แบบ native ด้วยต้นทุนการพัฒนาระดับทีมเล็ก
- ผลลัพธ์คือมี ยอดดาวน์โหลดแอปมากกว่า 100,000 ครั้งต่อปี และเคย ขึ้นอันดับสูงกว่า Duolingo ใน App Store ของเนเธอร์แลนด์ชั่วคราว
- แอปทั้งหมด พัฒนาและดูแลโดยนักพัฒนา Rails เพียงคนเดียว
- ตัวชี้วัดหลัก:
- โค้ด Ruby: 36,170 บรรทัด
- โค้ด JavaScript: 13,495 บรรทัด
- test coverage: 40%
- ผู้ใช้ที่ใช้งานต่อวัน: 6,332 คน
- จำนวน request ต่อนาทีในช่วงพีค: 7,000 ครั้ง
- ค่าใช้จ่ายเซิร์ฟเวอร์ต่อเดือน: ต่ำกว่า €1,500
- การคงไว้ซึ่ง structured monolithic architecture เป็นหนึ่งในการตัดสินใจที่ดีที่สุด เพราะ deploy ได้ง่ายด้วย Capistrano และ debug ก็สะดวก โดยไม่ต้องแบกรับความซับซ้อนของ microservices
- สำหรับผู้ก่อตั้งสายเทคนิค Rails ไม่ใช่แค่ framework แต่คือ พลังพิเศษที่ทำให้คนคนเดียวทำงานได้เทียบเท่าทั้งทีม
หลังจากทะลุ 1 ล้านยูโร
- ปลายปี 2022 มีจุดเปลี่ยนที่ไม่คาดคิดเกิดขึ้น เมื่อ นักลงทุนต่างชาติเริ่มสนใจ PlanGo และยื่นข้อเสนอเข้าซื้อกิจการ
- ตอนนั้น PlanGo เติบโตแบบ bootstrap จนเกิน €1M ARR และยังคง มีโครงสร้างรายได้ที่ยั่งยืนและการดำเนินงานที่มีประสิทธิภาพโดยไม่ต้องพึ่งเงินทุนภายนอก
- ข้อเสนอนี้กลายเป็นจุดเริ่มต้นของคำถามภายในทีมว่า "ต่อจากนี้เราอยากได้อะไร?"
- มีการสำรวจความเป็นไปได้หลายทาง ไม่ว่าจะคงรูปแบบเดิม รับเงินทุนภายนอกเพื่อ scale up หรือขายทั้งหมด
- แม้ ยังรักในธุรกิจนี้อย่างมาก แต่ก็เริ่มเห็นว่า หากมีทรัพยากรและความเชี่ยวชาญมากขึ้น ก็จะลงมือคว้าโอกาสต่าง ๆ ได้ง่ายกว่าเดิม
- ในแง่ของการ realize ผลตอบแทน ทางเลือกที่ ถอนมูลค่าบางส่วนจากสิ่งที่สร้างมานานกว่า 10 ปี แต่ยังเดินหน้าขยายธุรกิจต่อ ก็ถือว่าสมเหตุสมผล
- สุดท้ายจึงเลือกเป็นพาร์ตเนอร์กับ evergreen fund จากเนเธอร์แลนด์ที่มีค่านิยมและทิศทางระยะยาวสอดคล้องกัน
- ขายหุ้นบางส่วน แต่ยังคงอำนาจบริหารและถือหุ้นส่วนใหญ่ไว้
- ได้ทรัพยากรเพิ่มขึ้นโดย ไม่ทำลายโครงสร้างและวัฒนธรรมเดิม
- การตัดสินใจนี้ไม่ได้มุ่งสู่ exit ระยะสั้นหรือการขยายแบบบุกหนัก แต่เป็นส่วนหนึ่งของ กลยุทธ์การเติบโตที่มั่นคงบนพื้นฐานของธุรกิจที่ยั่งยืนและยึดลูกค้าเป็นศูนย์กลาง
- หลังจากนั้นก็เข้าสู่ช่วงใหม่ที่ยัง รักษาแนวทางแบบ Rails-based ไว้เหมือนเดิม แต่สามารถไล่ตามโอกาสที่เดิมทำได้ยากอย่างจริงจังมากขึ้น
สิ่งที่ได้เรียนรู้
- นี่คือบทเรียนที่ได้จากการทำ PlanGo ในฐานะผู้ก่อตั้งสายเทคนิคแบบลุยเดี่ยวตลอด 14 ปี
- Embrace Rails conventions
- สิ่งสำคัญคืออย่าพยายามฝืนปรัชญาและกฎเกณฑ์ของ Rails
- “Rails Way” คือ วิธีแก้ปัญหาที่ผ่านการพิสูจน์มาแล้ว และยิ่งทำตามมากเท่าไร ก็ยิ่ง โฟกัสกับคุณค่าเฉพาะของโปรดักต์ได้มากขึ้น
- Less is more
- Gem หรือ JS library แม้จะ ช่วยทำฟีเจอร์ได้เร็ว แต่ในเวลาเดียวกันก็ เพิ่มความซับซ้อนและความเสี่ยงต่อการพัง
- ก่อนเพิ่ม dependency ใหม่ ต้องถามตัวเองเสมอว่า "จำเป็นจริงหรือเปล่า?"
- Find a community
- สำหรับนักพัฒนาเดี่ยว การเชื่อมต่อกับนักพัฒนา Rails คนอื่นสำคัญมาก
- ตัวอย่างเช่น community ที่ได้จากการทำ Spina CMS กลายเป็น สายสัมพันธ์อันมีค่าที่แม้ไม่ใช่เพื่อนร่วมงาน แต่ช่วยทั้งการแลกเปลี่ยนความรู้และ feedback
- Technical debt isn't always bad
- บางครั้ง การเลือกแบบ pragmatic เพื่อออกสู่ตลาดให้เร็ว ก็ดีกว่าความสมบูรณ์แบบทางเทคนิค
- หัวใจสำคัญของ technical debt คือ ต้องแยกให้ออกว่าเมื่อไรควรยอมรับมันอย่างตั้งใจ และเมื่อไรควรชำระคืน
- You can go far alone
- หากใช้ Rails นักพัฒนาเพียงคนเดียวก็สามารถออกแบบ ขยายระบบ และ deploy โปรดักต์ในระดับที่ปกติเป็นงานของทั้งทีมได้
- จึงไม่จำเป็นต้องยึดติดกับความเชื่อทั่วไปว่า “ต้องมีทีมเสมอ”
ต่อจากนี้
- พาร์ตเนอร์นักลงทุนรายใหม่เห็นด้วยกับวิธีดำเนินงานแบบ lean ของ PlanGo แต่มีเงื่อนไขอยู่ข้อเดียวคือ ต้องเพิ่มนักพัฒนา Rails อีก 1 คน
- ปัญหาไม่ได้อยู่ที่การยึดติดกับการพัฒนาคนเดียว แต่คือ ความยากของการ onboarding นักพัฒนาใหม่เข้าสู่ codebase ที่พัฒนาต่อเนื่องมานาน 14 ปี
- codebase นี้ไม่ใช่แค่วิวัฒนาการของ PlanGo เท่านั้น แต่ยังเป็น ประวัติการเติบโตของผู้เขียนจากมือใหม่สู่มืออาชีพที่ถูกบันทึกไว้ในโครงสร้างอย่างครบถ้วน และ
เต็มไปด้วยการตัดสินใจและสไตล์โค้ดจากตัวเองในแต่ละช่วงเวลา
- หลังจากจ้างนักพัฒนา Rails คนที่สองซึ่งพบกันที่ Rails World (แคนาดา) ก็เกิด การเปลี่ยนแปลงเชิงโครงสร้างและผลลัพธ์เชิงบวก
- ลดความเสี่ยงทางเทคนิคจากการเป็น single point of failure
- มีมุมมองและไอเดียใหม่ ๆ เข้ามา
- คุณภาพโค้ดดีขึ้นผ่าน pair programming
- ได้แรงกระตุ้นทางปัญญาจากการร่วมงานกับนักพัฒนาที่พูดภาษาเดียวกัน
- หลังจากนี้ก็ ไม่มีแผนจะสร้างทีมพัฒนาขนาดใหญ่
- ดังที่พิสูจน์มาแล้ว แนวทางแบบ Rails-based เพียงอย่างเดียวก็ทำให้ทีมเล็กแต่ทรงพลังสร้างซอฟต์แวร์ที่มีความหมายได้
- อย่างไรก็ตาม ผู้เขียนก็ได้สัมผัสว่า ต่อให้นักพัฒนาเดี่ยวจะมีประสิทธิภาพแค่ไหน ก็ยังเติบโตได้มากขึ้นเมื่อมีเพื่อนร่วมทีมที่ดี
- เส้นทางของ PlanGo คือ กรณีตัวอย่างที่แสดงให้เห็นว่า One-Person Framework ของ Rails ใช้งานได้จริง และ
พิสูจน์ว่าทีมเล็กที่มีเครื่องมือเหมาะสมสามารถสร้างธุรกิจจริงจังได้ตามมาตรฐานของตัวเอง
- ไม่ว่าคุณจะเป็นนักพัฒนาเดี่ยวที่กำลังสร้างโปรดักต์แรก หรือเป็นทีมเล็กที่กำลังชั่งใจเรื่อง tech stack เรื่องราวนี้หวังว่าจะช่วยให้เห็น ความเป็นไปได้เมื่อใช้ Rails ได้อย่างเต็มศักยภาพ
4 ความคิดเห็น
ผมลองทำพอดแคสต์จากเนื้อหานี้ด้วยฟีเจอร์ Audio Overview ของ NotebookLM แล้ว
https://notebooklm.google.com/notebook/…
ระดับนี้ถือว่ายอดเยี่ยมเลยครับ คงต้องขัดเกลาเพิ่มเติมอีกหน่อย
ว้าว.. สุดยอดมากจริงๆ.. เป็นธรรมชาติมากขนาดนี้เลย
ข้อมูลก็ซึมเข้าหูได้อย่างง่ายดายเลย...
ความคิดเห็นจาก Hacker News
มีผู้ใช้ที่มีประสบการณ์คล้ายกับ Django กำลังดูแลแอปของตัวเองอยู่
มีผู้ใช้ที่ยืนยันว่าคนสำคัญกว่าเฟรมเวิร์ก
มีผู้ใช้ที่แบ่งปันประสบการณ์การใช้ Rails และ Phoenix
มีผู้ใช้ที่บอกว่าเคยนำเสนอว่า Rails 7+ ช่วยให้นักพัฒนาเดี่ยวสร้างแอปที่ทะเยอทะยานได้เช่นกัน
มีผู้ใช้ที่เล่าประสบการณ์ว่าพาร์ตเนอร์ใหม่ต้องการเพิ่มนักพัฒนา Rails เข้ามา
มีผู้ใช้ที่กำลังสร้างแอปด้วย AdonisJS
มีผู้ใช้ที่คิดว่า Rails มีหลายจุดที่ดีกว่า Django
มีนักพัฒนาเดี่ยวที่กำลังสร้างแอปด้วย Rails
มีผู้ใช้ที่ยืนยันว่าควรหลีกเลี่ยงการเขียนใหม่ทั้งหมด
มีผู้ใช้ที่คิดว่าเฟรมเวิร์กไม่ได้สำคัญขนาดนั้น