Template & Contoh PRD Aplikasi: Format Ramping yang Siap Diserahkan ke AI Coding Agent

Kamu googling "template PRD", dapet dokumen 40 halaman bekas konsultan. Ada bagian stakeholder analysis, risk matrix, appendix C. Kamu isi tiga section pertama, sisanya dibiarin "[TBD]". Terus file itu dikasih ke AI coding agent, dan agent-nya bingung: mana yang beneran aturan, mana yang cuma placeholder kosong.

Masalahnya bukan kamu malas ngisi. Template korporat memang ditulis buat rapat, bukan buat ngoding. Yang dibutuhin agent itu ringkas dan tegas: entitas apa, aturannya apa, edge case-nya apa. Artikel ini kasih template yang bisa langsung dicopy, satu contoh terisi penuh (aplikasi kasir), dan penjelasan tiap section buat apa. Kalau kamu belum kenal formatnya sama sekali, mampir dulu ke apa itu PRD.

Kenapa template PRD panjang malah bikin agent tersesat

Agent baca dokumenmu dari atas ke bawah dan memperlakukan hampir semuanya sebagai perintah. Kalau setengah dokumen isinya section seremonial yang kamu tinggalin kosong, kamu lagi ngasih dia teka-teki. Section yang bikin noise buat agent biasanya ini:

• Executive summary yang ngulang isi bab lain dengan bahasa marketing.
• Stakeholder & RACI matrix. Berguna buat manusia, nol nilai buat yang ngoding.
• Risk register dan mitigation plan yang isinya asumsi, bukan spesifikasi.
• Timeline & milestone. Agent nggak peduli sprint kamu minggu berapa.
• Appendix penuh "[TBD]" yang bikin agent ngira ada aturan tersembunyi.

Ramping bukan berarti asal-asalan. Spec-driven itu justru soal presisi, cuma presisinya diarahin ke hal yang bikin kode beda, bukan ke seremoni. Kalau kamu masih nimbang gaya kerja mana yang cocok, baca vibe coding vs spec-driven development biar jelas kapan butuh spec dan kapan enggak.

Template PRD ramping yang bisa langsung dicopy

Ini kerangka kosongnya. Copy, ganti placeholder, hapus yang nggak relevan. Tujuh section, semuanya kepakai buat ngarahin agent. Nggak ada yang cuma buat gaya-gayaan.

# PRD: [Nama Aplikasi]

## 1. Ringkasan
- Masalah yang dipecahin:
- Siapa penggunanya:
- Hasil yang dianggap berhasil:

## 2. Ruang lingkup
- Yang dikerjakan (v1):
- Yang TIDAK dikerjakan (out of scope):

## 3. Stack & batasan teknis
- Frontend:
- Backend / DB:
- Auth:
- Aturan wajib (mis. semua uang integer, validasi di server):

## 4. Entitas & data
- [Entitas]: field, tipe, wajib/opsional, relasi

## 5. Fitur
### [Nama fitur]
- User story: sebagai [peran], saya [aksi], supaya [hasil]
- Aturan bisnis:
- Edge case:
- Kriteria selesai:

## 6. Alur utama
1.
2.

## 7. Yang tidak boleh dilakukan
- 

Perhatiin section 7. Daftar larangan sering lebih berharga daripada daftar fitur, karena di situ agent paling suka ngarang kalau nggak dibatasi (bikin endpoint tambahan, hapus data beneran, ganti nama kolom seenaknya).

Tiap section itu buat apa

Sebelum ngisi, pahami dulu tugas masing-masing section. Kalau kamu ngerti kenapa section itu ada, kamu nggak bakal ngisinya asal panjang.

• Ringkasan: konteks buat agent ngambil keputusan kecil sendiri saat spec-mu diam. "Aplikasi kasir buat warung" bikin dia mikir beda dari "POS multi-cabang".
• Ruang lingkup: pagar. Bagian "yang TIDAK dikerjakan" yang nahan agent dari over-engineering fitur yang belum kamu minta.
• Stack & batasan: ngunci teknologi dan aturan non-negosiasi. Tanpa ini, dua agent bisa milih dua DB berbeda buat proyek yang sama.
• Entitas & data: tulang punggung. Salah model data di sini, semua fitur di atasnya ikut miring.
• Fitur: unit kerja sebenarnya. Satu fitur = user story + aturan + edge case + kriteria selesai. Bukan cuma judul.
• Alur utama: urutan langkah dari pengguna buka app sampai tujuannya kelar. Nangkep hal yang kelewat kalau kamu cuma daftar fitur terpisah.
• Yang tidak boleh: rem darurat. Isi ini tiap kali agent bikin sesuatu yang bikin kamu istighfar.

Contoh terisi: satu fitur aplikasi kasir

Template kosong gampang keliatan gampang. Yang susah itu ngisinya dengan detail yang bener. Ini satu fitur dari aplikasi kasir sederhana, diisi sampai ke aturan dan edge case. Segini levelnya yang bikin agent ngoding tanpa nebak-nebak.

## Fitur: Buat transaksi (kasir)

User story:
Sebagai kasir, saya pilih produk, sistem hitung total,
saya terima pembayaran, struk tercatat.

Entitas terkait:
- Produk       { id, nama, harga:int, stok:int, aktif:bool }
- Transaksi    { id, tanggal, kasir_id, total:int, bayar:int,
                 kembalian:int, status }
- ItemTransaksi{ transaksi_id, produk_id, qty:int,
                 harga_saat_itu:int }

Aturan bisnis:
- harga_saat_itu di-snapshot saat item ditambah, bukan referensi
  live. Harga produk boleh berubah nanti, struk lama tetap benar.
- total = sum(qty * harga_saat_itu). Dihitung di server, jangan
  percaya angka kiriman dari client.
- Stok berkurang saat status = "selesai", bukan saat item ditambah
  ke keranjang.
- bayar >= total. Kalau kurang, tolak, jangan simpan transaksi.

Edge case:
- Produk stok 0 -> tidak bisa ditambah, tampilkan pesan jelas.
- Produk dinonaktifkan sewaktu ada di keranjang -> blokir checkout.
- qty diubah jadi 0 -> hapus item dari keranjang.
- Transaksi dibatalkan setelah "selesai" -> stok dikembalikan,
  status = "batal", JANGAN hard delete.

Kriteria selesai:
- Total selalu cocok dengan penjumlahan item.
- Stok tidak pernah minus.
- Struk bisa dicetak ulang dengan angka yang sama persis.

Lihat baris "harga_saat_itu di-snapshot". Itu satu kalimat yang nyelametin kamu dari bug klasik: harga produk naik bulan depan, struk lama ikut berubah, laporan penjualan jadi ngaco. Agent nggak bakal kepikiran itu sendiri kecuali kamu tulis. Kalau kamu mau contoh yang lebih utuh dari ide sampai spec, baca cara membuat PRD untuk aplikasi, atau lihat langsung beberapa PRD jadi di galeri contoh.

Bagian yang paling sering dilewat: aturan & edge case

Kebanyakan PRD berhenti di "kasir bisa buat transaksi". Itu bukan spec, itu judul fitur. Kualitas PRD ketahuan di dua baris: aturan bisnis dan edge case. Di situlah dokumenmu balik modal. Yang paling sering ketinggalan biasanya ini:

• State kosong: keranjang belum ada isi, hasil pencarian nol, pengguna baru tanpa data.
• Duit dan angka: pembulatan, diskon, pajak, uang disimpan integer atau float (tolong integer).
• Barengan: dua kasir jual produk stok terakhir yang sama di detik yang sama.
• Batalin & undo: transaksi dibatalin, apa yang balik, apa yang tetap tercatat.
• Izin: siapa boleh ngapain. Kasir vs pemilik toko beda hak akses.
• Data buruk: input negatif, teks di kolom angka, karakter aneh di nama produk.

Kamu nggak harus nyelesein semuanya di v1. Tapi tiap edge case yang kamu tulis, walaupun keputusannya "abaikan dulu", adalah satu keputusan yang agent nggak perlu ngarang. Kalau kamu juga nulis prompt buat manggil agent-nya, samain gaya presisinya lewat prompt untuk AI coding.

PRD aplikasi mobile: apa yang beda

Struktur template-nya sama. Yang nambah itu kenyataan hidup di HP: koneksi putus-nyambung, layar kecil, dan sistem operasi yang punya aturan sendiri. Buat contoh PRD aplikasi mobile, tambahin pertimbangan ini di section fitur dan alur:

• Offline & sinkronisasi: apa yang jalan tanpa internet, apa yang di-antre buat dikirim pas online lagi.
• State saat app ditutup: pengguna keluar di tengah transaksi, balik lagi, harus lanjut dari mana.
• Izin perangkat: kamera buat scan barcode, notifikasi, penyimpanan. Kapan diminta, apa yang terjadi kalau ditolak.
• Navigasi: tombol back Android, gesture, deep link. Ini beda dari web dan sering bikin bug kalau nggak ditulis.
• Ukuran layar: apa yang tetap kelihatan di layar kecil, apa yang boleh disembunyiin di balik menu.

Sisipin ini sebagai aturan atau edge case di fitur yang relevan, bukan bikin bab terpisah. Agent butuhnya di dekat konteksnya, bukan di halaman lain.

Dari template ke file rules

PRD ngomongin apa yang dibangun. Tapi ada aturan yang berlaku di setiap fitur, dan ngulang-ngulang di tiap section itu boros. Aturan lintas-fitur begini tempatnya di file rules (.cursor/rules buat Cursor, CLAUDE.md buat Claude Code). Contohnya buat aplikasi kasir tadi:

# .cursor/rules  /  CLAUDE.md -- potongan

- Semua uang disimpan integer (rupiah), tidak pernah float.
- Validasi di server. Client hanya urusan tampilan.
- Nama tabel snake_case dan jamak: products, transactions.
- Jangan pernah hard delete data transaksi. Pakai kolom status.
- Bentuk error selalu konsisten: { error: { code, message } }.
- Setiap fungsi yang menyentuh stok wajib ada test-nya.

Kasih ide yang sama ke Cursor dan Claude Code tanpa file ini, hasilnya sering beda jauh: folder acak, format error sesuka masing-masing, ribet pas mau digabung. File rules ngunci pola itu di semua agent. Cara nulis dan naruhnya ada di file rules Cursor & CLAUDE.md biar AI konsisten.

Mau tanpa ngisi manual? Generate otomatis

Template di atas gratis dan bakal kepakai. Tapi ngisi entitas, aturan, dan edge case buat tiap fitur itu makan waktu, dan yang paling gampang kelewat justru edge case yang belum kepikiran. Di sinilah Skematik masuk: kamu ceritain idenya dengan bahasa biasa, dia keluarin PRD terstruktur sekaligus file rules, jadi agent mana pun ngoding dengan pola yang sama dari awal.

Ada juga mode Web GAS buat aplikasi Google Apps Script, dan PRD-nya bisa langsung diserahin ke Cursor atau Claude Code. Kalau kamu pengen bangun tanpa ngoding sendiri, alurnya dibahas di cara membuat aplikasi dengan AI tanpa coding. Mau lihat kerangka jadinya dulu? Ada di galeri template.

Template kosong bantu kamu mulai. Template terisi yang benar bantu agent selesai. Bedanya ada di detail yang males kamu tulis pas jam 11 malam. Serahin bagian itu ke Skematik, atau isi sendiri pakai kerangka di atas. Yang penting jangan kasih agent dokumen 40 halaman isi tiga baris.