การสร้าง Super App ไม่ได้ยากเพราะต้องมีฟีเจอร์จำนวนมาก
แต่ยากกว่า เพราะฟีเจอร์เหล่านั้นมาจากคนละทีม มีเป้าหมายธุรกิจต่างกัน มีจังหวะ release ต่างกัน และบางทีทำงานอยู่บนอุปกรณ์หลายรุ่นพร้อมกัน
เมื่อ Muze เข้าไปทำงานกับ TrueID ซึ่งต้องรองรับ 20M+ Monthly Active Users และมี Business Unit มากกว่า 20 ทีม บน ecosystem เดียวกัน โจทย์จริงๆ จึงไม่ใช่ “ทำฟีเจอร์ให้ครบ” แต่คือ “ออกแบบโครงสร้างให้ทุกทีมโตได้โดยไม่ทำระบบพัง”
Scale ที่ทำให้การตัดสินใจเปลี่ยนไปโดยสิ้นเชิง
| Dimension | Scale / Challenge |
|---|---|
| User Scale | 20M+ Monthly Active Users |
| Business Units | 20+ BU บน ecosystem เดียวกัน |
| Platform Coverage | Mobile App + Android TV Launcher (Gen 1–3) |
| Region Support | Multi-Region ด้วย Feature Toggle |
| High Concurrency | Live event ระดับ 1M+ concurrent viewers (เช่น World Cup) |
| Content Operation | CMS-driven Shelf & JSON-based Layout |
| Integration | Netflix entitlement, TMN Payment, TikTok Beans, True membership |
ตัวเลขเหล่านี้ไม่ใช่แค่ achievement ที่น่าประทับใจ แต่มันเปลี่ยน decision ทุกอย่าง ตั้งแต่ architecture ไปจนถึงวิธีที่ Muze เลือก approach ในแต่ละปัญหา
ปัญหาจริงคือ “20 ทีมอยู่ในบ้านหลังเดียวกัน”
ก่อนจะเริ่มเขียน code บรรทัดแรก สิ่งที่ต้องทำความเข้าใจคือ TrueID ไม่ใช่แอปธรรมดา มันคือ digital platform ที่ต้องรองรับ Streaming, Music, Games, News และ True Services ภายใต้ branding เดียว
แต่ละ BU อยากเปิด campaign ของตัวเอง อยากปรับ content ให้เหมาะกับ region ของตัวเอง และอยาก move ได้เร็วตาม business priority ของตัวเอง ในขณะที่ผู้ใช้ต้องรู้สึกว่าแอปนี้ลื่นไหลและเป็นหนึ่งเดียว
ถ้าปล่อยให้แต่ละ BU จัดการ code ของตัวเองโดยไม่มีโครงสร้างกลาง ผลคือ monolithic app ที่ยิ่งโตยิ่งคุมไม่ได้ — เพิ่มฟีเจอร์ใหม่ทีไรเสี่ยงกระทบทั้งระบบทุกที
นี่คือ core problem ที่ Muze ต้องแก้
Skeleton-First: Muze ไม่ได้เริ่มจากฟีเจอร์
แนวทางของ Muze คือการเริ่มจาก App Skeleton ก่อน แทนที่จะถามว่า “แต่ละ BU ต้องการฟีเจอร์อะไร” เราถามก่อนว่า
“แอปนี้ควรมีโครงสร้างกลางแบบไหน เพื่อให้ BU ต่างๆ เสียบ feature ของตัวเองเข้ามาได้ โดยไม่ทำให้ codebase แตกกระจาย?”
Skeleton ในที่นี้ครอบคลุม navigation structure, shelf engine, CMS integration, authentication layer, feature toggle, payment integration, entitlement logic, design system และ module boundary ระหว่าง service
เมื่อ Skeleton แข็งแรง การเพิ่ม BU ใหม่จะไม่ใช่การต่อเติมแบบเฉพาะกิจ แต่เป็นการเสียบ module เข้าโครงสร้างที่รองรับไว้แล้ว
3 Technical Decisions ที่ Muze เลือกและทำไม
1. 32-bit APK เพื่อรองรับทุก Hardware Generation
TrueID TV Box มี 3 generations ที่ capability ต่างกันมาก ตั้งแต่กล่อง Gen 1 ที่ spec จำกัด ไปจนถึง Gen 3 ที่มี AI และ Camera
ทางเลือกหนึ่งคือสร้าง APK แยกตามรุ่น ซึ่งฟังดูง่ายแต่หมายถึง maintenance cost ที่ซ้ำซ้อนตลอดชีวิตของโปรเจกต์
Muze เลือก build เป็น 32-bit APK เดียว ที่รองรับได้ทุก generation เหตุผลหลักคือ codebase เดียว = test path เดียว = deployment เดียว และลดความเสี่ยงที่ feature จะทำงานต่างกันบน device ต่างรุ่น
trade-off คือต้องออกแบบ performance layer ให้ทำงานดีบนทั้ง spec ต่ำและ spec สูง ซึ่งทำได้ด้วย feature detection และ adaptive rendering แทนการ hardcode ตาม device version
2. JSON-Driven UI + Firebase Remote Config แทนการรอ App Release
โจทย์ที่ยากของ Super App คือทีม business ต้องการเปลี่ยน layout, เปิด campaign, หรือปรับ content ให้เหมาะกับ region ได้เร็ว — โดยไม่ต้องรอ cycle การ submit app ไป store
Muze ออกแบบ Home Page ให้ใช้ JSON Skeleton Structure เป็นตัวกำหนด layout ซึ่งอ่านจาก backend ตอน runtime แทนที่จะ hardcode อยู่ใน app ควบคู่กับ Firebase Remote Config สำหรับควบคุม feature availability ตาม hardware generation และ region
ผลคือทีม business สามารถเปลี่ยน shelf, hero, grid, หรือเปิด/ปิด feature ได้จาก CMS โดยไม่ต้อง trigger app release ทุกครั้ง
สิ่งที่ต้องระวังคือ JSON-Driven UI มีความเสี่ยงด้าน consistency ถ้าไม่มี guardrail ดีพอ — Muze จึงออกแบบ schema validation ที่ CMS level เพื่อป้องกันไม่ให้ layout ที่ invalid ไปถึง production
3. Adapter Pattern สำหรับ Auth และ Payment หลายเจ้า
TrueID ต้องเชื่อมกับ payment provider หลายราย เช่น True Money (TMN) และ TikTok Beans รวมถึง entitlement system ของ Netflix และระบบสมาชิกของ True เอง
แต่ละ provider มี flow ไม่เหมือนกัน มี token format ต่างกัน และมี error handling ที่แตกต่างกัน ถ้าเอา provider-specific logic เข้าไปผูกกับ core app ตรงๆ ทุกครั้งที่เพิ่ม partner ใหม่หรือเปลี่ยน provider จะกระทบ codebase กลาง
Muze ออกแบบ Abstract Interface สำหรับ Auth และ Payment ที่ core app รู้แค่ว่า “ต้องการ authenticate” หรือ “ต้องการ process payment” โดยไม่รู้รายละเอียดของ provider แต่ละเจ้า — implementation แยกออกไปเป็น adapter ของแต่ละ provider
ผลคือการเพิ่ม payment method ใหม่ทำได้โดยเขียน adapter ใหม่ โดยไม่แตะ core logic เลย
Android TV: ความยากที่ไม่ได้คาดไว้ตั้งแต่แรก
หลายคนคิดว่า TV app คือ mobile app ที่ขยายหน้าจอให้ใหญ่ขึ้น ในความเป็นจริง challenge ต่างกันโดยสิ้นเชิง
บน mobile ผู้ใช้แตะสิ่งที่ต้องการโดยตรง แต่บน TV ผู้ใช้ต้อง navigate ด้วย remote control — ทุก press ขึ้น ลง ซ้าย ขวา ต้องรู้สึกเป็นธรรมชาติ
ปัญหาที่พบจริงในโปรเจกต์นี้คือ Home Shelf ที่มี content หลายประเภท (hero, rail, grid, recommendation) เมื่อ focus เคลื่อนที่ระหว่าง shelf ที่มี layout ต่างกัน cursor มักกระโดดไปผิดตำแหน่ง ทำให้ผู้ใช้รู้สึกว่าแอปตอบสนองไม่ได้เรื่อง
นอกจากนี้ TrueID TV ยังต้องทำงานในระดับ System Launcher ของ Android — ต่างจาก regular app ตรงที่ต้องจัดการ Boot sequence, Splash Screen และการเชื่อมต่อ Hardware ผ่าน AIDL เพิ่มเติม สิ่งเหล่านี้คือ complexity ที่ discovery phase ต้องหาให้เจอก่อน ไม่ใช่ปัญหาที่รอให้เจอตอน development
Discovery-First: ทำไมถึงไม่เริ่มเขียน Code ทันที
ก่อนเริ่ม modernize TrueID TV Launcher Muze ทำ Audit Legacy Codebase อย่างละเอียดทีละ module เพื่อหาว่าอะไรควร reuse อะไรควร replace และอะไรคือ dependency ที่กระทบมากที่สุด
เหตุผลที่ต้องทำ discovery ก่อน: ระบบที่มีผู้ใช้งาน 20M+ MAU ไม่มีพื้นที่สำหรับการ “ลองแล้วค่อยแก้” เหมือน startup — ถ้า migration กระทบ experience กลางอากาศ ผลกระทบวัดเป็นล้านคน
Discovery ที่ดีในกรณีนี้ต้องลงลึกถึง hardware constraint ของแต่ละ device generation, integration point กับ partner ต่างๆ, content delivery path, และ entitlement logic ที่ซ่อนอยู่ในระบบเดิม
บทเรียนที่ชัดที่สุดจากโปรเจกต์นี้คือ ยิ่งระบบใหญ่ ยิ่งไม่ควรรีบเขียน code เพราะ discovery ที่ดีคือ risk mitigation ที่ถูกที่สุด
Lesson Learned: Skeleton ไม่ใช่ Overhead — มันคือ Speed
หลายองค์กรมองว่าการลงทุนใน infrastructure ก่อนทำฟีเจอร์คือการเสียเวลา แต่จากโปรเจกต์ TrueID สิ่งที่เห็นชัดคือ BU ที่ 21, 22, 23 เพิ่มเข้ามาได้รวดเร็วกว่ามาก เพราะโครงสร้างรองรับแล้ว
เทียบกับถ้าไม่มี Skeleton — ทุก BU ใหม่จะต้อง negotiate กับ codebase เดิม และทุก feature ใหม่จะเพิ่ม complexity โดยไม่มีขอบเขต
สำหรับองค์กรที่กำลังสร้าง digital platform: ถ้ามีแผนจะโตเกิน 5 BU ให้ถามตัวเองก่อนว่า architecture วันนี้รองรับการโตนั้นได้ไหม — คำตอบจะบอกว่าควรเริ่ม Skeleton ตั้งแต่เมื่อไหร่
Key Takeaways
- Super App = Infrastructure ไม่ใช่ Feature List — โครงสร้างภายในตัดสินว่า platform จะโตได้แค่ไหน
- 32-bit APK เดียวดีกว่า APK หลายตัว — เมื่อ target device หลาย generation ให้เลือก backward-compatible build เหนือ optimization แยก version
- JSON-Driven UI + Remote Config = business agility โดยไม่ต้อง release cycle ทุกครั้ง
- Adapter Pattern ทำให้การเพิ่ม payment/auth provider ใหม่ไม่กระทบ core
- Android TV ≠ Mobile บนจอใหญ่ — Focus Management และ System Launcher integration คือ engineering domain ที่ต่างกันโดยสิ้นเชิง
- Discovery ก่อน Code — สำหรับระบบที่มี user จำนวนมาก การ audit ก่อน migrate ถูกกว่าการแก้ปัญหาหลัง go-live เสมอ
ดู case studies อื่นของ Muze →
จากประสบการณ์ Muze ในการออกแบบและ modernize TrueID Super App และ Android TV Launcher 2026
