Rekap dan Latihan

Poin-poin kunci

• Merilis adalah sebuah alur kerja, bukan sebuah momen: deploy, amati, tambal, ulangi — dan jadikan rollback sesuatu yang sudah pernah kamu uji.
• Jalankan daftar periksa pra-peluncuran sebelum mengumumkan apa pun, dan minta AI memverifikasi setiap butir alih-alih mengandalkan ingatanmu.
• Biarkan pengukuran mengarahkan optimasi — sebuah laporan Lighthouse selalu mengalahkan dugaan tentang apa yang "terasa lambat".
• Secret hidup di konfigurasi produksi, tidak pernah di repo; .env masuk gitignore dan .env.example tetap mutakhir.
• Versi pertama adalah sebuah hipotesis; pengguna sungguhan adalah eksperimennya, jadi beriterasilah dengan perbaikan kecil dan cepat.

Coba sendiri

Ambil aplikasi yang sudah kamu deploy (atau deploy satu yang kecil sekarang) dan jalankan seluruh daftar periksa pra-peluncuran terhadapnya baris demi baris. Untuk setiap kotak yang tidak bisa kamu centang secara jujur, tempelkan butir yang gagal itu ke AI dan minta perubahan terkecil yang menutup celahnya. Selesaikan dengan mengeklik sebuah deep link di situs yang hidup — bukan cuma halaman utama — untuk memastikan produksi berperilaku seperti dev.

Prompt bab ini

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.