สรุปและฝึกปฏิบัติ

ประเด็นสำคัญที่ควรจำ

• การ ship คือ workflow ไม่ใช่ช่วงเวลาเดียว: deploy สังเกต ปะแก้ ทำซ้ำ — และทำให้ rollback เป็นสิ่งที่คุณเคยทดสอบมาแล้ว
• รันรายการตรวจสอบก่อนเปิดตัวก่อนที่คุณจะประกาศอะไรก็ตาม และให้ AI ตรวจสอบแต่ละรายการแทนที่จะเชื่อความจำของตัวเอง
• ให้การวัดผลเป็นตัวขับเคลื่อนการปรับแต่ง — รายงาน Lighthouse ชนะการเดาว่าอะไร "รู้สึก" ช้าเสมอ
• ความลับอยู่ในคอนฟิกของ production เท่านั้น ไม่เคยอยู่ในรีโพ .env อยู่ใน gitignore และ .env.example เป็นปัจจุบันเสมอ
• เวอร์ชันแรกคือสมมติฐาน ผู้ใช้จริงคือการทดลอง ดังนั้นให้ทำซ้ำด้วยการแก้ไขเล็ก ๆ ที่รวดเร็ว

ลองทำดู

หยิบแอปที่คุณ deploy ไว้แล้ว (หรือ deploy อันเล็ก ๆ ขึ้นมาตอนนี้เลย) แล้วรันรายการตรวจสอบก่อนเปิดตัวทั้งหมดกับมันทีละบรรทัด สำหรับทุกช่องที่คุณติ๊กไม่ได้อย่างสัตย์จริง วางรายการที่ล้มเหลวนั้นให้ AI ดูแล้วขอการเปลี่ยนแปลงที่เล็กที่สุดที่จะปิดช่องว่างนั้น ปิดท้ายด้วยการคลิก deep link บนเว็บไซต์จริง — ไม่ใช่แค่หน้าแรก — เพื่อยืนยันว่า production ทำงานเหมือนกับ dev

พรอมป์ประจำบท

Here is my deployed app and its stack: [describe app + hosting + services].
Act as my launch reviewer. Walk this pre-launch checklist item by item
and, for each, tell me how to verify it on the LIVE site (not in dev):
- production URL loads over valid HTTPS on the custom domain
- all secrets set in production; none committed to the repo
- core happy path (sign-up, login, main action) works in production
- payments tested end-to-end including the webhook (if any)
- error tracking and uptime monitoring are live
- I can roll back, and have tested it once
- mobile layout works on a real phone
- database backups are enabled
For every item that fails, give me the SMALLEST change that fixes it.
Do not assume anything passes — make me prove each one.