SLA รับทำแอป (Service Level Agreement) คืออะไร?

SLA หรือข้อตกลงระดับบริการ คือ ส่วนหนึ่งของสัญญาที่ระบุมาตรฐานการให้บริการหลังการขาย เช่น ความพร้อมใช้งานของระบบ (Uptime 99.9%), ระยะเวลาในการตอบสนองเมื่อเกิดปัญหา (Response Time) และระยะเวลาในการแก้ไขปัญหา (Resolution Time)

ใครคือเจ้าของ Source Code เมื่อแอปพลิเคชันพัฒนาเสร็จสิ้น?

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

สัญญาจ้างทำแอปพลิเคชัน ข้อควรระวังทางกฎหมายและ SLA ที่องค์กรต้องรู้ก่อนเซ็นสัญญา | Stratton Softech

🏢 บริษัท สแตรทตันซอฟท์เทค จำกัด (Stratton Softech Co., Ltd.)

🌐 เว็บไซต์: https://rubtumapp.com

📞 โทรศัพท์: 097-9676457

💬 Line ID: stratton

📱 Line OA: @strattonsofttech

✉️ อีเมล: strattonsofttech@gmail.com

✨ รับทำ Mobile Application ครบวงจร | บริษัทรับทำแอป Android และ iOS ชั้นนำ ✨

⚙️ SEO Premium Metadata (For Admin)
Focus Keyword: สัญญาจ้างทำแอป, SLA รับทำแอป
Title: สัญญาจ้างทำแอปพลิเคชัน ข้อควรระวังทางกฎหมายและ SLA ที่องค์กรต้องรู้ก่อนเซ็นสัญญา
Meta Description: คู่มือ SEO Premium เจาะลึกสัญญาจ้างทำแอปพลิเคชัน ข้อควรระวังทางกฎหมาย และการกำหนด SLA รับทำแอป ที่องค์กรต้องรู้ก่อนพิจารณาเสนอราคาและเซ็นสัญญา เพื่อป้องกันข้อพิพาท

📑 Legal & Tech Business Guide 2026

สัญญาจ้างทำแอปพลิเคชัน ข้อควรระวังทางกฎหมายและ SLA ที่องค์กรต้องรู้ก่อนเซ็นสัญญา

Q: สัญญาจ้างทำแอปพลิเคชันคืออะไร?

สัญญาจ้างทำแอปพลิเคชัน คือ เอกสารทางกฎหมายที่ระบุข้อตกลงระหว่างผู้ว่าจ้างและผู้รับจ้างพัฒนาซอฟต์แวร์ โดยกำหนดขอบเขตงาน (Scope of Work), ระยะเวลา, ค่าจ้าง, เงื่อนไขการส่งมอบงาน และความรับผิดชอบของทั้งสองฝ่ายอย่างชัดเจน

App Development Contract: Legal Precautions and SLAs Organizations Must Know Before Signing

🤖 AI Overview: สรุปประเด็นสัญญาจ้างทำแอปพลิเคชัน และ SLA

สัญญาจ้างทำแอป (App Development Contract) คือเอกสารนิติกรรมที่ผูกพันระหว่างผู้ว่าจ้างและ บริษัทรับทำแอป Android และ iOS โดยต้องระบุรายละเอียดที่สำคัญได้แก่ 1. ขอบเขตงาน (Scope of Work) 2. ลิขสิทธิ์ซอร์สโค้ด (Source Code Ownership) และ 3. เงื่อนไขการรักษาความลับ (NDA) ส่วน SLA (Service Level Agreement) หรือข้อตกลงระดับบริการ คือมาตรวัดคุณภาพหลังการส่งมอบงาน เช่น การรับประกันระบบไม่ล่ม (Uptime Guarantee ที่ 99.9%) และระยะเวลาตอบสนองแก้ปัญหา (Response Time) การพิจารณารายละเอียดเหล่านี้ให้รัดกุมตั้งแต่ช่วงพิจารณาใบเสนอราคา (Quotation) จะช่วยลดความเสี่ยงโครงการล้มเหลวและข้อพิพาททางกฎหมายได้ 100%

💡 ในยุคดิจิทัลดิสรัปชัน (Digital Disruption) ทุกองค์กรต่างหันมาพัฒนาดิจิทัลโปรดักต์ของตนเอง ไม่ว่าจะเป็นระบบ ERP ภายใน หรือ Mobile Application สำหรับลูกค้า (B2C) ทว่าหนึ่งในปัญหาที่คลาสสิกที่สุดที่นำไปสู่การฟ้องร้องหรือโปรเจกต์ถูกทิ้งกลางทาง ไม่ใช่เรื่องของเทคโนโลยี แต่เป็นเรื่องของ “ความหละหลวมในการทำสัญญาจ้างทำแอปพลิเคชัน”

บ่อยครั้งที่ผู้ประกอบการมุ่งเน้นแต่เพียงฟีเจอร์ที่อยากได้และราคาที่ถูกที่สุด จนละเลยการตรวจสอบเงื่อนไขทางกฎหมาย และข้อตกลงระดับบริการ (SLA) ซึ่งถือเป็น “เกราะป้องกัน” ที่สำคัญที่สุดของธุรกิจ บทความ SEO Premium โดย บริษัท สแตรทตันซอฟท์เทค จำกัด ฉบับนี้ จะพาคุณเจาะลึกแบบทะลุปรุโปร่งถึงข้อควรระวัง ทุกบรรทัดที่คุณต้องอ่านก่อนจรดปากกาเซ็นสัญญา 🚀

📌 Part 1: ความสำคัญของการเตรียมตัวตั้งแต่ช่วงเสนอราคา (Quotation) และประมูลงาน (Bidding)

หลายองค์กรมีความเชื่อที่ผิดว่า สัญญาจะเริ่มมีความสำคัญก็ต่อเมื่อถึงวันเซ็น แต่ในความเป็นจริง กระบวนการที่สำคัญที่สุดก่อนจะถึงขั้นตอนการทำสัญญา คือช่วงของการประมูลงาน (Bidding) และการนำเสนอราคางาน (Quotation)

ในช่วงเวลาที่คุณกำลังเชิญบริษัทซอฟต์แวร์หลายแห่งเข้ามาประมูลงาน (Bidding) หรือกำลังพิจารณาเปรียบเทียบใบเสนอราคางาน (Job Quotation) เป็นช่วงเวลาทองที่คุณต้องกำหนดขอบเขตของ SLA รับทำแอป ลงไปในเอกสารทีโออาร์ (TOR – Terms of Reference) ให้ชัดเจน

✅ การคัดกรองเบื้องต้น: การระบุเงื่อนไขรับประกันและ SLA ลงไปใน TOR ตั้งแต่ช่วงประมูลงาน จะช่วยคัดกรองบริษัทที่ไม่ได้มาตรฐานออกไปได้ทันที
✅ ความแม่นยำของใบเสนอราคา: หากบริษัทรับทำแอปทราบว่าต้องรับประกัน Uptime 99.9% ตัวเลขในใบเสนอราคาจะสะท้อนต้นทุนของ Cloud Infrastructure ระดับสูง ทำให้ผู้ว่าจ้างได้เห็นต้นทุนที่แท้จริง ไม่ใช่ราคาที่ดัมป์ลงมาเพื่อแย่งงานแล้วทิ้งงานในภายหลัง

📝 Part 2: องค์ประกอบบังคับใน สัญญาจ้างทำแอป (Core Contract Elements)

สัญญาจ้างทำแอปพลิเคชันที่ดี ต้องไม่ใช้สัญญาจ้างทำของแบบทั่วไป (Generic Template) แต่ต้องถูกปรับแต่งให้สอดคล้องกับวงจรการพัฒนาซอฟต์แวร์ (SDLC) องค์ประกอบที่คุณต้องมองหา มีดังนี้:

Scope of Work (SOW) แบบละเอียด: ห้ามเขียนแค่ “ทำแอปพลิเคชันอีคอมเมิร์ซ” แต่ต้องแนบเอกสาร Requirement, Wireframe, แพลตฟอร์มที่รองรับ (iOS รุ่นไหน, Android รุ่นไหน) เข้าไปเป็นส่วนหนึ่งของสัญญา
Milestones & Payment Terms: การแบ่งงวดงานและการชำระเงิน ไม่ควรจ่ายก้อนใหญ่ตอนจบ แต่ควรแบ่งตามความคืบหน้า (เช่น 30% ตอนเซ็น, 30% เมื่อเสร็จ UI/UX, 30% เมื่อส่งมอบ UAT, 10% เมื่อนำขึ้น Store)
Intellectual Property (IP) Rights: ⚠️ ข้อนี้สำคัญมาก! ต้องระบุชัดเจนว่า “ผู้ว่าจ้างเป็นผู้ถือครองกรรมสิทธิ์และลิขสิทธิ์ทั้งหมดใน Source Code, รูปแบบฐานข้อมูล, ดีไซน์ และเอกสารที่เกี่ยวข้อง ทันทีที่ชำระเงินครบถ้วน”
Confidentiality (NDA): เงื่อนไขการรักษาความลับทางธุรกิจ ทั้งข้อมูล Data ของลูกค้าองค์กร และแผนธุรกิจ ห้ามบริษัทผู้รับจ้างนำไปเปิดเผยหรือทำซ้ำ

⚠️ Legal Trap (กับดักทางกฎหมายที่พบบ่อย): การไม่ระบุเรื่อง “การส่งมอบ Source Code” บางบริษัทส่งมอบเฉพาะตัวแอปที่ Compiled แล้ว (ไฟล์ .apk หรือ .ipa) แต่ไม่ยอมให้ Source Code ทำให้ในอนาคตคุณไม่สามารถจ้างบริษัทอื่นมาพัฒนาต่อได้ และถูกผูกขาดอยู่กับบริษัทเดิมตลอดไป!

⚙️ Part 3: เจาะลึก SLA (Service Level Agreement) ที่ต้องมีในสัญญา

เมื่อแอปพลิเคชันถูกส่งมอบและเปิดใช้งานจริง (Go-Live) สัญญาจะเข้าสู่ช่วงการบำรุงรักษา (Maintenance Period) ซึ่งตัวชี้วัดความเป็นมืออาชีพของบริษัทรับทำแอป คือข้อตกลง SLA

1. Uptime Guarantee (การรับประกันความพร้อมใช้งาน)

แอปพลิเคชันที่ดีไม่ควรล่ม โดยทั่วไป SLA มาตรฐานของระบบระดับองค์กรควรอยู่ที่ 99.9% (Three Nines) ซึ่งหมายถึงยอมรับระบบล่มได้ไม่เกิน 8.76 ชั่วโมงต่อปี หากองค์กรคุณเป็นสถาบันการเงินอาจต้องเรียกร้องถึง 99.99% (ล่มได้ไม่เกิน 52 นาทีต่อปี)

2. Response Time & Resolution Time

Response Time: ระยะเวลาที่ทีม Support ต้องตอบรับหลังจากเราแจ้งปัญหา (เช่น Critical Issue ต้องตอบสนองภายใน 15-30 นาที)
Resolution Time: ระยะเวลาที่ต้องแก้ปัญหาให้เสร็จ (เช่น หากเซิร์ฟเวอร์หลักล่ม ต้องกู้คืนให้ได้ภายใน 2-4 ชั่วโมง)

3. RPO (Recovery Point Objective) & RTO (Recovery Time Objective)

ในกรณีที่ข้อมูลสูญหายจากภัยพิบัติหรือแฮกเกอร์ สัญญาควรระบุรอบการ Backup ว่าข้อมูลจะสูญหายย้อนหลังได้ไม่เกินกี่ชั่วโมง (RPO) และระบบจะกลับมาทำงานได้ภายในกี่ชั่วโมง (RTO)

⚖️ Part 4: ข้อควรระวังเรื่อง PDPA / GDPR และ Open Source

กฎหมายคุ้มครองข้อมูลส่วนบุคคล (PDPA) มีผลบังคับใช้อย่างเต็มรูปแบบ สัญญาจ้างทำแอป ต้องมีข้อตกลงประมวลผลข้อมูลส่วนบุคคล (Data Processing Agreement – DPA) แนบท้าย เพื่อกำหนดให้ผู้รับจ้าง (ในฐานะผู้ประมวลผลข้อมูล) ต้องมีระบบรักษาความปลอดภัยของฐานข้อมูลที่แน่นหนา และรับผิดชอบหากทำข้อมูล User รั่วไหล

นอกจากนี้ ต้องระวังการที่นักพัฒนานำ Open Source Software (OSS) ที่มีลิขสิทธิ์แบบ Copyleft (เช่น GPL) มาใช้ในโปรเจกต์ ซึ่งอาจบังคับให้แอปขององค์กรคุณต้องเปิดเผย Source code สู่สาธารณะด้วย สัญญาจึงต้องห้ามใช้ไลบรารีที่มีเงื่อนไขเหล่านี้นอกจากจะได้รับอนุญาตเป็นลายลักษณ์อักษร

กำลังมองหาบริษัทรับทำแอปที่มีสัญญาและ SLA มาตรฐานสากลอยู่หรือเปล่า?

บริษัท สแตรทตันซอฟท์เทค จำกัด บริการพัฒนาแอปพลิเคชันระดับ Enterprise
พร้อมให้คำปรึกษาด้านการจัดทำ TOR และร่างสัญญาที่ปกป้องธุรกิจคุณ 100%

ปรึกษาผู้เชี่ยวชาญฟรีผ่าน LINE

📊 Part 5: ตารางเปรียบเทียบสัญญาจ้างทำแอปที่ดี vs สัญญาที่อันตราย

ประเด็นในสัญญา (Contract Elements)	✅ สัญญามาตรฐานระดับ Enterprise (Good)	❌ สัญญาที่เสี่ยงและเสียเปรียบ (Bad)
Source Code (ซอร์สโค้ด)	ผู้ว่าจ้างเป็นเจ้าของลิขสิทธิ์ 100% พร้อมส่งมอบเมื่อจบงาน	ไม่ระบุ หรือระบุเพียงว่าให้ “สิทธิ์การใช้งาน (License)”
ข้อกำหนดด้าน SLA รับทำแอป	ระบุ Uptime > 99.9%, Response Time ชัดเจน และมีค่าปรับ	ระบุแค่คำว่า “จะดูแลระบบให้ใช้งานได้ตามปกติ” (เลื่อนลอย)
เงื่อนไขการส่งมอบงาน / จ่ายเงิน	แบ่งงวดตามความสำเร็จของฟีเจอร์ และต้องผ่าน UAT	จ่าย 50% มัดจำ และ 50% ตอนจบงาน (ความเสี่ยงผู้ว่าจ้างสูง)
Change Request (การขอเปลี่ยนสเปก)	มีกระบวนการประเมินราคาและเวลาใหม่ (Change Order)	ไม่ระบุ ทำให้ทะเลาะกันเรื่องทำงานนอกสเปก
Third-party API & Licenses	ระบุชัดเจนว่าใครเป็นผู้รับผิดชอบค่าใช้จ่ายรายเดือนของ API	หมกเม็ดค่าใช้จ่าย ผู้ว่าจ้างต้องมาจ่ายเพิ่มทีหลังมหาศาล

💼 Part 6: Use Cases (กรณีศึกษาความสำคัญของ SLA)

🛒

E-Commerce Application

ปัญหา: แพลตฟอร์มล่มช่วงแคมเปญ 11.11 นาน 3 ชั่วโมง เพราะไม่มีการทำ Load Testing และระบุ SLA ในสัญญา
ผลลัพธ์จาก SLA: หากมี SLA ที่รัดกุม บริษัทผู้พัฒนาจะต้องออกแบบระบบ Auto-scaling รองรับโหลด และหากล่ม ต้องชดเชยค่าปรับทางธุรกิจ

🏥

Healthcare Telemedicine

ปัญหา: ข้อมูลประวัติคนไข้รั่วไหล เนื่องจากไม่มีข้อกำหนดด้าน Data Security และ PDPA ในสัญญา
ผลลัพธ์จาก SLA: สัญญาที่ระบุเรื่อง DPA และ Security Audit ประจำปี จะบีบให้นักพัฒนาเข้ารหัสข้อมูล (Encryption) ตั้งแต่วันแรกที่เขียนโค้ด

🏭

Corporate ERP App

ปัญหา: ต้องการเปลี่ยนบริษัทพัฒนาซอฟต์แวร์ แต่เจ้าเดิมไม่ยอมให้ Source Code และ Database Schema
ผลลัพธ์จาก SLA: สัญญาที่ระบุการโอนสิทธิ์ IP ชัดเจน ทำให้องค์กรมีอิสระในการเปลี่ยน Vendor โดยไม่ถูกจับเป็นตัวประกัน

✅ Part 7: Checklist ขั้นตอนการทำงานก่อนและหลังเซ็นสัญญา

เพื่อหลีกเลี่ยงข้อพิพาท ทาง สแตรทตันซอฟท์เทค ขอแนะนำขั้นตอน 5 Steps ดังนี้:

Bidding & Quotation: วางเงื่อนไขสเปก, เทคโนโลยีที่ต้องการ (เช่น React Native, Flutter) และ SLA รับทำแอป ในใบเสนอราคาให้เรียบร้อย
Drafting Contract: ให้ฝ่ายกฎหมายหรือทนายความ (Legal Counsel) ตรวจสอบร่างสัญญาจ้างทำแอปพลิเคชันอย่างละเอียด
SOW Attachment: แนบเอกสาร Software Requirement Specification (SRS) และ Wireframe เป็นส่วนหนึ่งของสัญญาท้ายเล่ม
Execution & Milestones: ตรวจรับงานอย่างเคร่งครัดตามงวด (UAT) ก่อนอนุมัติจ่ายเงิน
Handover & Deployment: รับมอบ Source Code ผ่าน Repository (เช่น GitHub/GitLab) และรหัสผ่าน Server ทั้งหมด

💡 Part 8: 30 FAQs คำถามที่พบบ่อยเกี่ยวกับสัญญาจ้างทำแอปและ SLA

รวมรวบ 30 คำถามเชิงลึกสุดพรีเมียม (People Also Ask) ที่ผู้บริหารและโปรเจกต์เมเนเจอร์ต้องรู้:

1. สัญญาจ้างทำแอปพลิเคชันคืออะไร?

คือเอกสารนิติกรรมที่ผูกพันผู้ว่าจ้างและผู้รับจ้างพัฒนาซอฟต์แวร์ ระบุขอบเขตงาน เวลา ค่าจ้าง และความรับผิดชอบของทั้งสองฝ่าย

2. SLA (Service Level Agreement) คืออะไร?

คือข้อตกลงระดับบริการที่รับประกันคุณภาพหลังส่งมอบ เช่น ระบบต้องพร้อมใช้งาน (Uptime) กี่เปอร์เซ็นต์ และเวลาตอบสนองแก้ปัญหา

3. ทำไม SLA ถึงสำคัญในการรับทำแอป?

เพราะแอปเป็นสินทรัพย์ที่ต้องรัน 24 ชม. SLA จะช่วยการันตีว่าเมื่อเกิดปัญหา ผู้รับจ้างจะไม่ทิ้งงานและรีบแก้ไขตามเวลาที่กำหนดเพื่อลดผลกระทบทางธุรกิจ

4. ใครคือเจ้าของ Source Code เมื่อแอปเสร็จ?

สัญญาที่ดีต้องระบุให้ “ผู้ว่าจ้าง” เป็นเจ้าของ Source code ทันทีที่ชำระเงินครบถ้วน เพื่อป้องกันการถูกผูกขาดจากนักพัฒนาเดิม

5. การรับประกันผลงาน (Warranty) ควรมีระยะเวลานานเท่าใด?

โดยมาตรฐานอุตสาหกรรม การรับประกันบั๊ก (Bug/Defect) ควรอยู่ที่ 3 – 6 เดือน หลังจากการส่งมอบและขึ้นระบบ (Go-live) เรียบร้อยแล้ว

6. NDA (Non-Disclosure Agreement) จำเป็นหรือไม่?

จำเป็นอย่างยิ่ง เพื่อป้องกันไม่ให้บริษัทรับทำแอปนำไอเดีย แผนธุรกิจ หรือข้อมูลลูกค้าของคุณไปเปิดเผยหรือขายให้คู่แข่ง

7. หากบริษัทรับทำแอปทิ้งงาน จะฟ้องร้องได้อย่างไร?

สามารถฟ้องร้องผิดสัญญาแพ่งและพาณิชย์ได้ โดยอ้างอิงจากหลักฐานการแบ่งงวดงานและเงื่อนไขการส่งมอบที่ระบุในสัญญาจ้างทำของ

8. ช่วงประมูลงาน (Bidding) ควรระบุ SLA ใน TOR เลยหรือไม่?

ควรระบุทันที เพื่อให้บริษัทที่เข้าร่วมนำเสนอราคา (Quotation) ประเมินต้นทุนได้ถูกต้อง และกรองบริษัทที่ไม่มีความสามารถในการดูแลระบบระยะยาวออกไป

9. การแบ่งงวดชำระเงินที่เหมาะสมควรเป็นอย่างไร?

ไม่ควรจ่ายเงินก้อนใหญ่ทีเดียว ควรแบ่งตาม Milestone เช่น 20% (เซ็นสัญญา), 30% (เสร็จ UI/UX), 30% (โค้ดดิ้งเสร็จ), 20% (นำแอปขึ้น Store)

10. ค่าบำรุงรักษา (Maintenance) ควรคิดเป็นกี่เปอร์เซ็นต์ของมูลค่าแอป?

โดยทั่วไปค่า MA รายปีจะอยู่ที่ประมาณ 15% – 20% ของมูลค่าการพัฒนาโปรเจกต์ทั้งหมด ขึ้นอยู่กับความซับซ้อนของ SLA

11. หากแอปมีบั๊กหลังส่งมอบ ใครรับผิดชอบ?

หากอยู่ในระยะเวลา Warranty ผู้รับจ้างต้องแก้ให้ฟรี แต่หากพ้นระยะเวลาแล้ว ต้องพิจารณาตามข้อตกลงในสัญญา Maintenance (SLA)

12. สัญญาควรครอบคลุมเรื่อง PDPA หรือไม่?

ต้องครอบคลุม โดยต้องมีข้อตกลง DPA (Data Processing Agreement) เพื่อให้ผู้รับจ้างมีมาตรการรักษาความปลอดภัยของข้อมูลผู้ใช้แอปตามกฎหมาย

13. การขอเพิ่มฟีเจอร์ (Change Request) จัดการในสัญญาอย่างไร?

สัญญาต้องระบุกระบวนการ Change Order ว่าหากสเปกเปลี่ยนจากเดิม ต้องมีการประเมินต้นทุนและระยะเวลาใหม่เป็นลายลักษณ์อักษรก่อนเริ่มทำ

14. Uptime 99.9% หมายความว่าอย่างไร?

หมายความว่าใน 1 ปี ระบบมีสิทธิ์ล่มได้ไม่เกิน 8.76 ชั่วโมง หากเกินกว่านี้ผู้ให้บริการคลาวด์หรือผู้ดูแลต้องชดเชยตามเงื่อนไข (Penalty)

15. จะเกิดอะไรขึ้นถ้า Uptime ต่ำกว่า SLA ที่กำหนด?

ปกติสัญญาจะระบุให้มีการชดเชยเป็นเครดิตเงินคืน (Service Credit) หรือลดค่า MA ในรอบบิลถัดไป ตามสัดส่วนเปอร์เซ็นต์ที่ระบบล่มเกินกำหนด

16. Response Time และ Resolution Time ต่างกันอย่างไร?

Response Time คือเวลาที่ทีมรับทราบเรื่องและเริ่มตรวจสอบปัญหา ส่วน Resolution Time คือกรอบเวลาสูงสุดที่ต้องแก้ไขปัญหานั้นให้ระบบกลับมาใช้งานได้

17. การส่งมอบ Source Code ต้องให้อะไรบ้าง?

ต้องให้ Code ที่ไม่ผ่านการ Obfuscate (ทำให้อ่านไม่ออก), โครงสร้าง Database Schema, ไฟล์ภาพต้นฉบับ, กุญแจ API และสคริปต์การ Deploy

18. หากผู้รับจ้างใช้ Open Source จะมีผลทางกฎหมายไหม?

มีผลมาก หากผู้รับจ้างใช้ Code ที่ติด License ประเภท GPL อาจทำให้บริษัทของคุณต้องเปิดเผย Source Code ของแอปสู่สาธารณะ สัญญาจึงต้องห้ามเรื่องนี้

19. ข้อกำหนดเรื่องทรัพย์สินทางปัญญา (IP) ครอบคลุมอะไรบ้าง?

ครอบคลุม Source code, Object code, UX/UI Design, อัลกอริทึม, ฐานข้อมูล และกราฟิกที่ถูกสร้างขึ้นเพื่อโปรเจกต์นี้โดยเฉพาะ

20. ควรมีข้อตกลงเรื่อง Security Audit หรือไม่?

แอปพลิเคชันระดับองค์กรหรือแอปการเงิน ควรระบุในสัญญาให้มีการทำ Penetration Testing (Pen-Test) ก่อนนำขึ้น Store เสมอเพื่อหาช่องโหว่

21. สัญญาที่ดีต้องระบุเรื่องการนำแอปขึ้น Store (Apple/Google) ไหม?

ต้องระบุ ว่าผู้รับจ้างมีหน้าที่รับผิดชอบกระบวนการ Submit App จนกว่าจะผ่านการอนุมัติ (Approve) และแก้ไขหากถูก Reject จากฝั่ง Apple/Google

22. ข้อมูลผู้ใช้ในแอป (User Data) เป็นของใคร?

User Data เป็นกรรมสิทธิ์ของผู้ว่าจ้างแต่เพียงผู้เดียว ผู้รับจ้างไม่มีสิทธิ์นำข้อมูลไปวิเคราะห์ หรือขายให้บุคคลที่สามเด็ดขาด

23. ค่าใช้จ่ายแอบแฝง (Hidden Costs) ที่ควรระวังมีอะไรบ้าง?

ค่า Cloud Server (AWS, Google Cloud), ค่าบริการ Third-party API (เช่น SMS OTP, Google Maps), ค่าต่ออายุ Apple Developer Program รายปี

24. สัญญา Escrow Source Code คืออะไร?

คือการนำ Source Code ไปฝากไว้กับคนกลาง หากบริษัทรับทำแอปล้มละลาย คนกลางจะส่งมอบ Code ให้เรา เพื่อให้ระบบดำเนินต่อไปได้ (ใช้กับโปรเจกต์ยักษ์ใหญ่)

25. การพิจารณาใบเสนอราคา (Quotation) ต้องดูเงื่อนไขใดควบคู่กับสัญญา?

ต้องตรวจสอบสเปก (Specs) ในใบเสนอราคาให้ตรงกับ Scope of Work ในสัญญาแบบคำต่อคำ และดูหมวด Exclusions (สิ่งที่ไม่รวมในราคา) เพื่อระวังงบบานปลาย

26. จะยกเลิกสัญญากลางคันได้ในกรณีใดบ้าง?

สัญญาควรมีช่องทาง (Termination Clause) ให้ยกเลิกได้หากผู้รับจ้างส่งงานล่าช้ากว่ากำหนดเกิน X วัน หรือละเมิดข้อกำหนดเรื่องความลับ (NDA) ร้ายแรง

27. ค่าปรับกรณีส่งงานล่าช้า (Penalty) ควรตั้งไว้ที่เท่าไหร่?

โดยทั่วไปมักตั้งค่าปรับอยู่ที่ 0.1% – 0.2% ของมูลค่าสัญญาต่อวันที่มีการล่าช้า (แต่รวมแล้วสูงสุดไม่เกิน 10% ของมูลค่างานทั้งหมด)

28. สัญญาควรระบุเวอร์ชันของ OS ที่รองรับหรือไม่?

จำเป็นมาก เช่น ระบุว่าแอปต้องรองรับ iOS 15 ขึ้นไป และ Android 12 ขึ้นไป เพื่อไม่ให้เกิดปัญหาแอปเด้งในมือถือรุ่นใหม่ๆ ของผู้ใช้งาน

29. กรณีมี Third-party API ล่ม ใครต้องรับผิดชอบ?

ปกติผู้รับทำแอปจะไม่รับผิดชอบระบบของ Third-party (เช่น Facebook Login ล่ม) แต่ใน SLA ต้องระบุว่าทีมซัพพอร์ตต้องเข้ามาตรวจสอบและยืนยันสาเหตุให้โดยเร็ว

30. หากจ้าง สแตรทตันซอฟท์เทค จะได้รับสัญญาและ SLA ระดับไหน?

เรามอบสัญญาระดับสากล (Enterprise Standard) ส่งมอบ Source Code 100% พร้อมบริการ SLA ตลอด 24/7 เพื่อให้แอปพลิเคชันของคุณเติบโตได้อย่างมั่นคง ปลอดภัยไร้กังวล

สร้างแอปพลิเคชันอย่างมั่นใจ ปราศจากความเสี่ยงทางกฎหมาย

ให้ บริษัท สแตรทตันซอฟท์เทค จำกัด เป็นพาร์ทเนอร์ด้านเทคโนโลยีของคุณ
เราเชี่ยวชาญการออกแบบสถาปัตยกรรมซอฟต์แวร์ และมีความโปร่งใสด้านสัญญา 100%

เยี่ยมชมเว็บไซต์ของเราเพื่อดูผลงาน

อ้างอิงข้อมูลทางกฎหมายและมาตรฐานสากล (External Authority):
– มาตรฐาน ISO/IEC 27001 ด้านระบบบริหารจัดการความมั่นคงปลอดภัยสารสนเทศ
– พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA) แห่งประเทศไทย

สัญญาจ้างทำแอป SLA รับทำแอป App Development Contract Service Level Agreement Source Code Ownership รับทำ Mobile Application รับทำแอป Android และ iOS Stratton Softech Bidding and Quotation PDPA DPA Agreement