SYNERRY Enterprise Platform Engine — เบื้องหลังการสร้างระบบใหม่ทั้งหมด

บทความนี้เหมาะกับ:ผู้บริหาร / หัวหน้าทีม / เจ้าของธุรกิจ IT ที่กำลังจะยกเครื่องระบบเก่า

เวลาอ่าน:25 นาที

TL;DR — Key Takeaways

• Full story behind building SYNERRY Enterprise Platform Engine from scratch
• Team feedback from 15 people drove the architecture decisions
• Tech stack selection: reasoning behind every choice (Monorepo, CI/CD, Design System)
• Foundation phase: how the first infrastructure was laid

ระดับ:กลาง-ขั้นสูง

Category:Behind-the-Scenes / Business + AI

Funnel Level:2-TRUST (เล่าเรื่องจริง ปัญหาจริง)

โครงสร้างเนื้อหาทั้งหมด (สารบัญ)

1. จุดเริ่มต้น
   1.1 ปัญหาที่ทีมเล่าให้ฟัง — Survey ทีม Dev 7 คน
   1.2 หาข้อมูล — จะเลือกอะไร ใช้อะไร เพราะอะไร
2. เริ่ม Build ระบบ
   2.1 Tech Stack ที่ตัดสินใจเลือก — เหตุผลทุกข้อ
   2.2 วาง Foundation — Monorepo, CI/CD, Design System
3. [เมนูถัดไป — ยังไม่เขียน]
...

1. จุดเริ่มต้น

ระบบเก่าของ SYNERRY รับภาระไม่ไหว — ทีม 7 คนรายงานปัญหา 14 หมวด รวมถึง SQL Injection และไม่มี automated testing แม้แต่ตัวเดียว ต้องสร้างใหม่ทั้งระบบ

ไม่ได้นั่งเดาว่าปัญหาคืออะไร — ให้ทีมบอกเอง เพราะพวกเขาคุยกับลูกค้า คุยกับ code ทุกวัน พวกเขารู้ดีกว่าว่าอะไรพัง อะไรใช้เวลานาน อะไรทำให้ลูกค้าโกรธ

แล้วพอปัญหาชัด ก็ต้องตอบคำถามที่ยากกว่า — จะแก้ด้วยอะไร?

ไม่ใช่แค่เลือก framework ใหม่มาใส่ แต่ต้องมองทั้งภาพ — architecture ที่วางมาดีพอไหม? security ผ่านมาตรฐานไหม? ทีมพร้อมเปลี่ยนตัวเองไหม? งบพอไหม?

Feedback จากทีม 15 คน คือจุดเริ่มต้นที่แท้จริงของ architecture ทั้งหมด

1.1 ปัญหาที่ทีมเล่าให้ฟัง

ส่ง survey ให้ทีม dev ทั้ง 7 คน พบปัญหากว่า 40 จุดใน 14 หมวด — ตั้งแต่ SQL Injection (5 คนรายงาน) จนถึงไม่มี CI/CD ข้อมูลจริงจาก Ohm, Mart, tar, bat, ten, pun, Oum

คำถามง่ายมาก:"อะไรที่ทำให้คุณปวดหัวที่สุดในการทำงาน?"

ไม่ได้ถามแค่คนเดียว เพราะคนที่เห็นปัญหาคนละจุดกัน — backend dev เห็นอีกแบบ frontend dev เห็นอีกแบบ คนที่อยู่กับลูกค้าเห็นอีกแบบ

ผลลัพธ์?ปัญหาทั้งหมดประมาณ 40 รายการจัดกลุ่มได้14 กลุ่มหลัก

พูดตรงๆ — ตกใจ ไม่ใช่เพราะมีปัญหาเยอะ (ระบบเก่าทุกที่มี) แต่เพราะหลายปัญหาเป็นเรื่องพื้นฐานที่ควรแก้ตั้งนานแล้ว

ภาพรวมปัญหาทั้ง 14 กลุ่ม

สิ่งที่ทำให้ตกใจ

ไม่ใช่จำนวนปัญหา — ระบบเก่าทุกที่มีปัญหาเยอะ นั่นปกติ

สิ่งที่ตกใจคือ5 คนจาก 7 คนพูดเรื่องเดียวกัน — SQL Injection

SQL Injection ไม่ใช่ปัญหาใหม่ มันเป็นช่องโหว่ที่รู้กันมาตั้งแต่ปี 1998 แต่ระบบยังมีอยู่ หลายจุด ไม่ใช่จุดเดียว

Ohm, tar, bat, ten, pun — ทุกคนพูดตรงกันว่า "หลายส่วนของระบบมีความเสี่ยง" ผลกระทบ? ข้อมูลลูกค้าอาจถูกเข้าถึงโดยไม่ได้รับอนุญาต แย่กว่านั้น — อาจต้องพัฒนาใหม่ทั้งหมด

แค่ข้อแรกก็หนักพอแล้ว

แต่ปัญหา Security ไม่ได้มีแค่ SQL Injection

Content Security Policy (CSP) ก็ไม่มี — อีก 5 คนรายงานเหมือนกัน Dependency เก่าที่ไม่เคย scan อีก 5 คน Cookie ที่ JavaScript อ่านได้ (httpOnly: false), IIS ที่มีช่องโหว่ Backdoor, ไม่มี Security Headers, ไม่ check file upload header จริงๆ, Authentication ที่ไม่มี 2FA

รวมปัญหา security ทั้งหมด?3 กลุ่มหลัก ทุกกลุ่มมีคนรายงาน 3-5 คน

ระบบเก่าไม่ใช่แค่ "เก่า" — มันอันตราย

ปัญหาที่ทำให้ทีมทำงานช้า

Security เป็นเรื่องเร่งด่วน แต่ปัญหาที่กินเวลาทีมทุกวันคืออีกกลุ่มหนึ่ง

"code เก่าไม่ได้ใช้แต่ไม่กล้าลบเพราะกลัวพัง"

ประโยคนี้จาก bat สรุปปัญหาได้ดีที่สุด — ทีมอยู่ในสถานะที่กลัวจะแก้อะไรเพราะไม่รู้ว่าถ้าแก้แล้วอะไรจะพังตาม

ไม่มี test ไม่มี monitoring ไม่มี audit log — เท่ากับบินโดยไม่มีเรดาร์

Deploy แล้วพัง? ไม่มี rollback strategy Mart คนเดียวที่รายงานข้อนี้ แต่คิดว่ามันสำคัญมาก เพราะถ้าระบบล่มบน production แล้วกู้กลับไม่ได้ — ทุกอย่างที่สร้างก็ไร้ค่า

สิ่งที่เรียนรู้จาก survey นี้

ปัญหาจัดกลุ่มได้เป็น 3 ชั้น:

ปัญหาชัดแล้ว คำถามถัดมาก็คือ — แล้วจะแก้ด้วยอะไร?

ไม่ได้แค่ patch ทีละจุด ต้องออกแบบระบบใหม่ตั้งแต่ต้น

แต่ก่อนจะเลือกเทคโนโลยี ต้องรู้ก่อนว่าสิ่งที่วางไว้ มันมีจุดอ่อนตรงไหน

ปัญหาไม่ใช่เทคโนโลยี — แต่คือการที่ทุกคนมองระบบคนละมุม

1.2 หาข้อมูล — จะเลือกอะไร ใช้อะไร เพราะอะไร

หลังจากระบุปัญหา 14 หมวด เปรียบเทียบ framework, architecture, และแนวทาง security อย่างเป็นระบบ — ตรวจสอบกับ pain point จริงของทีมก่อนเลือก

ให้ AI ช่วยวิเคราะห์ Spec ที่ร่างไว้ — SYNERRY Enterprise Platform Engine — โดยตั้ง 4 บทบาทขึ้นมาตรวจ:

ผลวิเคราะห์ออกมาหนัก — พบจุดอ่อน20 จุดแบ่งเป็น 8 จุดวิกฤต, 6 จุดค่อนข้างสูง, 6 จุดปานกลาง

พูดตรงๆ — Spec ที่ร่างมามี ambition สูงกว่าที่ทีมจะ deliver ได้

นี่คือ 5 จุดอ่อนที่ทำให้ต้องหยุดคิดใหม่ทั้งหมด

จุดอ่อนที่ 1: "เปลี่ยน DB แค่แก้ .env" — ฝันสวยที่ทำไม่ได้

Spec เขียนว่า "เปลี่ยน Database แค่แก้ .env — DATABASE_PROVIDER=postgresql หรือ mysql, sqlserver"

ฟังดูดี. ขายลูกค้าได้. แต่ความจริง?

การตัดสินใจ:ลด DB support เหลือPostgreSQL (default) + MySQL (legacy)เท่านั้น Oracle, MSSQL — เพิ่มทีหลังเมื่อมีลูกค้าจริงที่ต้องการ ไม่ใช่สร้างไว้ "เผื่อ"

ลด test matrix ไป 60%. ลดงาน maintenance ไปมหาศาล. ไม่ต้อง maintain 2 ORM layers.

ขายน้อยลง แต่ deliver ได้จริง — ว่าดีกว่า

จุดอ่อนที่ 2: Branch-per-Project = Merge Hell

Spec วางไว้ว่าใช้ monorepo แล้วแตก branch ตามโครงการ:

main          -> Engine core (stable)
project/rid   -> RID customizations
project/cgd   -> CGD customizations

แล้ว cherry-pick core updates ไปทุก project branch

ฟังดูเข้าท่า — จนกว่าจะมี 10+ projects

จุดอ่อนที่ 3: ทีมถนัด Vue แต่ Spec เลือก React

นี่เป็นจุดที่ทำให้คิดหนักที่สุด

ทีมใช้Nuxt 3 (Vue.js)มาทุกโครงการ มี codebase, patterns, components สะสมมา ทุกคนถนัด Vue ecosystem — Pinia, VueUse, Nuxt modules

แต่ Spec เลือกNext.js (React)

timeline 12 สัปดาห์ + ทีมต้องเรียน React ใหม่ = สูตรสำเร็จสำหรับความล้มเหลว

มี 2 ทางเลือก:

1. Training 4 สัปดาห์ก่อนเริ่ม Sprint 1 — แต่เสียเวลา
2. คงไว้เป็น Nuxt 3 — ทีมถนัดอยู่แล้ว ทำงานได้เต็มประสิทธิภาพตั้งแต่วันแรก

จุดอ่อนที่ 4: Timeline 12 สัปดาห์ไม่จริง

ลองนับจริงๆ ว่าต้องสร้างอะไรบ้าง:

ตัวเลขไม่โกหก ขาดอีก27-58 man-weeks — ไม่ใช่ขาดนิดหน่อย ขาดเกือบเท่าตัว

ทางออก?แบ่ง Phase

• Phase 1 (16 สัปดาห์): CMS + Auth + Search + Admin + Design System + CI/CD
• Phase 2 (8 สัปดาห์): Workflow + Report + Migration + AI

ไม่ใช่ส่งทีหมดแล้วทุกอย่างห่วย — ส่งทีละ phase แต่ทุก phase ต้องใช้ได้จริง

จุดอ่อนที่ 5: จุดอ่อนด้าน Security ของ Spec เอง

ยิ่งดูยิ่งพบว่า Spec ที่ร่างมา ยังมีช่องโหว่ security เหมือนกัน — ไม่ต่างจากระบบเก่า

จุดอ่อนทั้ง 20 จุด — สรุปรวม

5 สิ่งที่ต้องแก้ก่อนลงมือ build

จากจุดอ่อน 20 จุด สรุปเป็น 5 สิ่งที่ต้องตัดสินใจก่อนเขียน code บรรทัดแรก:

บทเรียนจากขั้นตอนนี้

การวิเคราะห์จุดอ่อนไม่ใช่เรื่องสนุก มันเจ็บ เพราะหลายอย่างที่คิดว่า "โอเค" มันไม่โอเคเลย

แต่เจ็บตอนวิเคราะห์ ดีกว่าเจ็บตอน deploy

สิ่งที่เรียนรู้:

• อย่าขายสิ่งที่ deliver ไม่ได้ — Multi-DB 5 ตัว ฟังดูดี แต่ maintain ไม่ไหว ลดเหลือ 2 แล้วทำให้ดี ดีกว่า
• ถามทีมก่อนตัดสินใจ — ทีมถนัด Vue แต่ Spec เลือก React ทำไม? เพราะ "เทรนด์" หรือเพราะ "ทำงานได้ดีกว่า"?
• ตัวเลขไม่โกหก — 75-106 man-weeks กับ 48 man-weeks ที่มี ตัวเลขบอกหมดว่า timeline 12 สัปดาห์ไม่จริง
• Security ต้องคิดตั้งแต่วันแรก — ไม่ใช่ "เดี๋ยวค่อยเพิ่มทีหลัง"

2. เริ่ม Build ระบบ

ปัญหาชัดแล้ว จุดอ่อนเห็นแล้ว ถึงเวลาตัดสินใจ

ไม่ได้นั่งตัดสินใจคนเดียว — ให้ AI ช่วยวิเคราะห์ เปรียบเทียบ หา trade-off แต่สุดท้ายคนตัดสินใจคือเพราะรู้บริบทของทีม ของลูกค้า ของงบ — สิ่งที่ AI ไม่มีทางรู้แทนได้

Tech Stack ที่ดีที่สุดคือตัวที่ทีมใช้งานได้จริง ไม่ใช่ตัวที่ trending

2.1 Tech Stack ที่ตัดสินใจเลือก — เหตุผลทุกข้อ

การเลือก Tech Stack ยึดกฎ 3 ข้อ — ให้ทีมพร้อมใช้งานจริง, security-first, และเลือก tools ที่พิสูจน์แล้วมากกว่า trending แต่ละตัวมีเหตุผลครบถ้วน

1. ทีมต้องทำงานได้ตั้งแต่วันแรก — ไม่ใช่เรียน 3 เดือนแล้วค่อยเริ่ม
2. ลูกค้าต้องได้ของจริง ไม่ใช่ demo — ทุก feature ที่ขายต้อง deliver ได้
3. ไม่สร้าง "เผื่อ" — สร้างสิ่งที่ต้องใช้ตอนนี้ เพิ่มทีหลังเมื่อต้องการจริง

จากกฎ 3 ข้อนี้ ทุก technology ที่เลือก มีเหตุผลชัดเจน

Frontend: ทำไมถึงเลือก Next.js — ทั้งที่ทีมถนัด Vue

พูดตรงๆ — ถ้าสร้างระบบนี้ให้ตัวเองใช้อย่างเดียว จะเลือก Nuxt 3 ไม่คิด

แต่สร้าง Platform Engine ที่จะขายลูกค้า Enterprise ต้องหาคนมาดูแลต่อได้ ต้อง scale ทีม ต้องให้ AI ช่วยเขียน code ได้มากที่สุด

React ชนะตรงนี้. ไม่ใช่เพราะ "ดีกว่า" — แต่เพราะecosystem ใหญ่กว่า

Backend: NestJS — ตัวเดียวที่ตอบโจทย์

ตัดสินใจตรงนี้ไม่ยาก — NestJS เป็น TypeScript เหมือน Next.js ทีมเขียนภาษาเดียวทั้ง frontend + backend ไม่ต้องสลับ mental model

ส่วนPython AI Module ที่ Spec เดิมวางไว้? ตัดออกVercel AI SDK ทำได้ทุกอย่าง — OpenAI, Claude, Gemini — จาก TypeScript โดยตรง ไม่ต้องเพิ่ม Python เข้ามาให้วุ่น

Admin Panel: Refine — ไม่ build จากศูนย์

ตรงนี้คือจุดที่ประหยัดเวลาได้มหาศาล

Payload CMS 3.0 ดีมาก (GitHub stars เยอะกว่า Refine ด้วยซ้ำ) แต่มันเป็น backend ในตัว — ถ้าใช้ Payload ก็ไม่ต้อง NestJS ซึ่งขัดกับ architecture ที่วางไว้

Refine ตอบโจทย์ตรงกว่า — เป็น headless framework ต่อกับ NestJS backend ที่มีอยู่ ประหยัดเวลาไป15-20 man-weeks

Full Stack ที่เลือก — ภาพรวม

สิ่งที่ตัดออก — สำคัญเท่ากับสิ่งที่เลือก

ตัดออก 5 อย่าง ลด complexity ลง 40%

ไม่ใช่ "ลดคุณภาพ" — แต่ "ลดสิ่งที่ไม่จำเป็น" ทุกอย่างที่ตัดออกสามารถเพิ่มกลับมาทีหลังได้ถ้ามีลูกค้าต้องการจริง

2.2 วาง Foundation — Monorepo, CI/CD, Design System

Tech Stack เลือกแล้ว ขั้นตอนถัดมาคือวาง foundation ก่อนเขียน feature แม้แต่บรรทัดเดียว

เปรียบเทียบขั้นตอนนี้กับการสร้างบ้าน — ถ้าฐานรากไม่ดี ต่อให้ตกแต่งสวยแค่ไหน สุดท้ายก็พัง

สัปดาห์ที่ 1-2: Monorepo Setup

synerry-engine/
|
|-- apps/
|   |-- web/          # Next.js 15 — Public website
|   |-- admin/        # Refine v5 — Admin panel
|   |-- api/          # NestJS — Backend API
|
|-- packages/
|   |-- @engine/ui/          # Design System (shadcn/ui)
|   |-- @engine/config/      # Shared config (ESLint, TS, Tailwind)
|   |-- @engine/auth/        # Auth module (JWT, RBAC, MFA)
|   |-- @engine/cms/         # CMS module (content types, workflow)
|   |-- @engine/db/          # Prisma schema + migrations
|   |-- @engine/search/      # Search integration (Meilisearch)
|   |-- @engine/file/        # File storage (MinIO/S3)
|   |-- @engine/ai/          # AI module (Vercel AI SDK)
|
|-- docker/
|   |-- docker-compose.yml   # Local dev environment
|   |-- docker-compose.prod.yml
|
|-- .github/
|   |-- workflows/           # CI/CD pipelines
|
|-- turbo.json               # Turborepo build orchestration
|-- pnpm-workspace.yaml

สิ่งที่ต่างจาก Spec เดิม — ไม่ใช้branch-per-projectอีกแล้ว

แต่ละ package ใน packages/ จะถูก publish เป็น versioned npm package ไปที่ GitLab Package Registry เมื่อโครงการใหม่เข้ามา แค่ npm install @engine/[email protected] — ไม่ต้อง cherry-pick ไม่ต้อง merge

สัปดาห์ที่ 1-2: CI/CD Pipeline

ก่อนเขียน code บรรทัดแรก ต้องมี pipeline ที่จับ bug ให้ก่อนถึง production

จำได้ไหม? ปัญหาข้อ #10 จาก survey — "ไม่มี testing pipeline, ไม่มี SAST scan, bug หลุดเข้า production บ่อย"

Pipeline นี้แก้ตรงจุดนั้น ทุก push ต้องผ่าน 5 ด่าน ถ้า fail ด่านไหนก็ merge ไม่ได้ ง่ายมาก

สัปดาห์ที่ 2: Design System Foundation

สัปดาห์ที่ 1-2: Security Foundation

ก่อนจะเขียน feature ต้องวาง security foundation ให้เรียบร้อย — แก้ปัญหาที่ทีมรายงานตั้งแต่แรก

Timeline Phase 1 — แผนจริงที่ทำได้จริง

บทเรียนจากการวาง Foundation

สัปดาห์แรกไม่ได้เขียน feature เลยแม้แต่บรรทัดเดียว ทั้ง 2 สัปดาห์ไปกับ monorepo, CI/CD, Docker, security headers, design tokens

ทีมบางคนอาจรู้สึกว่า "ทำไมไม่เริ่มเขียน code สักที?"

แต่รู้ว่า — ถ้าฐานไม่ดี เดี๋ยวก็ต้องมาทุบทำใหม่ เสียเวลามากกว่า

เหมือนสร้างบ้าน ถ้าเทฐานรากไม่ดี ต่อให้ตกแต่งสวยแค่ไหน สุดท้ายก็ร้าว

ต่อในเมนูถัดไป: เริ่มเขียน feature จริง — CMS, Auth, Admin Panel และ Cursor + AI เข้ามาช่วยตรงไหน

สรุป Blog Structure ที่วางไว้:

>

เมนูหลัก 1: จุดเริ่มต้น-- เสร็จ

- 1.1 ปัญหาที่ทีมเล่าให้ฟัง

- 1.2 หาข้อมูล — จะเลือกอะไร ใช้อะไร เพราะอะไร

>

เมนูหลัก 2: เริ่ม Build ระบบ-- เสร็จ

- 2.1 Tech Stack ที่ตัดสินใจเลือก — เหตุผลทุกข้อ

- 2.2 วาง Foundation — Monorepo, CI/CD, Design System

>

เมนูหลัก 3+: รอวางโครงสร้างเพิ่ม