โลกจริงไม่มี Ctrl+Z (ธุรกิจ สัญญา ภาษี และบริษัท ฉบับคนเขียนโค้ด)

ก่อนที่คุณจะก้าวเข้าสู่โลกของสัญญา ภาษี และการจดทะเบียนบริษัท สิ่งแรกที่คุณต้องมีไม่ใช่ทนายความหรือนักบัญชี แต่คือ "แผนที่การตัดสินใจ"

ในฐานะนักพัฒนา คุณคุ้นเคยกับระบบที่มี Logic ชัดเจน ถ้าเงื่อนไขเป็นจริง (True) ให้ทำสิ่งนี้ ถ้าเป็นเท็จ (False) ให้ทำสิ่งนั้น แต่ในโลกของธุรกิจ กฎหมาย และภาษี ความยากไม่ได้อยู่ที่ตัวกฎหมายเพียงอย่างเดียว แต่อยู่ที่ "ความคลุมเครือ" ของการนำไปใช้ และคำถามที่มักจะเกิดขึ้นในใจเสมอคือ "เรื่องนี้ฉันต้องทำเอง หรือฉันต้องจ่ายเงินจ้างคนอื่นทำ?"

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

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

เพื่อให้คุณไม่ต้องเสียเวลาเดาว่าเนื้อหาในแต่ละส่วนมีความยากหรือง่ายเพียงใด หรือมีความเสี่ยงระดับไหน หนังสือเล่มนี้จะใช้ระบบ "ป้ายกำกับสี" (Color-coded Labels) เพื่อบอกระดับการลงมือทำ ซึ่งจะปรากฏอยู่หน้าหัวข้อหรือขั้นตอนต่างๆ ตลอดทั้งเล่ม

###…

อาการที่คนมองเห็น กับโรคที่อยู่ข้างใน

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

เมื่อคุณสรุปว่าตัวเอง "ขายไม่เป็น" สิ่งที่คุณจะทำคือการพยายามแก้ที่ปลายเหตุ เช่น ไปลงคอร์สเรียนการขาย, ฝึกพูดโน้มน้าวใจ, หรือพยายามหา "คนช่วยขาย" ที่เก่งๆ มาดึงดูดลูกค้าให้ ซึ่งในโลกของซอฟต์แวร์ วิธีการนี้มักจะนำไปสู่หายนะ เพราะปัญหาจริงๆ ของนักพัฒนาไม่ได้อยู่ที่ "ทักษะการพูด" แต่อยู่ที่ "การวินิจฉัยโรค" ที่ผิดพลาด

ในโลกธุรกิจ อาการที่คุณเห็น (Symptom) กับโรคที่เป็นจริง (Root Cause) มักจะเป็นคนละเรื่องกัน หากคุณรักษาผิดจุด ต่อให้คุณจ้างนักขายระดับโลกมาช่วย คุณก็อาจจะจบลงด้วยการเสียลิขสิทธิ์ซอฟต์แวร์ให้พาร์ตเนอร์ หรือถูกกดราคาจนไม่คุ้มค่าไฟที่ใช้รันเซิร์ฟเวอร์

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

โรคที่ 1: ไม่รู้ว่าตัวเองขายอะไรอยู่ (Product-Market-Value Mismatch)

อาการของโรคนี้คือ คุณมี Product ที่ทำงานได้สมบูรณ์แบบ (Technical…

Product ≠ ธุรกิจ

หนึ่งในกับดักที่ใหญ่ที่สุดของนักพัฒนาที่ก้าวเข้าสู่โลกธุรกิจคือการสับสนระหว่าง "สิ่งที่สร้างเสร็จ" กับ "สิ่งที่ขายได้"

ในมุมมองของคนเขียนโค้ด เมื่อฟีเจอร์ครบตาม Requirement, ผ่านการ Test, และ Deploy ขึ้น Production ได้สำเร็จ เรามักจะเรียกสิ่งนั้นว่า "Product" และเมื่อเรามี Product หลายตัวในมือ เราจะรู้สึกว่าเรามี "อำนาจต่อรอง" สูงขึ้น เพราะเรามีทางเลือกเยอะ มี Solution ให้เสนอหลากหลาย และดูเหมือนว่าเรามีอาวุธในคลังเต็มไปหมด

แต่ในโลกของธุรกิจ ความจริงนั้นตรงกันข้ามอย่างสิ้นเชิง

ความแตกต่างระหว่าง Product และ ธุรกิจ

เพื่อให้เห็นภาพชัดเจนที่สุด เราต้องแยกสองคำนี้ออกจากกันก่อน:

Product (ผลิตภัณฑ์) คือ ผลลัพธ์ทางเทคนิค มันคือชุดของโค้ด ฐานข้อมูล และ UI ที่ทำงานได้ตามหน้าที่ของมัน Product คือ "เครื่องมือ" (Tool) ที่แก้ปัญหาบางอย่างได้

ธุรกิจ (Business) คือ ระบบที่สร้างรายได้จาก Product นั้นอย่างยั่งยืน มันประกอบด้วย การหาลูกค้า (Acquisition), การรักษาลูกค้า (Retention), การตั้งราคา (Pricing), การสนับสนุนหลังการขาย (Support), และการบริหารจัดการต้นทุน (Cost Management)

หากคุณเขียนระบบจัดการสต็อกสินค้าเสร็จ 1 ตัว คุณมี "Product" แต่ถ้าคุณยังไม่มีใครยอมจ่ายเงินซื้อระบบนี้ หรือคุณยังไม่รู้ว่าจะหาลูกค้า 100 รายแรกจากไหนโดยไม่ต้องใช้คอนเนกชันส่วนตัว…

ทำไมต้องตรวจสอบ "คนที่รู้จักกัน" มากกว่าคนแปลกหน้า

ในโลกของการเขียนโค้ด เราถูกสอนให้ทำ Unit Test และ Integration Test เพื่อให้แน่ใจว่าระบบจะทำงานได้ตามที่คาดหวังก่อนจะ Deploy ขึ้น Production แต่ในโลกของธุรกิจ หลายคนมักจะ "Skip Test" เมื่อคู่สัญญาเป็นคนที่รู้จักกัน

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

คำพูดเหล่านี้คือ "ช่องโหว่ทางความปลอดภัย" (Security Vulnerability) ที่ร้ายแรงที่สุดในดีลธุรกิจ เพราะมันทำให้คุณปิดการรับรู้ถึงความเสี่ยง และเลือกที่จะใช้ "ความเชื่อใจ" (Trust) มาแทนที่ "การตรวจสอบ" (Due Diligence) ซึ่งในทางธุรกิจ ความเชื่อใจคือสิ่งที่ใช้ให้ฟรี แต่การตรวจสอบคือสิ่งที่ต้องลงทุนด้วยเวลาและแรงกาย

กับดักของความคุ้นเคย (The Familiarity Trap)

เมื่อเราดีลกับคนแปลกหน้า เราจะสวมเกราะป้องกันเต็มรูปแบบ เราจะถามคำถามจุกจิก ขอดูเอกสารบริษัท ตรวจสอบประวัติ และอ่านสัญญาทุกตัวอักษร เพราะเราไม่มี "ข้อมูลพื้นฐาน" เกี่ยวกับเขาเลย

แต่เมื่อเป็นคนที่รู้จักกัน สมองของเราจะสร้างทางลัด (Heuristics) โดยการนำ "บุคลิกภาพส่วนตัว" มาปนกับ "ความสามารถทางธุรกิจ" ซึ่งเป็นคนละเรื่องกันอย่างสิ้นเชิง

• บุคลิกภาพส่วนตัว:…

ตารางเปรียบเทียบทั้ง 8 แบบ

เมื่อคุณมี Product ในมือ และมีคนที่เดินเข้ามาบอกว่า "ผมมีคอนเนกชัน" หรือ "ผมช่วยขายให้ได้" สิ่งแรกที่คุณต้องทำไม่ใช่การตกลงเรื่องเปอร์เซ็นต์ แต่คือการเลือก "โครงสร้างของดีล" (Deal Structure)

นักพัฒนาส่วนใหญ่มักตกหลุมพรางที่คิดว่าทุกดีลคือการ "แบ่งเปอร์เซ็นต์" เหมือนกันหมด แต่ในโลกของกฎหมายและธุรกิจ การแบ่ง 20% ของยอดขายในฐานะนายหน้า กับการแบ่ง 20% ของหุ้นในบริษัทที่ร่วมทุนกัน มีความหมายต่างกันราวฟ้ากับเหว ทั้งในแง่ของภาษี ความรับผิดชอบ และสิทธิในโค้ดที่คุณเขียนมาทั้งชีวิต

ก่อนจะลงลึกในรายละเอียดของแต่ละแบบในหัวข้อถัดไป ผมอยากให้คุณใช้ตารางนี้เป็น "แผนที่นำทาง" เพื่อให้เห็นภาพรวมว่า หากคุณเลือกเดินในเส้นทางใด คุณจะต้องแลก (Trade-off) อะไรไปบ้าง

ตารางเปรียบเทียบภูมิทัศน์ของดีล 8 แบบ

ฐานคำนวณ 3 แบบ

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

ในทางกฎหมายและบัญชี ฐานการคำนวณ (Calculation Base) คือจุดที่เกิดข้อพิพาทบ่อยที่สุด เพราะมันคือจุดเริ่มต้นของตัวเลขทั้งหมด หากจุดเริ่มต้นเพี้ยน ผลลัพธ์สุดท้ายจะเพี้ยนตามทันที สำหรับนักพัฒนาซอฟต์แวร์ ฐานคำนวณที่พบบ่อยที่สุดมี 3 แบบ ซึ่งส่งผลต่อกระแสเงินสดในกระเป๋าคุณต่างกันอย่างมหาศาล

Gross Revenue (รายได้รวม)

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

หากคุณตกลงจ่ายคอมมิชชั่นจาก Gross Revenue หมายความว่า ไม่ว่าคุณจะมีต้นทุนเท่าไร หรือลูกค้าจะจ่ายเงินครบหรือไม่ (ในบางกรณี) หรือคุณจะต้องเสียภาษีเท่าไร พาร์ตเนอร์จะได้รับส่วนแบ่งจากยอดเต็มที่ตกลงขาย

ตัวอย่างสถานการณ์: คุณขายซอฟต์แวร์ระบบจัดการสต็อกราคา 100,000 บาท โดยตกลงค่าคอมมิชชั่น 10% ของ Gross Revenue

• ยอดขาย: 100,000 บาท -…

อ่านโครงสร้างทุน (Cap Table) ใน 10 นาที

หากคุณเป็นนักพัฒนา สิ่งที่คุณคุ้นเคยที่สุดคือการจัดการ State ของโปรแกรม ซึ่งถ้า State เปลี่ยน คุณก็แค่เขียนฟังก์ชันให้มัน Update ค่าใหม่ แต่ในโลกของธุรกิจ "หุ้น" คือ State ที่เปลี่ยนยากที่สุด และเมื่อเปลี่ยนแล้วมักจะไม่มีทาง Undo กลับมาเป็นค่าเดิมได้

สิ่งแรกที่คุณต้องเข้าใจก่อนจะก้าวเข้าสู่การเจรจาเรื่องหุ้น คือคุณต้องมีเครื่องมือในการ "มองเห็น" ภาพรวมของความเป็นเจ้าของ ซึ่งในโลกธุรกิจเราเรียกสิ่งนี้ว่า Cap Table หรือชื่อเต็มคือ Capitalization Table

Cap Table คืออะไรในภาษาคนเขียนโค้ด

ถ้าจะเปรียบเทียบให้เห็นภาพ Cap Table ก็คือ config file ของบริษัทที่ระบุว่าใครถือครอง "สิทธิ" ในบริษัทนี้บ้าง โดยระบุเป็นจำนวนหุ้นและสัดส่วนเปอร์เซ็นต์ มันไม่ใช่แค่ตารางบอกว่าใครรวยแค่ไหน แต่เป็นตารางที่บอกว่า "ใครมีอำนาจสั่งการได้เท่าไร" และ "ถ้าบริษัทถูกขายไปในราคา 100 ล้าน ใครจะได้เงินกี่บาท"

ในบริษัทจำกัดของไทย หุ้นทุกหุ้นมีมูลค่าที่ตราไว้ (Par Value) เท่ากัน (เช่น หุ้นละ 100 บาท) ดังนั้นจำนวนหุ้นจึงเป็นตัวกำหนดสัดส่วนความเป็นเจ้าของโดยตรง

โครงสร้างพื้นฐานของ Cap Table

ลองดูตัวอย่างสถานการณ์สมมติ: คุณสร้างซอฟต์แวร์ขึ้นมาตัวหนึ่ง และตัดสินใจจดบริษัทโดยมีเพื่อนร่วมก่อตั้งอีก 2 คน โดยตกลงแบ่งหุ้นกันดังนี้

| ชื่อผู้ถือหุ้น |…