ใช้ LLM แทนไมโคร SaaS ราคา 120 ดอลลาร์ต่อปีได้ในเวลา 20 นาที

• เดิมทีผู้เขียนค่อนข้างสงสัยกับแนวคิดที่ว่า SaaS จะถูก LLM เข้ามาแทนที่ แต่ได้มาแชร์ประสบการณ์ที่ใช้โค้ดของตัวเองแทน บริการแสดงข้อความแนะนำจาก LinkedIn/X มูลค่า 120 ดอลลาร์ต่อปี ได้ภายใน 20 นาที
• บริการที่แทนที่นั้นถูกปล่อยทิ้งไว้ทั้งที่ ระบบชำระเงินเสียมาตั้งแต่ปี 2023 และฝ่ายซัพพอร์ตลูกค้าก็ทำได้เพียงส่งลิงก์เสียกลับมา
• ใช้ Codex เปลี่ยนมาเป็นแนวทางแบบโมดูล โดย แยกข้อความแนะนำเดิมออกเป็นไฟล์ JSON และสร้าง HTML ตอน build time ซึ่งผลลัพธ์ด้านภาพเหมือนเดิม
• สำหรับนักพัฒนา งานนี้ทั้งเร็วและน่าสนใจ แต่สำหรับ คนที่ไม่ใช่นักพัฒนา การตรวจสอบความถูกต้องของโค้ดที่ LLM สร้างขึ้น อาจเป็นอุปสรรคในการเริ่มต้น
• ไมโคร SaaS ที่มีลักษณะคงที่ และไม่สามารถส่งมอบคุณค่าอย่างต่อเนื่อง มีความเสี่ยงจะถูกแทนที่ก่อนเป็นกลุ่มแรกในยุค LLM

---

ความสงสัยเดิมต่อแนวคิดที่ LLM จะเข้ามาแทน SaaS

• แกนหลักของทฤษฎีที่ว่า SaaS จะถูก LLM แทนที่คือ SaaS เป็นผลิตภัณฑ์ซอฟต์แวร์ล้วน ๆ และเมื่อ LLM ลดต้นทุนและเวลาของการสร้างซอฟต์แวร์ตามความต้องการ ได้อย่างมาก ก็จะทำให้ผู้ให้บริการ SaaS ส่วนใหญ่หายไป
• ข้อโต้แย้งคือ ซอฟต์แวร์ HR อย่าง Workday ไม่ได้เป็นแค่ซอฟต์แวร์ธรรมดา แต่เป็นบริการที่รับประกัน การปฏิบัติตามข้อกำหนดของแต่ละประเทศ (เช่น ค่าลาพักร้อน สลิปเงินเดือน ฯลฯ) และอัปเดตต่อเนื่องตามการเปลี่ยนแปลงของปัจจัยภายนอกและภายใน

ประสบการณ์การใช้งาน Shoutout.io และเหตุผลที่เลิกใช้

• ผู้เขียนใช้ Shoutout.io มานาน 4 ปีในราคา 120 ดอลลาร์ต่อปี เพื่อแสดง ส่วนข้อความแนะนำ บน pragmaticengineer.com ที่อิงจากโพสต์บน LinkedIn และ X
• เข้าสู่ระบบเพียงประมาณปีละครั้ง และการล็อกอินล่าสุดก็เพื่อดู ใบแจ้งหนี้รายปี สำหรับการเบิกค่าใช้จ่าย
• ส่วนการชำระเงินถูกปล่อยทิ้งไว้ในสภาพ เสียมาตั้งแต่ปี 2023 และแม้จะอีเมลไปหาทีมซัพพอร์ต ก็ได้รับลิงก์เสียกลับมา
• สถานการณ์ที่ไม่สามารถตรวจสอบได้เลยแม้แต่ว่าปีถัดไปจะถูกเรียกเก็บเงินเท่าไร กลายเป็นเหตุผลโดยตรงที่ทำให้เลิกใช้ SaaS นี้

งานแทนที่ภายใน 20 นาทีด้วย Codex

• ใช้วิธีสร้างใหม่เฉพาะ กรณีใช้งานที่ต้องการจริงของตัวเอง ไม่ได้สร้างแทน SaaS ทั้งตัว ได้แก่ การแสดงข้อความแนะนำ การเพิ่มข้อความแนะนำใหม่ และการคงดีไซน์เดิมไว้
• ขอให้ Codex วางแผนลบการพึ่งพาบริการภายนอก และ โฮสต์ไว้ภายใน GitHub repository
• ปรับเป็นแนวทางแบบโมดูล โดยจัดการข้อความแนะนำใน ไฟล์ JSON แยกต่างหาก และสร้างเป็น HTML ใน ขั้นตอน build ตอนคอมไพล์
• ตั้งแต่การเพิ่มขั้นตอน build บนเครื่อง, ตั้งค่า Netlify build trigger, ทดสอบ, ปรับ UX, สร้างสคีมา ไปจนถึง deploy ใช้เวลารวม 20 นาที
• ผลลัพธ์สุดท้ายมีหน้าตาเหมือนของเดิมทุกประการ พร้อมกับ ตัดการพึ่งพา third-party ออกทั้งหมด
• เมื่อทีมซัพพอร์ตส่งลิงก์ที่ใช้งานได้มาในภายหลัง (2 ชั่วโมงให้หลัง) ตอนนั้นก็ ย้ายระบบเสร็จแล้ว

นัยต่อวิศวกรซอฟต์แวร์

• นักพัฒนาคุ้นเคยกับการใช้ command line และ AI agent เพื่อแทรกข้อความแนะนำลงใน codebase และตรวจสอบผลลัพธ์เมื่อมีการอัปเดตในอนาคต แต่สำหรับคนที่ไม่ใช่นักพัฒนา การตรวจสอบโค้ดที่ LLM สร้างขึ้น ยังเป็นอุปสรรคในการเริ่มต้น
• ความเร็วที่นักพัฒนาจะ "พอร์ต" SaaS มาเป็นโค้ดของตัวเองนั้นสูงกว่าคนที่ไม่ใช่นักพัฒนามาก
  • ในการลองครั้งแรก Codex สร้างผิดเป็น โมเดล flexbox และผู้เขียนต้องตัดสินใจเองโดยตรงว่าจะใช้เฟรมเวิร์กเลย์เอาต์ UI แบบใด
  • คนที่ไม่ใช่นักพัฒนาก็อาจแก้ได้เช่นกัน แต่คาดว่าจะใช้เวลานานกว่า
• การเขียนฟังก์ชันจาก third-party ขึ้นมาใหม่ด้วยตัวเองเป็นงานที่ สนุกและช่วยให้เรียนรู้ อีกทั้งยังเป็นโอกาสได้สัมผัสสมรรถนะจริงของเครื่องมือ

นัยต่อธุรกิจ SaaS

• การสร้าง SaaS ใหม่ทั้งระบบกับการ สร้างใหม่เฉพาะบางกรณีใช้งาน มีระดับความยากต่างกันมาก
  • Shoutout มีฟีเจอร์มากกว่า 10 เท่า เช่น การเพิ่มคำอ้างอิงจากกว่า 10 แพลตฟอร์ม การยืนยันตัวตน การชำระเงิน ฯลฯ
• SaaS แบบคงที่ ที่หลังจากแสดงข้อความแนะนำแล้วไม่ได้ส่งมอบคุณค่าอย่างต่อเนื่อง เป็นประเภทที่ถูกแทนที่ได้ง่ายที่สุด
  • ในทางกลับกัน ถ้ามีฟังก์ชันช่วยธุรกิจแบบเรียลไทม์ เช่น การปฏิบัติตามข้อกำหนด การวิเคราะห์ หรือการแจ้งเตือน การแทนที่จะยากกว่ามาก
• ความสามารถทำกำไรของธุรกิจซื้อขาย SaaS อาจลดลง
  • Shoutout ถูกสร้างโดยนักพัฒนาอิสระในปี 2020, ขายในปี 2022 ให้ product studio และในปี 2025 ก็ถูกขายต่อให้นักพัฒนารายอื่นอีกครั้ง
  • จากมุมมองของผู้ใช้ ไม่มีอะไรเปลี่ยนไปเลยนอกจากระบบชำระเงินที่เสีย
  • ผู้ซื้อกิจการอาจคาดหวังการเติบโตของรายได้โดยไม่ต้องลงทุนเพิ่ม แต่เมื่อผลิตภัณฑ์ถูกปล่อยทิ้ง ผู้ใช้ก็จะเลิกใช้ และในที่สุดก็เข้าสู่จุดที่ LLM เข้ามาแทนได้ง่าย
• ยุคนี้เป็นยุคที่การปล่อยให้เกิด "Broken Windows" ค้างไว้ ยอมรับได้น้อยลงกว่าที่ผ่านมา

[github88]

ค่าใช้จ่ายในการบำรุงรักษาก็เป็นต้นทุนเหมือนกัน

[ddaemiri]

การนำซอฟต์แวร์มาใช้ต้องมองในมุมมองของ TCO ตลอด "5 ปี" เสมอ ไม่อย่างนั้นก็เท่ากับสะสมแค่ 'ระเบิดเวลา' ที่จะมาปะทุเอาจริง ๆ ในภายหลัง

[anjwoc]

ดูเหมือนจะคิดง่ายไปจริง ๆ นะ 555

[sinbumu]

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