Build vs Buy: ตัดสินใจยังไงให้ไม่เสียใจ
ทีม Tech อยาก build ระบบเอง เพราะ 'มันง่ายนิดเดียว' แต่ 3 ปีผ่านไป ยังไม่เสร็จ ใช้เงินไป 10 ล้าน บทความนี้สอนวิธีตัดสินใจ Build vs Buy ด้วย TCO, NPV และหลัก Product Management ที่มักถูกข้าม
18 ก.พ. 2569 | 10 นาที
- “ง่ายนิดเดียว”
- ทำไมทีม Tech ชอบ Build มากกว่า Buy?
- 1. “มันง่ายนิดเดียว”
- 2. “เราต้องการ customization”
- 3. “ไม่อยาก depend on vendor”
- 4. “เป็น core competency”
- 5. “สนุกกว่า”
- สิ่งที่มักถูกข้าม (แต่ควรทำ)
- ไม่ทำ Problem Discovery
- ไม่ทำ Market Research
- ไม่ทำ Build-Measure-Learn
- ไม่คิด Jobs to be Done
- TCO: ต้นทุนที่มักถูกลืม
- Build Cost ที่บอก
- TCO จริง (3 ปี)
- Buy Cost (Stripe 2.9%)
- แต่เดี๋ยวก่อน!
- เปรียบเทียบจริงๆ
- Opportunity Cost: สิ่งที่มองไม่เห็น
- สมมุติว่า build feature ที่สร้าง revenue
- Sunk Cost Fallacy: กับดักที่ทำให้หยุดไม่ได้
- คำถามที่ถูกต้อง
- Red Flags และ Green Flags
- Framework ตัดสินใจ Build vs Buy
- Step 1: Problem Discovery
- Step 2: Market Research
- Step 3: TCO Calculation
- Step 4: Risk Assessment
- Step 5: Decision Matrix
- Checklist ก่อนอนุมัติ Build
- สรุป
- Key Takeaways
- Build ไม่ได้ถูกกว่า Buy เสมอไป ต้องคิด TCO ทั้งหมด รวม maintenance, compliance และ opportunity cost
- ก่อน build ต้องทำ Product Management ก่อน ได้แก่ Problem Discovery, Market Research และ MVP
- ถ้าตอบไม่ได้ว่า 'ปัญหาคืออะไร' และ 'ดู vendor กี่เจ้าแล้ว' ยังไม่ควรอนุมัติ
“ง่ายนิดเดียว”
ระบบ Payment นี่ build เองได้ ง่ายนิดเดียว 3 เดือนเสร็จ
ค่าใช้จ่ายเท่าไหร่?
2 developers × 3 เดือน = 6 แสนบาท ถูกกว่าใช้ Stripe ที่เก็บ 2.9% ต่อ transaction
ฟังดูดี อนุมัติ
3 ปีต่อมา…
ระบบ Payment ยังไม่เสร็จ ใช้เงินไปเท่าไหร่แล้ว?
…10 ล้านบาทครับ
เรื่องแบบนี้เกิดขึ้นบ่อยกว่าที่คิด บทความนี้จะอธิบายว่าทำไมถึงเกิดขึ้น และจะป้องกันได้อย่างไร
ทำไมทีม Tech ชอบ Build มากกว่า Buy?
มี 5 เหตุผลที่มักได้ยินเมื่อทีม Tech อยาก build เอง
1. “มันง่ายนิดเดียว”
นี่คือ Underestimation Bias ที่พบบ่อยที่สุด คนที่เก่งมักประเมินความยากต่ำกว่าความเป็นจริง เพราะมองเห็นแค่ส่วนที่ตัวเองรู้ ไม่เห็นส่วนที่ไม่รู้
2. “เราต้องการ customization”
คำถามคือ ต้องการจริงไหม? หรือแค่คิดว่าต้องการ? ส่วนใหญ่ไม่เคย validate ว่า customization นั้นจำเป็นจริงหรือเปล่า
3. “ไม่อยาก depend on vendor”
แต่ลืมไปว่า depend on internal team ก็มีความเสี่ยงเหมือนกัน ถ้าคนที่ build ลาออก จะเกิดอะไรขึ้น?
4. “เป็น core competency”
ถ้าไม่ใช่สิ่งที่สร้าง competitive advantage ก็ไม่ใช่ core competency ระบบ Payment ไม่ใช่ core ของบริษัท E-commerce แต่ประสบการณ์ลูกค้าต่างหากที่เป็น core
5. “สนุกกว่า”
นี่คือความจริงที่ไม่ค่อยมีใครพูด การ build ระบบใหม่สนุกกว่าการ integrate กับ vendor แต่ความสนุกไม่ใช่เหตุผลทาง business
ข้อสังเกต
ทั้ง 5 ข้อนี้ไม่ใช่เหตุผลทาง business แต่เป็นเหตุผลทาง emotion ถ้าได้ยินเหตุผลเหล่านี้ ควรถามคำถามเพิ่มเติม
สิ่งที่มักถูกข้าม (แต่ควรทำ)
ก่อนตัดสินใจ Build vs Buy มีขั้นตอน Product Management ที่ควรทำก่อน แต่มักถูกข้ามไป
ไม่ทำ Problem Discovery
เราต้องการระบบ Payment
ทำไม? ปัญหาคืออะไร?
”…ก็ต้องมีไง”
Design Thinking สอนว่าต้อง Empathize ก่อน Define ก่อน Ideate ถ้าไม่เข้าใจปัญหา จะแก้ปัญหาผิดจุด
ไม่ทำ Market Research
ผม build เองได้
ดู Stripe, Omise, 2C2P หรือยัง?
ไม่ต้องดู ผมรู้ว่าต้องการอะไร
Marketing Research สอนว่าต้องดู competitive landscape ก่อน ถ้าไม่ดู จะไม่รู้ว่ามี solution ที่ดีกว่าอยู่แล้วหรือเปล่า
ไม่ทำ Build-Measure-Learn
ผมจะ build ระบบเต็มรูปแบบเลย
ทำ MVP ก่อนได้ไหม?
MVP มันไม่ professional
Agile สอนว่าต้อง validate assumption ก่อน commit resource ถ้าไม่ทำ MVP จะไม่รู้ว่า assumption ผิดจนกว่าจะสายเกินไป
ไม่คิด Jobs to be Done
ระบบ Payment ต้องมี feature A, B, C, D, E
ลูกค้าต้องการ feature ไหนจริงๆ?
ทุก feature สำคัญหมด
Jobs to be Done สอนว่าลูกค้าไม่ได้ต้องการ feature ลูกค้าต้องการ outcome ถ้าไม่เข้าใจ outcome จะ build feature ที่ไม่มีใครใช้
TCO: ต้นทุนที่มักถูกลืม
เมื่อทีม Tech บอกว่า “6 แสนบาท” นั่นคือแค่ Development Cost ไม่ใช่ Total Cost of Ownership (TCO)
Build Cost ที่บอก
2 developers × 3 เดือน × 100,000 บาท = 600,000 บาท
TCO จริง (3 ปี)
สมมุติว่าเป็นระบบ Payment สำหรับ E-commerce ที่มี transaction volume 100 ล้านบาท/ปี
| รายการ | ปีที่ 1 | ปีที่ 2 | ปีที่ 3 | รวม |
|---|---|---|---|---|
| Development | 600,000 | 0 | 0 | 600,000 |
| Scope creep (เพิ่มขึ้น 50%) | 300,000 | 0 | 0 | 300,000 |
| Bug fixing | 200,000 | 300,000 | 400,000 | 900,000 |
| Security patches | 100,000 | 150,000 | 200,000 | 450,000 |
| PCI-DSS Compliance | 500,000 | 200,000 | 200,000 | 900,000 |
| Infrastructure | 120,000 | 120,000 | 120,000 | 360,000 |
| Opportunity cost | 1,000,000 | 1,000,000 | 1,000,000 | 3,000,000 |
| รวม | 2,820,000 | 1,770,000 | 1,920,000 | 6,510,000 |
PCI-DSS คืออะไร?
PCI-DSS (Payment Card Industry Data Security Standard) คือมาตรฐานความปลอดภัยสำหรับระบบที่รับชำระเงินด้วยบัตรเครดิต ถ้า build ระบบ Payment เอง ต้องผ่านการ audit ทุกปี ซึ่งมีค่าใช้จ่ายสูง
Buy Cost (Stripe 2.9%)
- Transaction volume: 100 ล้านบาท/ปี
- Stripe fee: 2.9% = 2.9 ล้านบาท/ปี
- 3 ปี = 8.7 ล้านบาท
แต่เดี๋ยวก่อน!
ถ้า build เอง ก็ต้องจ่าย payment gateway fee อยู่ดี (ประมาณ 2.5% สำหรับ gateway ในไทย)
- 3 ปี = 7.5 ล้านบาท
เปรียบเทียบจริงๆ
TCO เปรียบเทียบ Build vs Buy (3 ปี)
Opportunity Cost: สิ่งที่มองไม่เห็น
ถ้า 2 developers ไม่ได้ build ระบบ Payment พวกเขาจะทำอะไรได้บ้าง?
สมมุติว่า build feature ที่สร้าง revenue
- Feature ใหม่เพิ่ม conversion 5%
- Revenue เพิ่ม 5% × 100 ล้าน = 5 ล้านบาท/ปี
- 3 ปี = 15 ล้านบาท
นี่คือ Opportunity Cost ที่มักถูกลืม Developer ที่ build ระบบ internal ไม่ได้ build feature ที่สร้าง revenue
Insight
Opportunity Cost มักใหญ่กว่า Direct Cost แต่เพราะมองไม่เห็น จึงมักถูกละเลย
Sunk Cost Fallacy: กับดักที่ทำให้หยุดไม่ได้
ปีที่ 2:
ระบบ Payment ยังไม่เสร็จ ใช้เงินไป 3 ล้านแล้ว ควรหยุดไหม?
หยุดไม่ได้ ลงทุนไปเยอะแล้ว อีกนิดเดียวเสร็จ
นี่คือ Sunk Cost Fallacy เงินที่ใช้ไปแล้วไม่ควรเป็นเหตุผลในการตัดสินใจ เพราะไม่ว่าจะตัดสินใจอย่างไร เงินนั้นก็เอาคืนไม่ได้แล้ว
คำถามที่ถูกต้อง
ถ้าเริ่มใหม่วันนี้ โดยไม่มี code เดิม จะ build หรือ buy?
ถ้าคำตอบคือ “buy” ควรหยุด build ทันที แม้จะลงทุนไปเยอะแล้วก็ตาม
Red Flags และ Green Flags
Red Flags
สัญญาณว่าไม่ควร Build
ข้อดี
ข้อเสีย
- "ง่ายนิดเดียว" — ถ้าง่ายจริง ทำไมมี vendor ขายอยู่?
- "3 เดือนเสร็จ" — Hofstadter's Law: งานใช้เวลานานกว่าที่คิดเสมอ
- "ไม่ต้องดู vendor" — ไม่ทำ market research
- "ทุก feature สำคัญ" — ไม่ทำ prioritization
- "เป็น core competency" — แต่ไม่ได้สร้าง competitive advantage
Green Flags
สัญญาณว่าควร Build
ข้อดี
- เป็น competitive advantage จริงๆ
- ไม่มี vendor ที่ตอบโจทย์ (ทำ research แล้ว)
- มี expertise ในทีม เคยทำมาก่อน
- มี runway เพียงพอ ถ้าล่าช้า 2 เท่ายังไม่ตาย
- ทำ MVP ก่อนได้ validate ก่อน commit
ข้อเสีย
Framework ตัดสินใจ Build vs Buy
Step 1: Problem Discovery
- ปัญหาคืออะไร?
- ใครมีปัญหา?
- ปัญหานี้สำคัญแค่ไหน?
Step 2: Market Research
- มี vendor ที่ตอบโจทย์ไหม?
- ราคาเท่าไหร่?
- ข้อจำกัดคืออะไร?
Step 3: TCO Calculation
| รายการ | Build | Buy |
|---|---|---|
| Development | ค่าพัฒนา + scope creep | 0 |
| Maintenance | Bug fixing + security | รวมใน subscription |
| Compliance | ต้องทำเอง | vendor รับผิดชอบ |
| Infrastructure | ต้องจ่ายเอง | รวมใน subscription |
| Opportunity Cost | Developer ไม่ได้ทำอย่างอื่น | Developer ทำอย่างอื่นได้ |
| Integration | 0 | ค่า integrate กับระบบเดิม |
Step 4: Risk Assessment
| ความเสี่ยง | Build | Buy |
|---|---|---|
| Delay | สูง (มักล่าช้า 2-3 เท่า) | ต่ำ |
| Quality | ขึ้นกับทีม | ขึ้นกับ vendor |
| Talent | ถ้าคนลาออก? | ไม่กระทบ |
| Vendor lock-in | ไม่มี | มี |
| Price increase | ไม่มี | มี |
| Feature gap | ไม่มี | อาจมี |
Step 5: Decision Matrix
| Criteria | Weight | Build | Buy |
|---|---|---|---|
| TCO (3 ปี) | 30% | ? | ? |
| Time to market | 25% | ? | ? |
| Risk | 20% | ? | ? |
| Customization | 15% | ? | ? |
| Strategic fit | 10% | ? | ? |
| รวม | 100% | ? | ? |
ให้คะแนน 1-5 แล้วคูณ weight ตัวเลือกที่ได้คะแนนรวมสูงกว่าคือตัวเลือกที่ดีกว่า
Checklist ก่อนอนุมัติ Build
ถ้าทีม Tech มาขออนุมัติ build ระบบใหม่ ให้ถามคำถามเหล่านี้
- Problem Discovery: ปัญหาคืออะไร? ใครมีปัญหา?
- Market Research: ดู vendor กี่เจ้าแล้ว? ทำไมถึงไม่เลือก?
- TCO Calculation: คำนวณ TCO หรือยัง? รวม maintenance และ opportunity cost หรือยัง?
- MVP Plan: มีแผนทำ MVP ก่อนไหม? จะ validate อะไร?
- Rollback Plan: ถ้าไม่เวิร์ค จะทำยังไง?
กฎเหล็ก
ถ้าตอบ “ไม่” หรือ “ยังไม่ได้ทำ” แม้แต่ข้อเดียว ยังไม่ควรอนุมัติ
สรุป
Build vs Buy ไม่ใช่คำถามทาง Tech แต่เป็นคำถามทาง Business
Key Takeaways
-
Build ไม่ได้ถูกกว่า Buy เสมอไป ต้องคิด TCO ทั้งหมด รวม maintenance, compliance และ opportunity cost
-
เหตุผลที่อยาก build มักเป็น emotion ไม่ใช่ logic ต้องถามคำถามยากๆ เพื่อ validate
-
Product Management ต้องมาก่อน Engineering ทำ Problem Discovery, Market Research และ MVP ก่อน commit resource
-
Opportunity Cost มักใหญ่กว่า Direct Cost Developer ที่ build ระบบ internal ไม่ได้ build feature ที่สร้าง revenue
-
Sunk Cost Fallacy ทำให้หยุดไม่ได้ ถามว่า “ถ้าเริ่มใหม่วันนี้ จะทำยังไง?” ถ้าคำตอบคือ buy ควรหยุด build ทันที
รับบทความผ่านทางอีเมล