ถ้าเริ่มด้วย no-code ภายหลังต้องรื้อทำใหม่ไหม

หน้าจอเดียวกัน สร้างได้สองวิธี

เวลาเปรียบเทียบ no-code กับการพัฒนาเอง คนมักกางรายการฟีเจอร์ออกมาดู สมัครสมาชิกได้ไหม ต่อระบบชำระเงินได้ไหม มีหน้าจัดการหลังบ้านหรือเปล่า แต่รายการนี้ให้คำตอบไม่ได้ เพราะเครื่องมือ no-code สมัยนี้ตอบว่า “ได้” กับเกือบทุกข้อ

จุดที่แยกกันจริงคือข้อมูล ในระบบหลังบ้านที่พัฒนาเอง ข้อมูลสมาชิกและประวัติคำสั่งซื้ออยู่ในฐานข้อมูลที่เราทำสัญญาไว้เอง ส่วน no-code เก็บไว้ในระบบของบริษัทผู้ให้บริการ เราเข้าถึงได้ผ่านหน้าจอและปุ่มส่งออกที่เขาเตรียมให้เท่านั้น ถ้าดูแค่หน้าจอ สองผลิตภัณฑ์ทำงานเหมือนกันทุกอย่าง ความต่างจะปรากฏก็ต่อเมื่อความสัมพันธ์กับผู้ให้บริการรายนั้นสิ้นสุดลง

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

สามจุดที่ no-code ติดขัดจริง

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

จุดที่สองคือเวลาที่หลายคนแก้ข้อมูลชุดเดียวกันพร้อมกัน สินค้าเหลือชิ้นสุดท้ายแต่ลูกค้าสองคนกดชำระเงินพร้อมกันจะเกิดอะไรขึ้น ระบบหลังบ้านที่พัฒนาเองมีวิธีจัดการกรณีนี้เป็นมาตรฐาน ส่วนระบบอัตโนมัติของ no-code มักออกแบบบนสมมติฐานว่าขั้นตอนจะทำงานเรียงลำดับ จึงต้องอ่านเอกสารของผู้ให้บริการว่าเมื่อการทำงานซ้อนกันแล้วเครื่องมือจัดการอย่างไร ปกติมองไม่เห็น แล้วมาโผล่ในวันที่ยุ่งที่สุด

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

ลดต้นทุนการย้ายไว้ล่วงหน้า

ทั้งสามข้อเป็นเรื่องอนาคต จึงตัดสินตอนนี้ได้ยาก ดังนั้นไม่ว่าจะเลือกทางไหน มีสองอย่างที่ควรตรวจสอบตั้งแต่ตอนนี้

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

ตัดสินว่าจะเขียนกฎทางธุรกิจไว้ที่ไหน อัตราส่วนลด การจัดระดับสมาชิก วิธีคิดยอดจ่าย กฎที่มีอยู่เฉพาะในธุรกิจของเรา ถ้ากระจายฝังไว้ตามบล็อกอัตโนมัติหลายที่ในเครื่องมือ no-code งานแรกของการย้ายคือไล่หาว่ากฎเหล่านั้นอยู่ตรงไหนบ้าง ในทางกลับกัน ถ้ารวมไว้ที่เดียว เปลี่ยนเครื่องมือเมื่อไรก็ยกส่วนนั้นไปได้ทั้งชุด

สรุปแล้ว สิ่งที่ต้องตัดสินก่อนไม่ใช่ no-code หรือพัฒนาเอง แต่คือข้อมูลของบริการนี้จะเติบโตอย่างไร และเราดึงมันออกมาได้ตลอดเวลาหรือไม่ เมื่อเรื่องนี้ชัด การเลือกเครื่องมือจะตามมาเอง

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