KISS or Die: ทำไมวิศวกรอาวุโสถึงล้มเหลวในสตาร์ทอัพ

สตาร์ทอัพแรกของฉันล้มเหลว และสตาร์ทอัพข้างเคียงอีกหลายแห่งก็ล้มเหลวเช่นกัน เรามีเครดิต GCP มูลค่า $100K มีวิศวกรผู้ก่อตั้งที่เคยสร้างระบบในองค์กรขนาดใหญ่ และมีแผนการตลาด แต่เราล้มเหลว ไม่ใช่เพราะเราสร้างมันผิด แต่เพราะเราสร้างมันดีเกินไป นั่นคือปัญหา

ในขณะที่เราใช้เวลาต่อสู้กับสิ่งที่รู้สึกเหมือนเทคสแต็คที่ "ไม่เหมาะสม" เราสูญเสียสิ่งที่สำคัญที่สุด: เวลา แรงขับเคลื่อน และโอกาสเชิงกลยุทธ์

เรื่องนี้ไม่ใช่เรื่องของคนที่ขาดสามัญสำนึก ฉันมีสามัญสำนึก และเรารู้ว่าควรทำให้ทุกอย่างเรียบง่าย แต่เมื่อโมเดลความคิดของคุณไม่เหมาะกับสถานการณ์ สามัญสำนึกทั้งหมดของคุณจะถูกพัดพาไป คุณตัดสินใจ "ถูกต้อง" แต่กลับฆ่าตัวเอง

นี่ไม่ใช่เรื่องของวิศวกรรมที่แย่ แต่เป็นเรื่องของวิศวกรรมที่ดีที่ฆ่าสตาร์ทอัพ ประสบการณ์ที่ทำให้คุณเป็นผู้อาวุโสกลับกลายเป็นภาระหนักที่สุดของคุณ การ "ทำให้ถูกต้อง" หรือแม้แต่ "ทำให้เรียบง่าย" มักจะเป็นการทำผิดพลาด

บทความนี้นำเสนอ โมเดลความคิด เพื่อช่วยให้คุณตัดสินใจ ถูกต้อง และหลีกเลี่ยงข้อผิดพลาดที่ฉันเคยทำ

:::tip สำหรับใคร: วิศวกรอาวุโสที่กำลังเริ่มต้นหรือเข้าร่วมสตาร์ทอัพในระยะเริ่มต้น หากคุณใช้เวลา 5+ ปีในองค์กรขนาดใหญ่หรือบริษัทเทคยักษ์ใหญ่ นี่คือคำเตือนของคุณ

:::

\

โมเดลความคิด #1 - โครงสร้างพื้นฐาน "ฟรี" คือสิ่งที่แพงที่สุด

เครดิต GCP มูลค่า $100K ดูเหมือนของขวัญ แต่มันคือกับดัก มันผลักดันให้คุณออกแบบเกินความจำเป็นเพราะ "จ่ายไปแล้ว" คุณได้รับอินสแตนซ์คอมพิวต์ โหลดบาลานเซอร์ คอนเทนเนอร์เรจิสทรี และเครื่องมือระดับองค์กรที่ต้องการการตั้งค่าระดับองค์กร สิ่งที่คุณต้องการคืออะไร? ปุ่ม "กดเพื่อเดพลอย"

แน่นอน คุณสามารถสร้างเวิร์กโฟลว์ "เดพลอยจาก GitHub ไปยัง VM" บน GCP/AWS/Azure ได้ บางผลิตภัณฑ์ก็ใกล้เคียง แต่มันต้องการขั้นตอนเพิ่มเติม: การกำหนดค่า Cloud Build การตั้งค่าบทบาท IAM การเขียนสคริปต์เดพลอยเมนต์ การจัดการความลับ และการกำหนดค่าการตรวจสอบสุขภาพ คุณเผาเวลาไปกับการสร้างโครงสร้างพื้นฐานการเดพลอยก่อนที่จะเดพลอยผลิตภัณฑ์จริง

ในขณะเดียวกัน แพลตฟอร์มอย่าง Railway หรือ Fly.io ให้สิ่งที่สตาร์ทอัพต้องการจริงๆ: VM ถาวรพร้อมการเดพลอยแบบเริ่มต้นและไปจาก GitHub ง่ายที่สุดเท่าที่จะเป็นไปได้: คุณพุชโค้ดของคุณ และมันก็เดพลอย VM พร้อมใช้งานพร้อมตัวแปรสภาพแวดล้อม SSL โหลดบาลานเซอร์ บันทึก ฯลฯ มันไม่ "ฟรี" แต่พร้อมใช้งาน

เครดิตฟรีผลักดันให้คุณออกแบบเกินความจำเป็นเพราะ "จ่ายไปแล้ว" คุณทำให้ตัวเองเชื่อว่ากำลังประหยัดเงินในขณะที่กำลังใช้ทรัพยากรที่มีค่าที่สุดของคุณ: เวลา

\

โมเดลความคิด #2 - "น้อยที่สุด" <> "เรียบง่าย"

หลักการ KISS แบบดั้งเดิมบอกให้เราทำซอฟต์แวร์ให้เรียบง่าย แต่ในสตาร์ทอัพ นั่นเป็นเป้าหมายที่ผิด คุณไม่ควรทำให้ซอฟต์แวร์เรียบง่าย แต่ควรทำให้โซลูชันเรียบง่าย

ความเรียบง่ายที่แท้จริงควรวัดจากความพยายามทั้งหมด ไม่ใช่ความซับซ้อนของโค้ด:

ความพยายามทั้งหมด = การสร้างเริ่มต้น + การบำรุงรักษา + การดีบัก + การเพิ่มฟีเจอร์ + การอัปเดตความปลอดภัย + การเปลี่ยนแปลงการปรับขนาด

เมื่อคุณสร้างจากศูนย์ คุณเป็นเจ้าของสิ่งเหล่านี้ทั้งหมดตลอดไป เมื่อคุณใช้บริการ สิ่งเหล่านี้ส่วนใหญ่กลายเป็นศูนย์ บริการบุคคลที่สามที่ "อืดอาด" จริงๆ แล้วคือโซลูชันที่เรียบง่ายเพราะมันลดความพยายามทั้งหมด

ตัวอย่าง OAuth ของฉัน

วิศวกรผู้ก่อตั้งของเราตัดสินใจสร้าง OAuth จากศูนย์แทนที่จะใช้ "ไลบรารีที่ไม่รู้จัก" หนึ่งสัปดาห์ต่อมา เขาส่ง PR: การใช้งาน OAuth ที่สะอาดพร้อมโทเค็น JWT การหมุนเวียนรีเฟรชโทเค็น การจัดการเซสชัน และการควบคุมการเข้าถึงตามบทบาท ไม่มีการพึ่งพา ไม่มีการล็อกกับเวนเดอร์ มีเพียงโค้ดที่เราควบคุม

ฉันไม่ได้ปฏิเสธ PR และนี่เป็นความผิดพลาด การทิ้งงานหนึ่งสัปดาห์จะทำลายขวัญกำลังใจ แต่มันสร้างความซับซ้อนของโค้ดและวางมันบนรางที่ผิด นอกจากนี้ การไม่พูดคุยเกี่ยวกับวิธีการก่อนหน้านี้คือความผิดพลาดที่แท้จริงของเรา เราปล่อยให้ความภาคภูมิใจทางวิศวกรรมตัดสินใจเชิงกลยุทธ์

จากนั้น ลูกค้าต้องการ Microsoft OAuth และ Google OAuth การใช้งานแบบกำหนดเองหมายถึงการปรับโครงสร้างหลายวัน การหมุนเวียนรีเฟรชโทเค็น กรณีพิเศษ RBA และสิ่งอื่นๆ การเพิ่มแต่ละอย่างที่ "เรียบง่าย" ต้องการความเข้าใจอย่างลึกซึ้งเกี่ยวกับการยืนยันตัวตนแบบกำหนดเองของเรา ทุกการอัปเดตความปลอดภัยเป็นของเราที่จะนำไปใช้ ทุกข้อกำหนดใหม่เป็นของเราที่จะเขียนโค้ด

หลักการ

ความผิดพลาดของวิศวกรอาวุโสแบบคลาสสิก: การเพิ่มประสิทธิภาพเพื่อการควบคุมแทนที่จะเป็นผลลัพธ์ ในสตาร์ทอัพ ความเป็นจริงต้องการการกลับวิธีคิดของวิศวกรอาวุโสอย่างสิ้นเชิง:

1. หยุดคิด: "นี่เป็นเพียงการเขียนโค้ดไม่กี่วัน" \n เริ่มคิด: "นี่คือเวลาไม่กี่วันที่ไม่ได้เขียนโค้ดผลิตภัณฑ์จริงของฉัน"
2. หยุดคิด: "ฉันสามารถสร้างสิ่งนี้อย่างง่ายๆ" \n เริ่มคิด: "ฉันสามารถแก้ปัญหานี้อย่างง่ายๆ โดยไม่ต้องสร้าง"
3. หยุดคิด: "บริการบุคคลที่สามเพิ่มความซับซ้อน" \n เริ่มคิด: "บริการบุคคลที่สามดูดซับความซับซ้อน"

\

\

โมเดลความคิด #3 - ทางเลือกที่สบาย

เราเลือก Angular เพราะวิศวกรผู้ก่อตั้งของเรารู้จักมันอย่างลึกซึ้ง การตัดสินใจที่ฉลาด ใช่ไหม? ใช้จุดแข็งของคุณ ส่งมอบโค้ดคุณภาพ เฟรมเวิร์กนั้นดี แต่ปัญหาคือระบบนิเวศของมัน

กับดักระบบนิเวศ

Angular ยอดเยี่ยมและวิศวกรของเราสามารถสร้างอะไรก็ได้กับมัน

แต่ "อะไรก็ได้" ใช้เวลาเพียงแค่เริ่มต้น การตั้งค่าการเดพลอย การยืนยันตัวตน และคอมโพเนนต์ UI พื้นฐานหมายถึงการกำหนดค่าไม่รู้จบก่อนที่จะเขียนฟีเจอร์เดียว ในขณะที่เราดีบักธีม Angular Material คู่แข่งสามารถ (และจะ) ใช้ Next.js + Vercel กำลังรับผู้ใช้แล้ว

เปรียบเทียบกับเส้นทาง Next.js + Vercel: เดพลอยแอปโครงร่างด้วย npx create-next-app ในวันแรก เพิ่มการยืนยันตัวตน Clerk และคอมโพเนนต์ shadcn/ui ส่งมอบฟีเจอร์จริงในวันแรก จุดหมายปลายทางเดียวกัน การเดินทางที่แตกต่างกันอย่างสิ้นเชิง

ทำไมเรื่องนี้ถึงเกิดขึ้น?

ความแตกต่างไม่ใช่คุณภาพของเฟรมเวิร์ก แต่เป็นการเพิ่มประสิทธิภาพของระบบนิเวศ Next.js/React ถูกล้อมรอบด้วยสตาร์ทอัพที่ได้รับการสนับสนุนจากนักลงทุนที่สร้างเครื่องมือสำหรับสตาร์ทอัพอื่นๆ:

• UI: shadcn/ui - คัดลอก วาง ส่งมอบ
• Auth: Clerk/Supabase - กำหนดค่าในไม่กี่นาที
• Deploy: Vercel - git push เท่ากับการผลิต
• ทุกอย่าง: ถ้าสตาร์ทอัพต้องการ มีคนสร้างบริการแล้ว

ระบบนิเวศของ Angular ให้บริการองค์กร: มีประสิทธิภาพ ยืดหยุ่น ปรับแต่งได้ไม่มีที่สิ้นสุด สมบูรณ์แบบ(?) สำหรับทีม 50 คนและเป็นพิษสำหรับทีม 3 คน

\

โมเดลความคิด #4 - สร้างแกนหลัก เช่าบริบท

แต่แม้จะมีเครื่องมือที่เหมาะสม ก็ยังมีกับดักสุดท้าย: แรงกระตุ้นที่จะสร้างสิ่งต่างๆ เพราะคุณทำได้ ไม่ใช่เพราะคุณควรทำ กับดักนี้ฆ่าทีมที่แข็งแกร่งทางเทคนิคและสตาร์ทอัพมากกว่าที่เราจินตนาการได้: การสร้างสิ่งที่ไม่มีใครขอเพราะคุณทำได้ ไม่ใช่เพราะคุณควรทำ

เราใช้เวลาอย่างน้อยหนึ่งเดือนในการสร้างฟีเจอร์ที่ไม่มีใครต้องการ OAuth แบบกำหนดเองเมื่อมี Auth0 อยู่แล้ว คิวงานที่ใช้ Postgres เมื่อมี Redis + Celery อยู่แล้ว Terraform ตั้งแต่วันแรกเมื่อคอนโซลทำงานได้ดี การตัดสินใจแต่ละครั้งรู้สึกมีประสิทธิผล แต่แต่ละอย่างเป็นการทำร้ายตัวเองเพื่อเผชิญกับความท้าทายที่แท้จริง เช่น การพูดคุยกับลูกค้าหรือการพัฒนาลูกค้าอื่นๆ

รูปแบบนั้นง่าย: ถ้าลูกค้าจะไม่เลือกคุณเพราะมัน อย่าสร้างมัน

กฎ $50 ของฉัน

ถ้า SaaS มีราคาน้อยกว่า $50/เดือน คุณไม่สามารถจ่ายเพื่อสร้างมันได้ เวลาของคุณแพงเกินไป

การสร้าง OAuth แบบกำหนดเองใช้เวลา 1-2 สัปดาห์ในการบำรุงรักษาทั้งหมดและการเพิ่มผู้ให้บริการ OAuth ที่แตกต่างกัน ที่อัตราการเผาผลาญของสตาร์ทอัพ นั่นคือ $5,000-$15,000 ในเวลาวิศวกรรม หรือในการสูญเสียเวลาโอกาส Auth0 ฟรีสำหรับผู้ใช้งานถึง 25,000 คน จากนั้น $35/เดือน คุณสามารถจ่ายค่า Auth0 ได้ 35 ปีด้วยค่าใช้จ่ายในการสร้างมันครั้งเดียว

ดังนั้น นี่ไม่ใช่เรื่องของเงิน แต่เป็นเรื่องของลำดับความสำคัญและต้นทุนค่าเสียโอกาส

ข้อยกเว้น

ในความเห็นของฉัน สร้างเฉพาะเมื่อคุณไม่สามารถเรียนรู้เกี่ยวกับผู้ใช้โดยไม่มีมัน  ตัวอย่างง่ายๆ คือเมื่อคุณต้องการทดสอบว่าผู้ใช้จะจ่ายเงินสำหรับรายงานที่สร้างโดย AI หรือไม่ สร้างเวอร์ชันที่เรียบง่ายที่สุดที่พิสูจน์ความต้องการ และทุกอย่างอื่นพยายามที่จะหลีกเลี่ยง ใช่ ข้ามโครงสร้างพื้นฐาน ข้าม "การทำให้ถูกต้อง" ข้ามแนวปฏิบัติที่ดีที่สุดที่ไม่ส่งมอบฟีเจอร์ ข้ามการทดสอบ อีกครั้ง ขี้เกียจให้มากที่สุดในการเขียนโค้ด

สิ่งที่ฉันใช้จริงๆ

• Auth: Clerk (React-native, DX ที่ดีกว่า) หรือ Auth0 (มุ่งเน้น B2B, พร้อมสำหรับองค์กร)
• Email: Resend (นักพัฒนามาก่อน) หรือ SendGrid (ผ่านการทดสอบแล้ว)
• Analytics: PostHog (ฟรีจนกว่าจะขยาย)
• Monitoring: Sentry (ไม่มีใครเทียบได้สำหรับข้อผิดพลาด)
• Hosting: Cloudflare หรือ Vercel (ถ้าทุ่มเทกับ Next.js)

เหล่านี้ไม่ใช่การรับรอง แต่เป็นตัวเลือกของฉันเองที่เพิ่มประสิทธิภาพเพื่อความเร็ว ฉันเดาว่าสแต็คของคุณจะแตกต่างกันแต่หลักการนี้จะไม่แตกต่าง

\

\

สรุป

LLMs ทำให้การสร้างกลายเป็นสินค้าโภคภัณฑ์ จูเนียร์คนไหนที่มี Claude ก็สามารถสร้างระบบยืนยันตัวตนแบบกำหนดเองที่คุณภูมิใจได้ คุณค่าของคุณไม่ได้อยู่ที่สิ่งที่คุณสามารถสร้างอีกต่อไป แต่อยู่ที่การรู้ว่าไม่ควรสร้างอะไร

ความเป็นผู้นำคือความสามารถในการแยกสัญญาณจากเสียงรบกวน ความอาวุโสที่แท้จริงหมายถึงการมีวินัยที่จะละเลย 90% ของสิ่งที่คุณรู้และส่งมอบโซลูชันของวันนี้ ไม่ใช่สถาปัตยกรรมของวันพรุ่งนี้