Saya telah menyaksikan tiga orang berbeda salah menangani layar tiga puluh detik yang sama — kartu rencana yang muncul di antara prompt Anda dan proses build — dan masing-masing membayarnya dengan mata uang yang berbeda. Satu membayar dengan rebuild. Satu membayar dengan pengetikan yang sia-sia. Satu membayar dengan produk yang tidak bisa melakukan hal yang sebenarnya mereka butuhkan. Kartu rencana adalah momen termurah dalam seluruh proses untuk mengubah pikiran, dan entah bagaimana justru itulah yang membuatnya mudah dilewatkan begitu saja.
Kesalahan satu: menyetujui tanpa berpikir
Ini yang paling umum. Kerangka terlihat benar, klik setuju, lanjutkan — saya melakukan ini selama berminggu-minggu sebelum akhirnya kena batunya. Build yang akhirnya menghentikan kebiasaan ini kembali dengan checkout Stripe yang terhubung ke situs statis yang tidak punya tempat untuk menyimpan status akun yang dibutuhkan Stripe. Rencana itu sudah menyebutkan jenis produk: situs statis dengan jelas, tepat di kartu itu, dan saya melewatinya begitu saja karena daftar halamannya terlihat baik-baik saja dan saya sedang terburu-buru.
Kerusakan dari kesalahan ini selalu berbentuk sama: segala sesuatu setelah rencana itu benar berdasarkan rencananya, jadi kegagalannya tidak muncul sebagai error, melainkan muncul sebagai build yang berfungsi tapi secara struktural salah. Tidak ada yang menandainya karena tidak ada yang rusak — situs statis dengan tombol checkout hanya melakukan hal yang salah secara diam-diam, atau gagal tepat pada momen pengguna sungguhan menekan "bayar." Anda baru mengetahuinya saat review, tempat paling mahal untuk mengetahuinya.
Kesalahan dua: terlalu detail untuk menghindari putaran kedua
Kesalahan sebaliknya terlihat lebih bertanggung jawab tapi tidak. Sebagian orang, setelah kena kesalahan satu, terlalu berlebihan mengoreksi dengan menulis satu paragraf persyaratan detail di tahap rencana — teks persis, preferensi spasi, fitur apa yang pasti harus ada dan tidak boleh ada, ditulis seperti dokumen spesifikasi. Saya juga pernah melakukan ini, karena kekhawatiran samar bahwa melewatkan detail sekarang berarti "membuang-buang" satu putaran build nanti.
Ini justru terbalik, dan inilah alasannya: rencana akan direvisi lagi begitu Anda melihat halaman sebenarnya, tidak peduli seberapa hati-hati Anda di awal. Dan saat direvisi, Anda tidak mendapatkan perbandingan perubahan — Anda mendapatkan kartu baru yang sudah menyertakan revisi Anda, titik, tanpa catatan perubahan. Jadi detail yang Anda tulis di putaran pertama tidak bertahan utuh ke putaran kedua; Anda tetap harus membaca ulang semuanya. Dua atau tiga putaran "bukan, maksud saya begini" memberi hasil yang lebih baik, lebih cepat dari sisi waktu nyata, dibanding satu brief yang sangat detail — meskipun menulis brief itu terasa lebih efisien saat Anda melakukannya.
Perubahan berbahasa sehari-hari yang benar-benar berhasil itu singkat:
- "Hapus blog, tambahkan halaman harga" — mengganti daftar halaman dengan bersih.
- "Jadikan dua pemain, bukan satu pemain" — lebih besar dampaknya dari yang terdengar. Bisa memengaruhi model data, yang kini melacak dua peserta bukan satu, dan rencana yang direvisi akan menunjukkan dampak itu, bukan menyembunyikannya.
- "Ini butuh akun pengguna" — jika rencana saat ini adalah situs statis, ini kalimat yang langsung memaksa munculnya pertanyaan jenis produk.
Kesalahan tiga: memperlakukan jenis produk sebagai field yang bisa diubah sepele
Ini yang paling mahal, dan mahal karena semua yang lain di kartu itu benar-benar bisa diperbaiki. Halaman, fitur yang disimpulkan, sebagian besar percabangan pertanyaan — semuanya bisa diperbaiki dengan iterasi versi setelah build selesai. Jenis produk tidak bisa. Ada empat kategori:
| Jenis produk | Artinya |
|---|---|
| Situs statis | Sederhana, tanpa logika server. |
| Aplikasi yang dapat dipasang | Bergaya PWA — dapat digunakan offline, dapat ditambahkan ke layar utama, masih tanpa logika server. |
| Build berbasis framework | Bergaya React/Next, interaktivitas klien yang lebih berat, masih tanpa backend persisten. |
| Aplikasi berbasis server | Satu-satunya dari keempatnya yang memiliki database sungguhan dan sistem akun di baliknya. |
Menyetujui rencana situs statis, lalu tiga versi kemudian memutuskan ingin fitur login, itu bukan sekadar naik versi — itu rebuild dari jenis produk yang berbeda, dan Anda kehilangan kontinuitas yang selama ini diberikan riwayat versi untuk semua yang lain.
Orang salah paham soal ini dengan dua cara. Pertama, mereka tidak memeriksa prompt mereka sendiri terhadap field ini — jika prompt Anda mengandung kata "akun," "login," "simpan," "dashboard yang diperbarui," "pembayaran," atau "banyak pengguna mengedit hal yang sama," dan kartunya tidak menyebutkan berbasis server, itulah satu-satunya edit yang layak dilakukan sebelum Anda menyetujui, tanpa kecuali. Kedua, mereka mengacaukan aplikasi yang dapat dipasang dengan build berbasis framework, karena keduanya terasa seperti "aplikasi" dalam percakapan sehari-hari. Keduanya tidak bisa saling menggantikan: aplikasi yang dapat dipasang cocok untuk alat di mana semua status disimpan di perangkat pengguna — kalkulator tip, timer latihan. Build berbasis framework berarti interaktivitas dan struktur komponen yang lebih tinggi tapi tetap tanpa data yang bertahan di server lintas sesi atau perangkat. Tidak satu pun dari keduanya adalah "aplikasi" dalam artian memiliki akun dan data yang mengikuti Anda lintas perangkat — hanya berbasis server yang seperti itu. Dan menyediakan berlebihan ke berbasis server "untuk jaga-jaga" untuk situs portofolio atau halaman dokumentasi juga bukan pilihan yang aman; menurunkannya nanti sama repotnya dengan rebuild seperti menaikkannya.
Yang tersisa setelah Anda berhenti melakukan tiga hal itu
Setelah Anda tidak lagi melewati baris jenis produk begitu saja, tidak menulis spesifikasi di tahap rencana, dan tidak memperlakukan bahasa akun/data/pembayaran di prompt Anda sendiri sebagai hal yang bisa dinegosiasikan, yang tersisa adalah pemeriksaan cepat dan sempit:
- Baca jenis produknya.
- Cocokkan dengan prompt Anda.
- Lihat sekilas daftar fitur yang disimpulkan untuk hal apa pun yang akan Anda tolak begitu melihatnya.
Daftar ini ada justru karena prompt seperti "alat penjadwalan untuk salon rambut" menarik hal-hal yang tidak Anda ketik — tampilan kalender dan pengingat SMS dan daftar klien, sebagian memang Anda maksudkan dan sebagian lagi adalah scope creep yang ditambahkan model karena fitur-fitur itu secara statistik sering muncul bersamaan. Pangkas yang tidak sesuai dalam satu kalimat, di sini, bukan setelah dibangun.
Semua yang lain — teks, spasi, warna aksen apa, apakah tombolnya bertuliskan "Mulai" atau "Coba Gratis" — sama sekali tidak ada di kartu ini, dengan sengaja. Hal-hal itu murah untuk dilihat dan diperbaiki pada build yang sudah berfungsi, jadi kartu ini tidak membuang perhatian Anda untuk itu, dan Anda pun sebaiknya begitu. Itu mungkin lima belas detik penilaian nyata dari tiga puluh detik yang dibutuhkan untuk membaca kartu ini.
