AI Agent เริ่มเข้ามาแทนที่ SaaS แล้ว

 (martinalderson.com)
7 คะแนน โดย GN⁺ 2025-12-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตลอด 15 ปีที่ผ่านมา ซอฟต์แวร์ได้เข้าครอบงำอุตสาหกรรมต่าง ๆ และตอนนี้ AI Agent กำลังเริ่มเข้ามาแทนที่ตลาด SaaS
  • นักพัฒนากำลังเลิกใช้เครื่องมือ SaaS แบบสำเร็จรูป แล้วหันมา ใช้ Agent เพื่อสร้างเครื่องมือภายในแบบปรับแต่งเองโดยตรง
  • การเปลี่ยนแปลงนี้ทำให้ เกิดความกังขาต่อการต่อสัญญา SaaS และการขึ้นราคา มากขึ้น และบริษัทต่าง ๆ ก็กำลังพิจารณาการสร้างใช้เองเป็นทางเลือกที่ใช้งานได้จริง
  • ภาระด้านการบำรุงรักษาถูกลดทอนลงด้วยความสามารถด้านอัตโนมัติของ Agent และ SaaS เดิมเองก็มีปัญหาการดูแลรักษาอยู่แล้ว เช่น การเปลี่ยนแปลง API
  • SaaS ฝั่ง Back Office แบบ CRUD ที่เรียบง่ายคือกลุ่มที่เสี่ยงที่สุด และองค์กรที่มีความสามารถด้านเทคนิคอาจเปลี่ยนกระแสนี้ให้กลายเป็นความได้เปรียบทางการแข่งขันได้

การผงาดขึ้นของ AI Agent ที่เข้ามาแทน SaaS

  • ตลอด 15 ปีที่ผ่านมา ซอฟต์แวร์ได้เข้าครอบงำอุตสาหกรรมอย่างค้าปลีก สื่อ และการเงิน และตอนนี้ก็เริ่มเกิด กระแสที่ AI Agent จะเข้ามาแทน SaaS
    • ความต้องการใช้เครื่องมือ SaaS ลดลง และงานง่าย ๆ สามารถให้ Agent จัดการได้ภายในไม่กี่นาที
    • ผู้ใช้ไม่คิดจะเลือกเครื่องมืออย่าง Retool อีกต่อไป แต่สร้างแดชบอร์ดขึ้นมาเองโดยตรง
  • Agent อย่าง Gemini 3, Claude Code ยังทำงานที่ไม่ใช่งานพัฒนาได้ด้วย เช่น ทำ mockup UI/UX หรือสร้างงานนำเสนอ
    • ตัวอย่างเช่น Claude Code สามารถแปลง Markdown เป็น PDF และสร้างสไลด์อัตโนมัติ
  • แรงต้านต่อการขึ้นราคาเมื่อต่อสัญญา SaaS สำหรับองค์กร เพิ่มขึ้น
    • ในอดีตการสร้างระบบใช้เองเป็นเรื่องไม่สมจริง แต่ตอนนี้เริ่มถูกพิจารณาเป็นทางเลือกจริงจัง
  • ความซับซ้อนของผลิตภัณฑ์ SaaS มาจากการต้องรองรับความต้องการของลูกค้าจำนวนมาก แต่ เครื่องมือภายในที่ใช้เฉพาะองค์กรสามารถลดความซับซ้อนลงได้เพราะโฟกัสลูกค้าเพียงรายเดียว
    • องค์กรสามารถควบคุมโรดแมปได้ด้วยตัวเอง

ข้อโต้แย้งเรื่องการบำรุงรักษาและแนวทางรับมือ

  • ข้อโต้แย้งหลักคือ “แล้วใครจะดูแลแอปที่สร้างขึ้นเอง”
    • แม้ยังต้องมีการแก้บั๊กและอัปเดตแพตช์ความปลอดภัย แต่ SaaS เองก็มักมีคุณภาพด้านการบำรุงรักษาที่ไม่ดีนัก
  • Agent ช่วยลดต้นทุนการบำรุงรักษาได้อย่างมาก
    • ตัวอย่าง: ทำงานเปลี่ยนไลบรารีที่เลิกซัพพอร์ตแล้วโดยอัตโนมัติ
    • ใช้ไฟล์ AGENTS.md เพื่ออธิบายโค้ดเบสแบบอัตโนมัติและ ช่วยบรรเทาปัญหาความรู้หายไปเมื่อคนย้ายออก
  • SaaS เองก็มีความเสี่ยงด้านการบำรุงรักษา
    • ตัวอย่าง: กรณีที่มีการยกเลิก API เดิมและบังคับย้ายไป API ใหม่จนต้องแก้ระบบครั้งใหญ่
  • องค์กรที่มีศักยภาพด้านเทคนิคกำลังลดการพึ่งพา SaaS และพิจารณาสร้างระบบเอง
    • อย่างไรก็ตาม องค์กรที่ไม่ใช่สายเทคนิคยังยากที่จะเปลี่ยนทั้งหมดในตอนนี้

การเปลี่ยนแปลงของโครงสร้างเศรษฐศาสตร์ SaaS

  • มูลค่าของ SaaS ตั้งอยู่บน อัตราการเติบโตของลูกค้าและ NRR (อัตราการรักษารายได้สุทธิ) ที่สูง
    • เมื่อความต้องการจากลูกค้าใหม่ลดลง คาดว่า ต้นทุนด้านการขายและการตลาดจะเพิ่มขึ้น
  • การลดลงของ NRR คือภัยคุกคามที่ใหญ่กว่า
    • ลูกค้าอาจแทนที่บางฟังก์ชันด้วยเครื่องมือที่สร้างเอง หรือดึงข้อมูลผ่าน API ไปใช้บนแดชบอร์ดภายใน
    • ผลลัพธ์คือ จำนวนไลเซนส์ผู้ใช้ลดลงและหลีกเลี่ยงการอัปเกรด
  • โครงสร้างการขยายธุรกิจที่มาร์จินสูงซึ่งเคยเป็นหัวใจของโมเดล SaaS เดิม อาจอ่อนแอลง

พื้นที่ของ SaaS ที่ยังแข็งแกร่ง

  • ระบบที่ต้องการ High Availability และ High Reliability (SLA) ยังแทนได้ยาก
    • เช่น ระบบประมวลผลการชำระเงินหรือโครงสร้างพื้นฐานหลัก ยังเป็นพื้นที่ที่ SaaS เฉพาะทางอย่าง Stripe ได้เปรียบ
  • บริการที่ต้องประมวลผลข้อมูลปริมาณมากหรืออาศัย Network Effect ก็ยังทดแทนได้ยาก
    • Slack หรือ Data Lake ขนาดใหญ่ ไม่คุ้มค่าที่จะสร้างใช้เองภายใน
  • บริษัทที่ครอบครองข้อมูลแบบ proprietary อาจกลับยิ่งได้เปรียบจากการใช้ Agent
    • ข้อมูลการเงินหรือข้อมูลการขายยังคงมีมูลค่าสูง
  • อุตสาหกรรมที่มี ข้อกำกับดูแลและข้อกำหนดด้าน compliance จะยังคงพึ่งพา SaaS ต่อไป
  • คาดว่าความต้องการบุคลากร SRE และ DevOps เพื่อดูแลแอปภายในจะเพิ่มขึ้น
    • บางองค์กรอาจตั้งทีมเฉพาะขึ้นมาใหม่

กลุ่มที่เสี่ยงที่สุดและการแบ่งขั้วของตลาด

  • SaaS ฝั่ง Back Office ที่อิง CRUD แบบเรียบง่าย จะได้รับผลกระทบหนักที่สุด
    • คือกลุ่มผลิตภัณฑ์ที่ให้เพียงแดชบอร์ดหรือฟังก์ชันวิเคราะห์ง่าย ๆ บนข้อมูลของลูกค้า
    • ลูกค้าสามารถทำเอกสารสเปกเองแล้วให้ Agent สร้างขึ้นใหม่ได้
  • ตลาด SaaS มีแนวโน้ม แยกเป็นสองขั้วระหว่างบริษัทที่มีศักยภาพด้านเทคนิคกับบริษัทที่ไม่มี
    • กลุ่มแรกจะลดต้นทุนและเสริมความสามารถในการแข่งขันด้วยการสร้างระบบเอง
    • กลุ่มหลังจะเปราะบางต่อการขึ้นราคาของ SaaS มากกว่า
  • SaaS จะไม่หายไป แต่ ผลิตภัณฑ์ที่ไม่มีความแตกต่างชัดเจนและไม่มีองค์ความรู้เฉพาะตัวจะอยู่รอดได้ยาก
  • ปัจจัยสำคัญต่อจากนี้คือ Agent จะพัฒนาไปถึงระดับ การจัดการระบบที่ซับซ้อน ได้เร็วแค่ไหน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-12-16
ความคิดเห็นจาก Hacker News

  • ฉันเป็น CTO ของบริษัท SaaS ที่เชี่ยวชาญใน vertical เฉพาะอุตสาหกรรมแห่งหนึ่ง
    ลูกค้าของเราไม่มีความสามารถในการสร้างเครื่องมือขึ้นมาเอง และ “ระบบ” ส่วนใหญ่ก็เป็นแค่ Excel
    ในบรรดาบริษัทใหญ่ มีอยู่สองแห่งที่พยายามทำสำเนาผลิตภัณฑ์ของเราไว้ใช้ภายในองค์กร แต่แห่งหนึ่งล้มเลิกไป และอีกแห่งผู้ใช้ก็บอกว่า “ไม่ค่อยดี”
    เราไม่เคยสูญเสียลูกค้าที่จ่ายเงินเลย
    เราใช้ AI agent อย่างจริงจังเพื่อเร่งความเร็วในการพัฒนา แต่คอขวดก็ยังคงเป็น “การรู้ว่าควรสร้างอะไร”
    มูลค่าของผลิตภัณฑ์อยู่ที่ การตัดสินใจเชิงโดเมน จำนวนมากมายที่ผู้ใช้ไม่ทันสังเกตเห็น ซึ่งเป็นอินไซต์ที่ทีมพัฒนาภายในไม่อาจลอกเลียนได้ภายในวันเดียว

    • เห็นด้วยกับคำว่า “การรู้ว่าควรสร้างอะไรคือคอขวด” ตอนนี้ด้วยอิทธิพลของ LLM นักพัฒนาจำนวนมากเริ่มสัมผัสความจริงข้อนี้ด้วยตัวเอง
    • ทีมขายมักได้ยินคำพูดอย่าง “เราทำเองภายในก็ได้” หรือ “โยนให้ LLM ก็พอ”
      แต่สิ่งที่ลูกค้าจ่ายเงินให้ไม่ใช่ตัว wrapper ของ LLM แต่คือ ความซับซ้อนอีก 99% ที่เหลือ — เทคโนโลยีที่ยาก งานที่ต้องทำซ้ำ ๆ และระบบ SLA กับการสนับสนุน
    • ความเชี่ยวชาญด้านโดเมน + วงจร feedback ที่รวดเร็ว คือหัวใจของความสำเร็จใน B2B SaaS
      ถ้ายกตัวอย่าง LOB app สำหรับภาคธนาคาร หากไม่ได้แลกเปลี่ยน feedback กับลูกค้าทุกวันก็จะตามคู่แข่งไม่ทัน
      เวลาที่ลูกค้าตามความเร็วไม่ทัน พนักงานของเราก็ถึงขั้นเข้าไปนั่งทำงานร่วมกับบริษัทลูกค้าชั่วคราว
    • เสน่ห์ของ HN มักอยู่ที่ คอมเมนต์มีคุณค่ามากกว่าบทความต้นฉบับ
    • มูลค่าที่แท้จริงของ AI อยู่กับ นักพัฒนาเดี่ยวหรือ indie hacker
      ตอนนี้พวกเขาสามารถสร้างแอปที่มีความสมบูรณ์สูงได้โดยไม่ติดข้อจำกัดจากกระบวนการทีมหรือข้อจำกัดด้านงบประมาณ
      แต่ในอีกด้านหนึ่ง ตลาดก็น่าจะ หนาแน่นและหลากหลายมากขึ้น

  • ฉันเป็นผู้ก่อตั้ง SaaS สำหรับจัดการสต็อกชิ้นส่วนอิเล็กทรอนิกส์ชื่อ PartsBox
    ฉันกังวลเรื่อง AI อยู่เหมือนกัน แต่ก็ยังนอนหลับสบาย
    กังวลว่าลูกค้าอาจไม่เข้าใจความลึกของปัญหา แล้วไปสร้างแอปเองด้วย AI แต่จริง ๆ แล้วทุกวันนี้พวกเขาก็ทำอะไรคล้าย ๆ กันด้วยสเปรดชีตอยู่แล้ว
    สิ่งที่ยากจริง ๆ ไม่ใช่ การเขียนโค้ด แต่คือการทำ domain modeling
    มันคือการทำความเข้าใจกระบวนการอันซับซ้อนของโลกจริง และหาสมดุลระหว่าง usability กับความซับซ้อน
    แต่ถึงจะสร้างโมเดลแบบนี้ได้ดีแค่ไหน ของลอกเลียนแบบ ก็ยังตามมาอย่างรวดเร็ว

    • “ความสามารถในการเข้าใจและสร้างแบบจำลองของโลก” คือส่วนที่ AI แทนที่ได้ยาก
      ความรู้เชิงโดเมน รายอุตสาหกรรมส่วนใหญ่มักถูกเก็บไว้ภายในบริษัท และไม่รวมอยู่ในข้อมูลสำหรับฝึกโมเดล
      เพราะแบบนี้ นักพัฒนาในอุตสาหกรรมเหล่านี้กลับยิ่งอยู่ในตำแหน่งที่ มั่นคงกว่าเดิม
    • เราโฮสต์ทางเลือกโอเพนซอร์สชื่อ Inventree ไว้ใช้งานเอง
      เราใช้ AI ปรับแต่งทั้ง backend และ frontend บางส่วน และแก้ปัญหา workflow ได้ภายในสองวัน
      โซลูชัน AI แบบครบถ้วนยังดูไม่สมจริง แต่ถ้าเอา AI มาวางบนฐานโอเพนซอร์ส ก็สามารถสร้าง โซลูชันปรับแต่งได้ในต้นทุนต่ำ
    • มีความเป็นไปได้สูงที่ Microsoft จะผสาน AI เข้ากับ Excel, Word, Access ฯลฯ เพื่อเจาะงานประเภท “เกือบจะอัตโนมัติ” แบบนี้
    • ยังมีคำถามเชิงเทคนิคด้วย — ทำไมถึงเลือกใช้ Clojure และเหตุผลที่ไม่เลือก Common Lisp เป็นเพราะความสามารถด้าน SaaS หรือไม่
    • มีคนชี้ว่า “ถ้า AI กลายเป็น assistant ที่คอยควบคุม UI แทนผู้ใช้ SaaS อาจลดสถานะเหลือแค่ tool call”
      นั่นอาจลบช่องทางโฆษณาของ SaaS และเสี่ยงทำให้ผลิตภัณฑ์ กลายเป็นสินค้าโภคภัณฑ์ (commoditize)

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

    • ภาคการผลิตค่อนข้างอนุรักษ์นิยมต่อการเปลี่ยนแปลง และ ความไม่น่าเชื่อถือของ AI คือความเสี่ยงใหญ่
      ดังนั้นการเปลี่ยนแปลงจึงมักเกิดแบบค่อยเป็นค่อยไป หรือเกิดเฉพาะเมื่อมีข้อได้เปรียบที่ท่วมท้นจริง ๆ เท่านั้น

  • ในช่วงต้นยุค 2000 บริษัทใหญ่ ๆ เคยสร้าง LOB app ด้วยทีม IT ภายใน แต่หลังจากนั้น SaaS เข้ายึดตลาดด้วยความคุ้มค่าด้านต้นทุน
    ตอนนี้ดูเหมือนเรากำลังย้อนกลับสู่ยุคของ การพัฒนาภายในองค์กร อีกครั้ง

    • แต่ก็เป็นไปได้ว่าจะเกิด บริการรับจ้างทำ SaaS แบบปรับแต่งเฉพาะโดยใช้ AI ขึ้นมาใหม่
      ไม่จำเป็นต้องกลับไปจ้างทีม IT ภายในที่เคยปลดออกไปก็ได้

  • ฉันไม่ค่อยเข้าใจประเด็นของบทความนี้ การบอกว่า AI จะมาแทน SaaS เป็นเรื่องที่จะเกิดขึ้นได้ก็ต่อเมื่อ AI ทำงานได้ด้วยตัวเองจริง ๆ
    ต่อให้ AI สร้างโค้ดได้ ก็ยังต้องมี วิศวกรรม ความปลอดภัย และการปฏิบัติการระบบ อยู่ดี ซึ่งทั้งหมดนี้มีต้นทุนสูง
    จ่ายค่าสมาชิก SaaS ยังถูกกว่ามาก

    • นี่คือการเข้าใจ economies of scale ผิด
      แอปภายในองค์กรต้องแบกรับค่าบำรุงรักษา 100% แต่ SaaS กระจายต้นทุนเป็น 1/N ตามจำนวนลูกค้า
      สิ่งที่โค้ดจาก AI มาแทนได้ ก็เป็นของที่แต่เดิมไม่คุ้มจะทำเป็น SaaS อยู่แล้วเท่านั้น
      ตัวอย่างเช่นผลิตภัณฑ์อย่าง Retool จริง ๆ แล้วก็เป็นเครื่องมือที่ ล้าสมัยไปแล้ว มากกว่าจะเป็น SaaS
    • ถึงอย่างนั้น SaaS ที่ทำมาสำหรับนักพัฒนาอาจเป็นข้อยกเว้น
      เช่นถ้าสร้างแดชบอร์ดด้วย Claude ได้ใน 5 นาที แล้วจะยังต้องใช้ SaaS แบบเสียเงินไปทำไม?

  • ฉันกำลังทำ internal app builder คล้าย UI Bakery
    ลูกค้าบางรายกำลังจะยกเลิกสมาชิก SaaS ที่จ่ายปีละมากกว่า 100,000 ดอลลาร์
    เหตุผลที่ SaaS ส่วนใหญ่ยังถูกใช้อยู่ มักเป็นเพราะมีฟีเจอร์เดียวที่จำเป็นจริง ๆ
    แต่เมื่อเปลี่ยนไปใช้เครื่องมือ custom แล้ว การ deploy และการจัดการวงจรชีวิต กลับกลายเป็นโจทย์ใหม่
    ในทางกลับกัน SaaS ที่มี สิทธิ์เข้าถึงข้อมูลเฉพาะตัว ก็ยังแข็งแกร่ง
    ตัวอย่างเช่น การเข้าซื้อ Clearbit ของ HubSpot ถือว่าสมเหตุสมผลมากในฐานะกลยุทธ์รักษาลูกค้า

  • ฉันกำลังพัฒนา ERP แบบปรับแต่งเฉพาะ สำหรับธุรกิจประเภทหนึ่งภายในองค์กร
    ด้วย AI แม้แต่ทีมเล็ก ๆ ก็สามารถสร้าง ซอฟต์แวร์แบบปรับแต่งเฉพาะ ได้อย่างรวดเร็ว
    ฉันคิดว่าตอนนี้เราเข้าสู่ยุคของ “ซอฟต์แวร์บูทีค” แล้ว
    AI เพิ่มผลิตภาพของฉันอย่างน้อย 4 เท่า
    ถ้าสร้างผลิตภัณฑ์ที่ “ดีพอ” ได้ภายใน 2 สัปดาห์ แล้วทำไมต้องไปใช้ SaaS ที่แพง?

    • แต่บริษัทที่เคยหันไปพัฒนาภายในเต็มรูปแบบในอดีต สุดท้ายก็มักตกสู่ นรกแห่งการบำรุงรักษา
      ตอนแรกมันเร็ว แต่เมื่อเวลาผ่านไประบบจะค่อย ๆ กลายเป็น ระบบที่เปราะบางและซับซ้อน
      ถ้าคิดเรื่องคน การปฏิบัติการ และการครอบคลุมช่วงลาพักร้อน ต้นทุนรวมของการพัฒนาภายในจะสูงกว่า SaaS มาก
    • ถ้า AI เพิ่มปริมาณโค้ดที่ผลิตได้ ภาระการบำรุงรักษา ก็จะเพิ่มตาม
      ทั้งความปลอดภัย โครงสร้างพื้นฐาน และ DevOps ล้วนต้องขยายตาม
      SaaS มี network effect แต่เครื่องมือภายในไม่มี สุดท้าย SaaS ก็ยังถูกกว่า
    • AI ทำให้ความคุ้มค่าทางเศรษฐศาสตร์ของการพัฒนาภายในดีขึ้นเล็กน้อยก็จริง แต่ SaaS ก็ไม่เคยมีเป้าหมายหลักเพื่อการลดต้นทุน
      บริษัทส่วนใหญ่ก็ยังชอบใช้บริการสำเร็จรูปมากกว่าอยู่ดี
    • ERP ภายในเป็นของที่ปรับแต่งเฉพาะ จึงใช้เวลา onboarding และบำรุงรักษา นานกว่า
      คำขอเพิ่มฟีเจอร์ก็จะตามมาไม่รู้จบ และแม้ AI agent จะมีประโยชน์กับงานบางอย่าง เช่นการออกแบบโมเดล แต่กับ งานแกนหลักขององค์กร มันยังพลาดบ่อย
    • ยังมีคำถามเกี่ยวกับ tech stack และแนวทางการทำงานด้วย

  • ทุกวันนี้หลายบริษัทเริ่มตั้งข้อสงสัยกับ ใบเสนอราคาต่ออายุ Enterprise SaaS
    แต่การบอกว่า “AI จะมาแทน Workday หรือ Salesforce” เป็นความคิดที่ เหมือนเวทมนตร์มากกว่าโลกจริง
    ในความเป็นจริง Claude Code ยังไม่สามารถสร้างระบบขนาดใหญ่แบบนั้นให้เสร็จได้
    คนที่เคยใช้งานจริงย่อมรู้ข้อจำกัดของมันดี

  • บทความของ Jamin Ball เรื่อง Clouded Judgement: Long Live Systems of Record สมจริงกว่ามาก

    • นี่แหละประเด็นสำคัญจริง ๆ การบำรุงรักษาซอฟต์แวร์คือความเจ็บปวด
      แต่ในอีกด้านหนึ่ง ธุรกิจขนาดเล็กก็สามารถใช้สคริปต์ง่าย ๆ เพื่อ เพิ่มผลิตภาพ ได้แล้ว
    • เห็นด้วย นี่เป็นมุมมองที่แม่นยำกว่ามาก
    • เป็นบทความที่ดี

  • มูลค่าของ SaaS ตั้งอยู่บน ความเร็วในการเติบโตของลูกค้า NRR ที่สูง และ อัตรากำไร 80–90%
    แต่เมื่อรวมต้นทุนโทเคน AI เข้าไปแล้ว ก็มีความเป็นไปได้สูงว่า โครงสร้างกำไรนั้นจะเริ่มสั่นคลอน