Langsung ke konten utama
Kalau kamu butuh jawaban cepat sebelum membaca semua halaman docs, mulai dari FAQ ini. Setiap jawaban di bawah sengaja singkat dan selalu diarahkan ke halaman detail yang relevan.

​
Pertanyaan yang paling sering muncul

Tidak. Justru pendekatan yang lebih aman biasanya kebalikannya: aktifkan hanya modul yang memang dipakai, lalu matikan sisanya lewat NEXT_PUBLIC_ENABLE_*. Lihat Matrix feature toggle dan Environment variables.
Cocok untuk memahami apa yang sudah siap dipakai, memilih use case, menentukan fitur yang aktif, dan menyiapkan brief yang lebih jelas ke developer. Tetapi untuk custom besar, schema database, business logic inti, dan deployment production, kamu tetap akan terbantu kalau ada developer yang menangani bagian teknis. Lihat Yang bisa dikerjakan tanpa coding vs butuh developer.
Bisa. Set NEXT_PUBLIC_ENABLE_AI=false, lalu hapus CTA, copy, dan plan yang menyebut fitur AI. Baca AI dan tooling dan Resep rebranding kalau kamu ingin membersihkan jejak AI dari UI dan positioning produk.
Tidak. Kamu cukup pilih satu provider lewat PAYMENT_PROVIDER, lalu isi credential provider yang sesuai. Midtrans dan Doku ada sebagai opsi, bukan kewajiban untuk dipakai bersamaan. Lihat Setup layanan dan Environment variables.
Bisa. Set NEXT_PUBLIC_ENABLE_PAYMENTS=false, lalu rapikan halaman pricing, CTA upgrade, dan alur checkout. Untuk skenario seperti portal member atau client area, ini justru sering jadi preset awal yang paling masuk akal. Lihat Resep preset per use case.
Bisa. Itu salah satu jalur paling aman untuk validasi awal. Kamu bisa mematikan auth, payments, admin, dan AI lebih dulu, lalu fokus ke landing page, contact form, blog, roadmap, dan waitlist. Lihat Use case KilatKoding, Resep preset per use case, dan Checklist launch.
Bisa. Ini malah salah satu use case yang paling natural. Tetapi rebrand yang rapi biasanya mencakup lebih dari logo: navigation, copy, pricing, legal pages, email sender, CTA, dan modul yang memang harus dimatikan juga perlu dirapikan. Lihat Kustomisasi dan Resep rebranding.
Ya. Docs setup lokal memang ditulis khusus untuk tiga OS itu. Kalau kamu bekerja lintas tim, halaman ini biasanya jadi entry point paling aman untuk memastikan semua orang mulai dari urutan yang sama. Lihat Setup lokal.
Kamu tetap butuh developer saat mulai masuk ke area seperti model data produk, schema database, permission yang lebih spesifik, webhook logic, AI experience yang lebih dalam, integrasi layanan tambahan, dan deployment production yang lebih kompleks. Lihat Arsitektur, Peta database, dan API reference.
Sebagai fondasi awal, iya. Sebagai solusi siap pakai untuk marketplace kompleks atau multi-tenant penuh, belum. KilatKoding bisa menghemat waktu di auth, billing, admin, dan marketing layer, tetapi logic inti seperti multi-seller, payout, escrow, atau team workspace tetap butuh custom besar. Lihat Perbandingan KilatKoding dan Batasan saat ini.
Tidak wajib. Tetapi jalur deployment yang paling detail di docs saat ini memang Vercel, jadi itu biasanya jadi opsi paling cepat untuk tim yang ingin mengikuti panduan apa adanya. Kalau kamu deploy ke platform lain, prinsip env, callback URL, dan webhook tetap sama, tetapi beberapa langkah operasional perlu kamu sesuaikan sendiri. Lihat Deploy ke Vercel.
Mulai dari Ringkasan produk, Use case KilatKoding, Perbandingan KilatKoding, lalu Resep preset per use case. Dari sana kamu biasanya sudah bisa memutuskan arah setup tanpa membaca semuanya sekaligus.
Kalau pertanyaan kamu belum terjawab di sini, cek juga Glosarium, Troubleshooting, dan Operational runbook.