Cara Membuat Web dan Aplikasi Sekolah dari Nol: 25 Langkah dengan Prompt AI

Membuat web dan aplikasi manajemen sekolah dimulai dari memahami pekerjaan sekolah sehari-hari. Data siswa, jadwal, presensi, nilai, tagihan, dan informasi untuk orang tua perlu disusun menjadi satu alur yang jelas. Setelah alurnya ditetapkan, AI dapat membantu menulis rancangan, membuat kode, menjelaskan error, dan menyusun pemeriksaan hasil.

Artikel ini mengajak Anda mengerjakannya melalui 25 langkah, dari menyiapkan komputer sampai meluncurkan web serta aplikasi mobile. Setiap langkah dilengkapi tujuan, penjelasan praktis, prompt AI siap salin, hasil yang perlu diperoleh, dan cara memeriksanya. Contoh proyek menggunakan sekolah fiktif agar latihan dapat dilakukan tanpa data siswa nyata.

Gunakan panduan ini sebagai urutan kerja. Selesaikan dan periksa satu tahap sebelum melanjutkan ke tahap berikutnya. Prompt menghasilkan instruksi atau perubahan kode sesuai kemampuan alat AI yang digunakan; keberhasilannya tetap perlu dibuktikan di proyek Anda.

Daftar isi

• Pertanyaan yang sering diajukan
• Bacaan dan alat pendukung

• Dasar riset dan pilihan pendekatan
• Cara menggunakan prompt
• Tahap A: Persiapan
• 1. Tentukan tujuan dan pengguna
• 2. Petakan proses dan aturan sekolah
• 3. Batasi versi pertama
• 4. Pilih arsitektur dan teknologi
• 5. Siapkan komputer dan akun
• 6. Buat proyek dan dokumentasi kerja AI
• Tahap B: Fondasi sistem
• 7. Rancang database
• 8. Rancang layar dan navigasi
• 9. Implementasikan login dan hak akses
• 10. Bangun data induk dan impor
• Tahap C: Modul sekolah
• 11. Bangun penerimaan siswa
• 12. Bangun presensi dan akademik
• 13. Bangun tagihan dan pembayaran manual
• 14. Integrasikan pembayaran online
• 15. Bangun portal orang tua dan notifikasi
• 16. Bangun kartu siswa digital
• Tahap D: Web dan aplikasi mobile
• 17. Siapkan kontrak API
• 18. Siapkan web mobile dan PWA
• 19. Bangun aplikasi Flutter
• Tahap E: Pengujian dan peluncuran
• 20. Uji fungsi, keamanan, dan performa
• 21. Siapkan privasi dan operasional data
• 22. Deploy web dan backend
• 23. Rilis aplikasi Android dan iOS
• 24. Migrasi, pilot, dan serah terima
• 25. Pemeliharaan dan pemulihan
• Estimasi waktu dan anggaran
• Prompt perbaikan dan kelanjutan pekerjaan
• Kriteria aplikasi benar-benar selesai
• Catatan penggunaan
• Daftar sumber

Dasar riset dan pilihan pendekatan

SkoolaCloud mempublikasikan cakupan administrasi, penerimaan siswa, akademik, presensi, pembayaran, akses orang tua, dan layanan identitas siswa. Halaman tersebut menjadi referensi jenis kebutuhan, bukan bukti teknologi internal atau kualitas implementasinya. SkoolaCloud (2026/10), halaman utama; tanggal akses

Kelola akademik, keuangan, PPDB, absensi, hingga komunikasi orang tua dalam satu platform

SkoolaCloud (2026/10), pembuka; tanggal akses

Rekomendasi rancangan: bangun satu sistem backend yang digunakan web dan aplikasi mobile. Mulai dari satu sekolah, dengan model data yang menyimpan identitas sekolah. Peluncuran layanan untuk banyak sekolah membutuhkan pengujian isolasi data tersendiri. Jangan menyebut produk siap multisekolah hanya karena sudah mempunyai kolom school_id.

Ini pilihan implementasi untuk tutorial, bukan satu-satunya stack yang benar. Gunakan versi stabil yang kompatibel saat proyek dimulai, lalu simpan versi dependensi dalam lockfile. Jangan mencampurkan contoh konfigurasi dari beberapa versi framework.

Sanctum memang mendukung aplikasi mobile dan API berbasis token. Laravel Sanctum (2026/10), pengantar; tanggal akses

mobile applications, and simple, token based APIs

aplikasi mobile, serta API sederhana berbasis token

Laravel Sanctum (2026/10), pengantar; tanggal akses

Struktur awal yang diusulkan:

school-platform/
  backend/       aplikasi Laravel dan web admin
  mobile/        aplikasi Flutter
  docs/          kebutuhan, database, API, pengujian, operasional

Aturan sekolah tetap diputuskan oleh sekolah. Prompt membantu menerjemahkan keputusan itu menjadi rancangan dan kode.

Cara menggunakan prompt

Gunakan prompt berurutan. Jika memakai AI percakapan biasa, jalankan instruksi di komputer sendiri dan kirimkan hasil yang relevan. Jika memakai agen coding yang mempunyai akses proyek, mintalah agen mengedit dan menjalankan pengujian langsung. Jangan menganggap AI sudah menjalankan perintah hanya karena menampilkan perintahnya.

Ganti bagian dalam tanda kurung siku. Berikan file hasil tahap sebelumnya sebagai konteks. Untuk tiap modul, simpan perubahan yang sudah lolos pemeriksaan ke Git agar bisa kembali ke versi yang diketahui bekerja.

Prompt induk, dipasang di awal pekerjaan:

Anda membantu saya membangun sistem manajemen sekolah yang bisa dijalankan.
Nama proyek: [nama]. Target awal: satu sekolah, [jumlah] siswa.
OS komputer saya: [Windows/macOS/Linux]. Kemampuan saya: [pemula/menengah].
Stack: Laravel + Blade/Livewire, PostgreSQL, Sanctum, dan Flutter.
Web admin dan mobile memakai backend yang sama.

Baca docs proyek serta versi dependensi sebelum mengubah kode.
Kerjakan hanya tahap yang saya minta dan pertahankan keputusan sebelumnya.
Gunakan data sintetis; jangan meminta data siswa asli atau secret melalui chat.
Jangan mengganti stack atau menambah layanan berbayar tanpa menjelaskan kebutuhan.
Validasi dan otorisasi wajib di server. Jangan memakai localStorage atau data
mock sebagai pengganti penyimpanan produksi tanpa label yang jelas.
Gunakan dokumentasi resmi sesuai versi yang terpasang.

Untuk setiap tahap, tampilkan:
1. Tujuan dan prasyarat.
2. File yang dibuat atau diubah.
3. Implementasi lengkap untuk cakupan tahap tersebut.
4. Perintah menjalankan dan hasil yang diharapkan.
5. Pemeriksaan keberhasilan, termasuk kasus gagal yang relevan.
6. Pengujian yang benar-benar dijalankan serta yang belum.
7. Ringkasan keputusan dan tugas berikutnya di docs/progress.md.
Jangan mengklaim selesai jika masih ada placeholder pada alur utama.

Tahap A: Persiapan

1. Tentukan tujuan dan pengguna

Mulailah dengan satu masalah yang bisa diamati. Misalnya, bendahara harus membuka beberapa spreadsheet hanya untuk mengetahui tunggakan seorang siswa. Tulis keadaan sekarang, siapa yang mengerjakan, dan hasil seperti apa yang dianggap membantu. Setelah itu, buat daftar pengguna. Akun orang tua tidak sama dengan profil siswa, dan seorang wali bisa memiliki lebih dari satu anak. Pembeda ini akan memengaruhi rancangan database dan izin akses sejak awal.

Tujuan: menentukan siapa memakai sistem dan pekerjaan yang akan dibantu. Siapkan jumlah siswa, kelas, unit sekolah, perangkat, kualitas internet, serta penanggung jawab sekolah. Untuk contoh, gunakan nama fiktif “Sekolah Pelita”, 500 siswa, satu sekolah, mata uang IDR, zona waktu Asia/Jakarta.

Bertindak sebagai analis kebutuhan. Susun dokumen kebutuhan sistem Sekolah
Pelita, satu sekolah dengan 500 siswa. Pengguna: admin, tata usaha,
bendahara, kepala sekolah, guru, orang tua, dan siswa.
Petakan masalah, tujuan terukur, tugas pengguna, kebutuhan perangkat,
aksesibilitas, serta pertanyaan yang perlu dijawab sekolah.
Tandai asumsi, jangan mengarang kebijakan sekolah.
Simpan docs/requirements.md dan matriks pengguna versus tindakan.
Bedakan akun login, profil siswa, profil guru, dan hubungan wali-siswa.

Hasil dan pemeriksaan: sekolah menyetujui kebutuhan. Setiap fitur punya pengguna dan tujuan. Contoh ukuran keberhasilan usulan: bendahara dapat menerbitkan tagihan satu kelas, dan orang tua dapat melihat tagihan anak yang terhubung dengan akunnya.

2. Petakan proses dan aturan sekolah

Ambil satu formulir kosong yang benar-benar digunakan sekolah. Ikuti perjalanan formulir itu: siapa mengisi, siapa memeriksa, kapan dinyatakan lengkap, dan apa yang terjadi jika salah. Terapkan cara yang sama pada presensi, nilai, dan pembayaran. Hasil pemetaan sebaiknya menjelaskan tindakan berikutnya untuk setiap status. Jika masih ada status bernama “diproses” tanpa penanggung jawab atau batas tindakan, bahas dulu dengan petugas terkait sebelum meminta AI menulis kode.

Tujuan: mengubah kebiasaan administrasi menjadi alur yang jelas. Siapkan contoh formulir kosong, struktur kelas, periode akademik, format rapor, dan aturan pembayaran.

Baca requirements.md. Petakan alur penerimaan siswa, penempatan kelas,
presensi, penilaian, penerbitan tagihan, pembayaran, koreksi, dan kelulusan.
Untuk setiap alur buat aktor, input, status, transisi yang diizinkan,
otoritas persetujuan, kondisi gagal, dan jejak audit.
Jelaskan kasus pindah kelas, wali lebih dari satu, saudara kandung,
cicilan, pembayaran berlebih, pembatalan, dan perubahan tahun ajaran.
Tandai kebijakan yang harus diputuskan sekolah. Simpan docs/workflows.md.

Hasil dan pemeriksaan: petugas dapat menyimulasikan satu siswa dari pendaftaran sampai aktif tanpa menebak status. Pembatalan pembayaran dan perubahan nilai punya otoritas yang jelas.

3. Batasi versi pertama

Versi pertama perlu cukup kecil untuk diselesaikan, tetapi cukup utuh untuk dipakai. Sebagai contoh, jangan hanya membangun halaman daftar tagihan. Selesaikan juga penerbitan, rincian, pembayaran, pencatatan sisa, serta akses wali terhadap tagihan tersebut. Fitur tambahan dapat dimasukkan ke daftar pengembangan berikutnya. Dengan cara ini, kemajuan diukur dari pekerjaan pengguna yang berhasil dituntaskan, bukan dari banyaknya menu yang sudah muncul.

Tujuan: membangun satu alur utuh yang bisa dipakai terlebih dahulu. MVP yang diusulkan: login, data siswa/guru/wali, kelas, presensi, tagihan, pencatatan pembayaran, portal wali, dan pengumuman. Penerimaan serta penilaian ditambahkan dalam iterasi berikutnya jika tidak menjadi kebutuhan pertama sekolah.

Dari requirements dan workflows, buat backlog berurutan menurut dependensi.
Pisahkan MVP, rilis lanjutan, dan fitur opsional. Untuk setiap pekerjaan,
tentukan acceptance criteria, dependensi, perkiraan kompleksitas, dan demo.
Prioritaskan alur siswa -> kelas -> presensi -> tagihan -> pembayaran -> wali.
Jangan memasukkan LMS penuh, CBT, dompet uang saku, RFID, atau biometrik
ke MVP tanpa kebutuhan eksplisit. Simpan docs/backlog.md.

Hasil dan pemeriksaan: batas versi pertama tertulis. Tiap pekerjaan dapat didemokan dan tidak hanya disebut “buat dashboard”.

4. Pilih arsitektur dan teknologi

Bayangkan backend sebagai tempat semua aturan sekolah diperiksa. Ketika bendahara membuka web dan orang tua membuka aplikasi, keduanya mengakses aturan serta data yang sama. Karena itu, perubahan status pembayaran sebaiknya tidak dihitung berbeda di masing-masing perangkat. Dalam rancangan tutorial ini, satu backend mengurus modul yang dipisahkan secara rapi. Pilihan teknologi perlu disesuaikan dengan kemampuan pengelola dan lingkungan hosting yang benar-benar akan digunakan.

Tujuan: menetapkan satu pilihan yang konsisten. Usulan panduan ini adalah modular monolith: satu aplikasi backend dengan modul yang terpisah secara kode, tanpa memecahnya menjadi banyak layanan sejak awal.

Rancang arsitektur untuk stack pada prompt induk. Pisahkan modul identitas,
sekolah, akademik, penerimaan, keuangan, komunikasi, dan audit.
Jelaskan request dari browser/mobile sampai database dan penyimpanan berkas.
Tentukan batas transaksi, strategi queue, pengelolaan secret, lingkungan
local/staging/production, dan autentikasi untuk tiap klien.
Buat keputusan tertulis tentang isolasi sekolah dan hubungan wali-siswa.
Bandingkan singkat alternatif yang lebih sederhana jika kemampuan saya
belum cukup. Simpan docs/architecture.md; jangan buat microservices.

Hasil dan pemeriksaan: fitur web dan mobile tidak mempunyai aturan bisnis yang saling bertentangan. Semua perubahan penting diperiksa backend.

5. Siapkan komputer dan akun

Catat sistem operasi komputer sebelum mengikuti perintah instalasi. Instruksi PowerShell, terminal macOS, dan shell Linux tidak selalu bisa ditukar begitu saja. Setelah memasang satu komponen, jalankan pemeriksaan versinya dan simpan hasilnya di catatan proyek. Siapkan pula folder kerja khusus yang tidak bercampur dengan dokumen siswa. Pada tahap ini, sasaran utamanya adalah lingkungan lokal yang stabil; akun produksi dan layanan tambahan dapat disiapkan ketika sudah dibutuhkan.

Tujuan: mendapatkan lingkungan lokal yang dapat menjalankan proyek. Siapkan editor, Git, PHP, Composer, runtime JavaScript, PostgreSQL, Flutter SDK, serta perangkat/emulator Android. Pasang tooling mobile saat mendekati tahap mobile bila ingin mengurangi beban belajar awal. Dokumentasi Laravel menjelaskan prasyarat PHP, Composer, installer, serta alat build frontend. Laravel Installation (2026/10), instalasi; tanggal akses

Pandulah setup berdasarkan OS saya. Periksa dahulu php -v, composer --version,
node -v, npm -v, git --version, dan psql --version. Untuk tahap mobile,
tambahkan flutter doctor. Jelaskan perintah dijalankan di terminal mana.
Pilih versi yang kompatibel dengan dokumentasi framework stabil.
Berikan langkah instalasi resmi hanya untuk komponen yang belum tersedia,
cara mengatur PATH, dan cara memeriksa hasil. Jangan menimpa instalasi
yang sudah dipakai proyek lain tanpa rencana. Buat docs/setup.md.

Hasil dan pemeriksaan: perintah pemeriksaan berhasil, database uji dapat diakses. Akun yang perlu disiapkan kemudian: repositori privat, hosting, domain, email aplikasi, sandbox pembayaran, dan akun distribusi aplikasi bila diperlukan. Secret disimpan dalam konfigurasi lokal atau pengelola secret, bukan dokumen prompt.

6. Buat proyek dan dokumentasi kerja AI

Begitu proyek dasar terbuka, hentikan dulu penambahan fitur dan pastikan fondasinya dapat diulang. Tutup server lokal, jalankan kembali, lalu buka halaman yang sama. Periksa bahwa koneksi database tetap bekerja dan petunjuk menjalankan proyek dapat diikuti dari awal. Catatan kemajuan berfungsi sebagai pengingat bagi pengembang dan AI: keputusan mana yang sudah dibuat, bagian mana yang benar-benar diuji, serta pekerjaan apa yang paling masuk akal dikerjakan berikutnya.

Tujuan: memperoleh aplikasi dasar yang benar-benar berjalan. Contoh alur resmi setelah installer Laravel siap: laravel new, pemasangan dependensi frontend, build, lalu composer run dev. Pilihan starter kit memengaruhi isi proyek. Laravel Installation (2026/10), creating an application; tanggal akses

Buat school-platform/backend dengan Laravel dan starter kit yang kompatibel
dengan Blade/Livewire. Periksa dokumentasi versi yang dipilih dahulu.
Konfigurasikan PostgreSQL lokal, locale Indonesia dan zona waktu aplikasi.
Buat .env.example tanpa secret, README, .gitignore, dan folder docs.
Simpan versi runtime/dependensi. Jalankan migration pada database uji,
build frontend dan smoke test. Buat akun dummy melalui seeder lokal.
Tuliskan URL lokal dan langkah membuka halaman login. Jangan deploy dulu.

Hasil dan pemeriksaan: halaman lokal terbuka, koneksi database berfungsi, dan repositori tidak berisi .env atau kunci privat. Simpan titik awal di Git.

Tahap B: Fondasi sistem

7. Rancang database

Rancangan data perlu merekam perubahan, bukan hanya keadaan hari ini. Jika nama kelas seorang siswa langsung diganti pada satu kolom, riwayat tahun sebelumnya bisa menjadi sulit ditelusuri. Dalam rancangan ini, keanggotaan kelas disimpan melalui enrollment per periode. Begitu pula pembayaran dipisahkan dari tagihan karena satu pembayaran dapat dialokasikan menurut aturan yang disepakati. Mintalah AI memberi contoh data kecil agar relasi dapat diperiksa sebelum seluruh migration dibuat.

Tujuan: menjaga riwayat akademik dan hubungan pengguna. Contoh kelompok tabel yang diusulkan:

Rancang ERD dan kamus data dari workflows. Gunakan enrollment per tahun
ajaran agar pindah kelas tidak menghapus riwayat. Hubungan wali-siswa
harus many-to-many dengan status verifikasi dan cakupan akses.
Pisahkan invoice, upaya pembayaran, pembayaran sah, alokasi, dan refund.
Gunakan tipe uang exact, bukan floating point. Tentukan foreign key,
unique constraint, indeks, dan kebijakan arsip/penghapusan per entitas.
Buat migration serta data dummy dua sekolah untuk menguji isolasi.
Simpan docs/data-model.md. Jangan memakai NIK sebagai primary key publik.

Hasil dan pemeriksaan: seorang wali dapat mempunyai dua anak; satu anak dapat mempunyai dua wali yang diverifikasi; riwayat kelas tetap ada setelah kenaikan kelas. Jangan menerapkan soft delete sebagai jawaban otomatis untuk semua data.

8. Rancang layar dan navigasi

Susun layar berdasarkan tugas terpenting. Bendahara membutuhkan pencarian siswa dan informasi sisa tagihan, sedangkan guru membutuhkan kelas yang sedang diajar dan daftar presensi. Buat rancangan sederhana terlebih dahulu dan minta calon pengguna menjelaskan apa yang akan mereka klik. Perhatikan juga keadaan ketika belum ada data. Halaman kosong perlu memberi petunjuk tindakan yang jelas, bukan hanya memperlihatkan tabel tanpa isi atau angka nol yang membingungkan.

Tujuan: membuat pekerjaan tiap pengguna mudah ditemukan. Siapkan daftar halaman berdasarkan backlog, bukan menyalin semua menu produk referensi.

Buat rancangan layar untuk admin, bendahara, guru dan orang tua berdasarkan
hak akses. Prioritaskan tabel yang bisa dicari, filter periode, formulir
dengan validasi yang jelas, serta tampilan HP yang mudah disentuh.
Sediakan keadaan loading, kosong, error, akses ditolak, dan berhasil.
Gunakan label Indonesia yang konsisten. Implementasikan kerangka UI dengan
data dummy berlabel, dan buat daftar komponen yang akan dihubungkan API.
Jangan tampilkan metrik fiktif seolah berasal dari database produksi.

Hasil dan pemeriksaan: pengguna dapat menyelesaikan satu tugas tanpa membuka menu yang tidak relevan. Uji layar kecil, keyboard, kontras, dan label formulir.

9. Implementasikan login dan hak akses

Uji hak akses menggunakan beberapa akun dummy sejak awal. Buat dua wali dengan anak yang berbeda, dua guru dengan penugasan berbeda, serta dua sekolah untuk skenario pengujian. Kemudian coba membuka objek yang tidak menjadi hak masing-masing akun. Pemeriksaan seperti ini membantu memastikan bahwa izin berasal dari backend. Tampilan menu hanyalah bagian antarmuka; permintaan API, ekspor, dan tautan berkas perlu mengikuti aturan akses yang sama.

Tujuan: membatasi tindakan sekaligus data yang dapat dilihat. Risiko akses objek melalui manipulasi ID dijelaskan OWASP; ID yang sulit ditebak tidak menggantikan pemeriksaan izin. OWASP API1 (2023), description

Implementasikan autentikasi, reset password, pembatasan percobaan login,
dan otorisasi server. Admin sekolah hanya mengelola sekolahnya, guru hanya
kelas/mapel penugasannya, wali hanya anak dengan relasi terverifikasi.
Gunakan policy untuk setiap objek, termasuk ekspor dan download berkas.
school_id harus berasal dari konteks yang diotorisasi, bukan dipercaya
dari payload pengguna. Implementasikan pencabutan sesi/token dan audit
perubahan peran. Tambahkan tes ganti ID siswa dan akses lintas sekolah.

Hasil dan pemeriksaan: login sebagai wali A lalu mencoba URL anak wali B harus ditolak. Menyembunyikan menu saja tidak memenuhi tahap ini.

10. Bangun data induk dan impor

Mulai impor dari file kecil yang mudah diperiksa, misalnya sepuluh siswa dummy dengan beberapa kesalahan yang sengaja ditambahkan. Sertakan satu nomor internal ganda, satu kelas yang belum tersedia, dan satu baris yang kolom wajibnya kosong. Operator harus memperoleh laporan yang menjelaskan baris mana perlu diperbaiki. Setelah hasilnya sesuai, ulangi impor file yang sama. Tentukan sebelumnya apakah tindakan itu memperbarui data atau ditolak, sehingga perilakunya tidak mengejutkan pengguna.

Tujuan: menyiapkan siswa, guru, wali, kelas, periode, dan mata pelajaran. Gunakan data sintetis untuk pengembangan.

Bangun CRUD data induk dan impor CSV dengan template kolom, preview,
validasi per baris, deteksi duplikasi, serta laporan baris ditolak.
Terapkan batas ukuran file dan transaksi sesuai kebutuhan. Impor ulang
file yang sama tidak boleh membuat siswa ganda. Jelaskan kunci pencocokan.
Relasi wali harus diverifikasi operator, bukan otomatis dipercaya hanya
karena nomor telepon diunggah. Sediakan ekspor sesuai izin dan audit.
Uji impor berhasil, salah format, duplikat, dan referensi kelas tidak ada.

Hasil dan pemeriksaan: operator mengetahui berapa baris diterima, diperbarui, dan ditolak. Tidak ada data yang hilang diam-diam.

Tahap C: Modul sekolah

11. Bangun penerimaan siswa

Pisahkan calon siswa dari siswa aktif. Pendaftar yang baru menyimpan draft belum seharusnya langsung masuk daftar kelas atau menerima tagihan siswa reguler. Tetapkan titik perubahan yang jelas, misalnya setelah keputusan diterima dan daftar ulang disahkan. Dokumen pendukung juga perlu mengikuti izin pemeriksa. Gunakan berkas dummy untuk mencoba alur perbaikan dokumen, lalu pastikan pendaftar dapat mengetahui apa yang harus diperbaiki tanpa melihat berkas milik orang lain.

Tujuan: membuat alur pendaftaran sampai menjadi siswa aktif. Gunakan istilah penerimaan siswa/PPDB/SPMB sesuai kebijakan sekolah yang telah dikonfirmasi, tanpa mengasumsikan aturan pemerintah tertentu.

Bangun modul penerimaan dari workflow yang disepakati: periode pendaftaran,
formulir, penyimpanan draft, kirim, verifikasi berkas, permintaan perbaikan,
keputusan, daftar ulang, dan aktivasi siswa. Upload berkas ke storage privat.
Tentukan transisi status yang boleh dilakukan tiap peran. Cegah aktivasi
ganda ketika tombol dipencet ulang. Buat notifikasi status tanpa membocorkan
berkas. Sediakan tes alur diterima, ditolak, diperbaiki, dan ditutup.

Hasil dan pemeriksaan: pendaftar yang diterima menjadi satu siswa aktif dengan riwayat asal pendaftaran. File tidak dapat dibuka publik hanya dengan menebak URL.

12. Bangun presensi dan akademik

Kerjakan presensi lebih dahulu jika itu kebutuhan paling mendesak. Setelah guru bisa memilih sesi, mencatat kehadiran, dan melakukan koreksi beralasan, lanjutkan ke tugas serta penilaian. Untuk rapor, minta sekolah menyediakan contoh perhitungan yang telah disepakati. Gunakan contoh itu sebagai pembanding hasil aplikasi. Jangan membiarkan AI menetapkan sendiri bobot, pembulatan, atau aturan kelulusan karena keputusan tersebut merupakan bagian dari kebijakan akademik.

Tujuan: mendukung kegiatan guru dan menghasilkan informasi yang bisa dipercaya orang tua.

Implementasikan presensi per sesi kelas, jadwal, tugas dan penilaian sesuai
workflows. Cegah presensi ganda pada siswa/sesi yang sama. Simpan koreksi
beserta alasan dan pelakunya. Guru hanya dapat mengubah kelas penugasannya.
Bobot nilai harus mengikuti aturan yang disetujui sekolah; jangan mengarang
rumus rapor. Terapkan draft, review, publish, dan versi revisi rapor.
Orang tua hanya melihat nilai yang dipublikasikan. Uji perubahan penugasan
guru, kenaikan kelas, pembulatan nilai, dan periode yang sudah dikunci.

Hasil dan pemeriksaan: nilai akhir cocok dengan perhitungan manual contoh sekolah. Koreksi tidak menghapus jejak nilai sebelumnya. Mulai dari presensi manual yang jelas sebelum menambahkan perangkat khusus.

13. Bangun tagihan dan pembayaran manual

Mulai dari pencatatan manual yang dapat diperiksa bendahara sebelum menghubungkan pembayaran online. Buat beberapa tagihan dummy, lakukan pembayaran sebagian, lalu cocokkan jumlah penerimaan dengan sisa kewajiban. Pertimbangkan apa yang terjadi jika petugas salah memasukkan nominal atau pembayaran perlu dibatalkan. Rancangan koreksi sebaiknya mempertahankan riwayat agar perubahan dapat dijelaskan kembali. Setelah alur ini stabil, integrasi gateway memiliki dasar pencatatan yang jelas.

Tujuan: membuat pencatatan kewajiban siswa yang dapat direkonsiliasi. Pada rancangan ini, dashboard tagihan belum disebut sistem akuntansi lengkap. Buku besar, jurnal berpasangan, tutup periode, dan laporan keuangan penuh merupakan lingkup tersendiri.

Bangun jenis biaya, invoice, rincian, jatuh tempo, diskon yang disetujui,
pembayaran manual, alokasi pembayaran, sisa tagihan dan kuitansi.
Gunakan nomor unik, transaksi database dan kontrol konkurensi.
Penerbitan ulang tagihan bulanan tidak boleh membuat duplikat.
Jangan menghapus transaksi yang sudah disahkan; gunakan koreksi/reversal
dengan alasan dan persetujuan. Ikuti aturan cicilan dan kelebihan bayar
dari workflows. Buat tes total tagihan, pembayaran sebagian dan pembatalan.

Hasil dan pemeriksaan: contoh uji usulan: tagihan Rp500.000 dibayar Rp200.000, sisa Rp300.000. Mengirim permintaan pembayaran yang sama dua kali tidak menambah penerimaan menjadi Rp400.000.

14. Integrasikan pembayaran online

Gunakan sandbox untuk seluruh percobaan awal. Skenario penting bukan hanya pembayaran berhasil, tetapi juga status pending, kedaluwarsa, notifikasi terlambat, dan pemberitahuan yang dikirim ulang. Catat satu identitas transaksi yang dapat ditelusuri dari invoice internal sampai respons penyedia. Sebelum beralih ke produksi, bendahara perlu memahami bagaimana memeriksa transaksi yang statusnya belum sinkron dan siapa yang berwenang melakukan rekonsiliasi atau tindak lanjut.

Tujuan: menghubungkan tagihan dengan penyedia pembayaran. Midtrans mendokumentasikan verifikasi signature dan penanganan notifikasi idempotent, yaitu pengulangan pemberitahuan tidak menciptakan efek transaksi ganda. Midtrans Webhooks (2026/10), verification and best practices; tanggal akses

Implement notification handling in an idempotent way.

Tangani notifikasi secara idempotent.

Midtrans Webhooks (2026/10), best practices; tanggal akses

Integrasikan payment gateway menggunakan sandbox dan dokumentasi resmi.
Server membuat order dari invoice yang boleh diakses pengguna; nominal
tidak dipercaya dari browser. Buat endpoint webhook yang memverifikasi
signature/status, nominal, mata uang, dan identitas transaksi sesuai API.
Terapkan idempotency, transaksi atomik, serta penanganan status terlambat
atau tidak berurutan. Jangan melunasi tagihan dari redirect sukses klien.
Sediakan rekonsiliasi status ke provider. Uji sukses, pending, expired,
signature salah, notifikasi ganda dan refund sesuai kemampuan provider.

Hasil dan pemeriksaan: pembayaran sandbox mengubah satu transaksi dan satu alokasi secara benar. Pembayaran berhasil tetapi notifikasi terlambat dapat direkonsiliasi. Aktivasi akun merchant dan penetapan biaya provider diselesaikan sebelum transaksi nyata.

15. Bangun portal orang tua dan notifikasi

Portal wali sebaiknya langsung menampilkan informasi yang paling sering dicari: anak yang sedang dipilih, kehadiran, tagihan, dan pengumuman. Jika wali mempunyai dua anak, pemilih anak harus terlihat jelas agar tagihan atau nilai tidak tertukar konteks. Notifikasi berfungsi sebagai pengingat menuju informasi di aplikasi. Hindari memasukkan seluruh detail pribadi dalam pesan singkat, terutama ketika pesan dapat terlihat di layar perangkat yang sedang terkunci.

Tujuan: orang tua melihat anak, presensi, tagihan, pengumuman, dan hasil belajar yang telah diterbitkan.

Bangun portal wali dengan pemilih anak terverifikasi. Tampilkan presensi,
tagihan, bukti bayar, pengumuman, dan nilai yang sudah diterbitkan.
Bangun kotak masuk internal lebih dahulu, kemudian adapter email/push.
Gunakan queue, retry terbatas, deduplikasi event, dan log pengiriman.
Jangan menaruh detail sensitif dalam preview notifikasi layar terkunci.
Jika WhatsApp belum terintegrasi, tandai dengan jelas dan jangan membuat
tombol yang mengaku sudah mengirim. Uji wali dua anak dan relasi dicabut.

Hasil dan pemeriksaan: notifikasi gagal tidak menggagalkan pencatatan pembayaran. Relasi wali yang dicabut tidak dapat memakai tautan lama untuk mengambil data anak.

16. Bangun kartu siswa digital

Tentukan dulu tujuan kartu digital. Jika tujuannya menunjukkan identitas, tampilkan informasi minimum yang dibutuhkan petugas. Jika hendak digunakan untuk presensi atau transaksi, susun aturan tambahan untuk kehilangan kartu, salinan kode, pencabutan, dan pemeriksaan petugas. Tutorial ini memulai dari identitas digital sederhana. Gunakan kartu dummy pada pengembangan dan beri penanda ilustrasi pada gambar contoh agar tidak disalahpahami sebagai kartu resmi sekolah.

Tujuan: menyediakan identitas digital dengan data minimum. Kartu identitas, bukti presensi, dan alat pembayaran adalah fungsi berbeda yang perlu keputusan terpisah.

Buat kartu digital berisi nama tampilan, nomor internal, foto yang diizinkan,
kelas dan QR token acak yang bisa dicabut. Jangan masukkan NIK, alamat,
tanggal lahir, atau seluruh profil ke QR. Endpoint verifikasi harus memeriksa
izin petugas dan hanya menampilkan data minimum.
Untuk presensi berbasis QR, buat rancangan terpisah yang menangani salinan
QR, sesi, masa berlaku dan pencatatan ganda. Jangan klaim QR statis
membuktikan pemilik kartu hadir. Uji token dicabut dan kartu diganti.

Hasil dan pemeriksaan: kartu lama dapat dinonaktifkan. Penambahan RFID, biometrik, atau uang saku ditempatkan dalam proyek lanjutan dengan evaluasi perangkat, data, dan penyedia layanan tersendiri.

Tahap D: Web dan aplikasi mobile

17. Siapkan kontrak API

Selesaikan satu endpoint kecil sampai tuntas sebelum memperbanyak API. Contohnya, endpoint daftar anak harus mengembalikan hanya anak yang terhubung dengan wali yang sedang login. Dokumentasikan pula respons saat tidak ada anak, token tidak berlaku, atau pengguna tidak memiliki izin. Aplikasi mobile kemudian dapat dibangun berdasarkan kontrak tersebut. Perubahan format respons perlu dicatat supaya perbaikan backend tidak diam-diam merusak layar yang sudah digunakan.

Tujuan: web dan aplikasi memakai aturan bisnis yang sama, dengan format pertukaran data yang terdokumentasi.

Dokumentasikan dan implementasikan API /api/v1 untuk login mobile, profil,
daftar anak terotorisasi, presensi, tagihan, pembayaran dan pengumuman.
Buat spesifikasi OpenAPI: request, response, error, pagination, filter,
autentikasi, izin dan contoh sintetis. Gunakan service/domain logic yang
sama dengan web. Terapkan rate limit dan hindari respons berisi seluruh
kolom model. Buat contract test dan tes akses lintas pengguna/sekolah.
Jelaskan kebijakan token kadaluarsa, pencabutan dan login kembali.

Hasil dan pemeriksaan: API bisa diuji tanpa aplikasi Flutter. Respons tidak menyertakan password hash, token lain, dokumen privat, atau data anak yang tidak terkait.

18. Siapkan web mobile dan PWA

Uji web langsung dari ponsel, bukan hanya mengecilkan jendela di komputer. Periksa keyboard saat mengisi formulir, posisi tombol, ukuran tabel, dan perilaku halaman ketika koneksi terputus. Jika menambahkan PWA, jelaskan kepada pengguna apa yang dapat diinstal dan apa yang masih memerlukan internet. Mulailah dengan portal responsif yang nyaman, lalu tambahkan kemampuan instalasi serta penanganan offline sesuai kebutuhan yang benar-benar telah ditentukan.

Tujuan: memberi akses HP sebelum rilis aplikasi native selesai. PWA yang dapat diinstal memerlukan manifest dan HTTPS pada deployment, dengan dukungan yang bergantung browser/platform. Instalasi PWA tidak otomatis membuat semua fungsi bekerja offline. MDN PWA (2026/10), installability; tanggal akses

HTTPS, localhost, or loopback are required

HTTPS, localhost, atau loopback diperlukan.

MDN PWA (2026/10), heading; tanggal akses

Audit tampilan portal pada HP. Tambahkan manifest, ikon dan pengalaman
instalasi PWA yang sesuai browser. Jika memakai service worker, cache
hanya aset yang aman dan halaman offline generik. Jangan cache otomatis
API autentikasi, dokumen, atau data keuangan. Pastikan logout membersihkan
data lokal yang sensitif. Jelaskan fitur yang tetap membutuhkan jaringan.
Uji update versi, offline, login ulang, dan pembersihan cache.

Hasil dan pemeriksaan: portal nyaman di HP dan memberi pesan yang jujur saat offline. Pengguna tidak melihat data akun sebelumnya pada perangkat bersama.

19. Bangun aplikasi Flutter

Gunakan API yang sama dengan hasil tahap sebelumnya. Hubungkan satu alur terlebih dahulu, misalnya login, memilih anak, lalu membaca tagihan. Setelah berhasil di perangkat nyata, lanjutkan ke presensi dan pengumuman. Layar perlu memperlihatkan proses memuat data serta pesan kegagalan yang bisa ditindaklanjuti. Bila koneksi gagal, pengguna sebaiknya mendapat pilihan mencoba kembali dan tidak menerima pesan sukses seolah perubahan sudah tersimpan di server.

Tujuan: menyediakan klien mobile yang terhubung API nyata. Dokumentasi Flutter merekomendasikan pemisahan lapisan UI dan data. Flutter Architecture (2026/10), recommendations; tanggal akses

Use clearly defined data and UI layers.

Gunakan lapisan data dan UI yang terdefinisi jelas.

Flutter Architecture (2026/10), recommendations; tanggal akses

Buat mobile/ dengan Flutter sesuai kontrak API. Pisahkan view, view model,
repository, dan service API. Implementasikan login, profil, pemilih anak,
presensi, tagihan, pengumuman, serta layar guru sesuai izin server.
Gunakan penyimpanan token aman yang sesuai platform; jangan hardcode secret.
Tangani timeout, tanpa jaringan, token tidak berlaku, tombol ganda,
pagination, refresh dan logout. Pisahkan konfigurasi staging/production.
Buat unit test logika, widget test keadaan layar, dan integration test
login -> pilih anak -> lihat tagihan. Hubungkan ke backend staging nyata.

Hasil dan pemeriksaan: perubahan presensi pada web terlihat pada mobile setelah refresh. Tidak ada daftar siswa hardcode. Jika memakai emulator, dokumentasikan alamat backend yang benar karena alamat localhost emulator tidak selalu menunjuk komputer pengembang.

Tahap E: Pengujian dan peluncuran

20. Uji fungsi, keamanan, dan performa

Buat daftar pengujian yang dapat dijalankan ulang sebelum setiap rilis. Pilih contoh yang mencerminkan kerugian nyata: wali melihat anak lain, pembayaran tercatat dua kali, berkas terbuka tanpa izin, atau nilai berubah setelah periode dikunci. Untuk performa, tentukan skenario pemakaian bersama sekolah. Jalankan pengukuran pada lingkungan yang mendekati produksi dan catat hasilnya. Jangan menyimpulkan kapasitas hanya dari banyaknya data dummy yang berhasil dimasukkan.

Tujuan: membuktikan alur yang berisiko sebelum digunakan sekolah. Pemeriksaan otorisasi objek perlu dilakukan pada akses data melalui ID. OWASP API1 (2023), prevention

Audit implementasi terhadap requirements dan buat test matrix berbasis risiko.
Prioritas: akses lintas wali/sekolah, unggah berkas, perubahan peran,
duplikasi pembayaran, koreksi nilai dan ekspor data.
Jalankan unit, integration dan end-to-end test yang relevan. Uji beban
dengan target yang disepakati, bukan angka kapasitas yang dikarang.
Catat error rate, waktu respons, query lambat dan queue backlog.
Laporkan bukti hasil, cacat, tingkat dampak, serta tes yang belum dijalankan.
Perbaiki akar masalah dan ulangi tes terkait sebelum menandai siap.

Hasil dan pemeriksaan: laporan berisi hasil nyata. Jumlah siswa terdaftar tidak disamakan dengan jumlah pengguna serentak. Uji penerimaan dilakukan bersama operator, guru, bendahara, dan wali contoh.

21. Siapkan privasi dan operasional data

Inventaris data membantu sekolah mengambil keputusan yang konkret. Untuk setiap kolom, tanyakan mengapa diperlukan, siapa yang boleh melihat, dan kapan tidak lagi dibutuhkan. Pisahkan keputusan operasional dari penilaian hukum yang perlu ditinjau pihak berwenang. Pada pengembangan dan pelatihan, tetap gunakan data sintetis. Sebelum migrasi nyata, pastikan sekolah memiliki proses untuk memverifikasi hubungan wali, memperbaiki data yang salah, dan menindaklanjuti permintaan terkait data.

Tujuan: menetapkan pengelolaan data sebelum memasukkan data nyata. UU 27/2022 menggolongkan data anak sebagai data pribadi spesifik. Penentuan kewajiban yang berlaku perlu mempertimbangkan bentuk layanan, peran para pihak, dan aturan terkait. UU PDP (2022/10), Pasal 4

Buat inventaris data: kolom, tujuan, pihak pengakses, sumber, tempat simpan,
masa retensi usulan dan prosedur koreksi/penghapusan sesuai kewajiban.
Susun draf pemberitahuan privasi dan daftar keputusan yang harus ditinjau
pengelola sekolah serta pihak hukum. Bedakan sekolah dan penyedia aplikasi.
Petakan alur data anak, akun wali, vendor pembayaran dan notifikasi.
Jangan mengklaim kepatuhan otomatis atau mengarang dasar hukum.
Buat prosedur verifikasi wali, penanganan permintaan data dan insiden.

Hasil dan pemeriksaan: pengelola menyetujui siapa berwenang mengakses dan mengekspor data. Draf AI tidak dianggap sebagai pengesahan hukum. Jangan mengunggah data siswa nyata ke layanan AI tanpa dasar dan pengaturan yang tepat.

22. Deploy web dan backend

Siapkan staging sebagai tempat latihan sebelum menyentuh produksi. Gunakan konfigurasi yang terpisah agar percobaan pembayaran atau pengiriman notifikasi tidak mengenai pengguna nyata. Setelah deployment, uji pekerjaan latar seperti pengiriman pesan dan pembuatan laporan, bukan hanya halaman login. Siapkan pula prosedur kembali ke versi sebelumnya. Jika deployment mengubah struktur database, rencana pemulihannya perlu mempertimbangkan data yang sudah masuk setelah perubahan tersebut.

Tujuan: memindahkan aplikasi teruji ke lingkungan yang dapat digunakan. Dokumentasi Laravel menekankan document root pada direktori publik, debug produksi nonaktif, serta pengelolaan proses aplikasi. Laravel Deployment (2026/10), server configuration; tanggal akses

In your production environment, this value should always be false.

Di lingkungan produksi, nilai ini harus selalu false.

Laravel Deployment (2026/10), debug mode; tanggal akses

Susun deployment untuk hosting yang saya pilih. Verifikasi runtime dan
ekstensi, domain, HTTPS, document root public/, izin file, secret,
database privat, queue worker, scheduler, email, dan storage privat.
Pisahkan staging dari production, termasuk database dan kunci pembayaran.
Buat pipeline build/test, backup sebelum migration, health check dan
rencana rollback yang mempertimbangkan kompatibilitas skema database.
Set APP_DEBUG=false. Jangan memakai chmod 777 sebagai solusi umum.
Tampilkan runbook dan pemeriksaan pascadeploy sebelum peluncuran publik.

Hasil dan pemeriksaan: HTTPS bekerja, login dan upload berjalan, queue memproses pekerjaan, cron aktif, log tidak mengandung secret, dan endpoint kesehatan dipantau. Jangan hanya memeriksa halaman depan.

23. Rilis aplikasi Android dan iOS

Mulailah dari distribusi pengujian internal. Gunakan build release untuk memeriksa perilaku yang akan diterima pengguna, termasuk koneksi ke backend produksi yang telah disiapkan, izin perangkat, dan proses login. Materi distribusi perlu sesuai kemampuan aplikasi yang benar-benar tersedia. Jika rilis iOS belum dapat dikerjakan karena perangkat atau akun belum tersedia, catat kebutuhan tersebut secara terbuka dan selesaikan jalur Android serta web sesuai ruang lingkup yang disepakati.

Tujuan: menghasilkan build produksi serta menyiapkan distribusi. Dokumentasi Flutter mencakup signing dan app bundle Android. Untuk iOS, build/rilis memerlukan Xcode pada macOS; distribusi App Store melibatkan program pengembang Apple serta peninjauan. Flutter Android Release (2026/10); Flutter iOS Release (2026/10), tanggal akses

Siapkan rilis mobile berdasarkan dokumentasi Flutter dan kebijakan store
yang berlaku saat ini. Untuk Android periksa application ID, versi,
permission minimum, signing, secret build dan flutter build appbundle.
Siapkan pengujian internal, deskripsi, screenshot, kebijakan privasi,
deklarasi data dan akun reviewer yang sesuai. Untuk iOS buat checklist
macOS/Xcode, bundle ID, signing, App Store Connect, TestFlight dan review.
Jangan menjanjikan persetujuan store. Catat langkah yang memerlukan akun
atau perangkat saya, dan jangan memasukkan kunci signing ke repositori.

Hasil dan pemeriksaan: build release diuji pada perangkat nyata. APK yang terpasang sendiri belum berarti aplikasi sudah tersedia di Play Store. Periksa kembali syarat akun, target SDK, privasi, dan biaya pada saat pengajuan.

24. Migrasi, pilot, dan serah terima

Pilih kelompok pilot yang cukup kecil untuk didampingi, tetapi mewakili alur penting. Sertakan operator, guru, bendahara, dan beberapa wali contoh. Catat pertanyaan yang muncul saat mereka memakai aplikasi karena pertanyaan itu sering menunjukkan bagian antarmuka atau panduan yang perlu diperbaiki. Setelah pilot, cocokkan kembali data dan saldo. Serah terima dilakukan berdasarkan bukti pekerjaan yang berjalan, daftar masalah terbuka, serta tanggung jawab dukungan yang disepakati.

Tujuan: memastikan sekolah dapat berpindah dari proses lama tanpa kehilangan data dan tanggung jawab.

Susun rencana pilot satu kelas dan satu periode tagihan. Buat pemetaan
kolom sumber, pembersihan data, dry run, rekonsiliasi jumlah siswa dan
saldo awal, serta log baris gagal. Tentukan waktu cutover, batas perubahan
data lama, kriteria go/no-go dan prosedur kembali jika gagal.
Siapkan panduan operator, guru, bendahara dan wali dengan contoh sintetis.
Buat berita acara penerimaan berdasarkan skenario yang benar-benar diuji,
daftar masalah terbuka, pemilik masalah dan jadwal penanganannya.

Hasil dan pemeriksaan: jumlah siswa, hubungan wali, kelas, dan saldo awal sesuai sumber yang disahkan. Pengelola dapat melakukan tugas tanpa bantuan pengembang terus-menerus. Peluncuran seluruh sekolah menunggu hasil pilot.

25. Pemeliharaan dan pemulihan

Susun jadwal pemeriksaan rutin dan tentukan siapa yang menerima pemberitahuan ketika terjadi gangguan. Backup perlu mencakup database serta berkas yang diperlukan untuk memulihkan layanan. Lakukan latihan restore pada lingkungan terpisah agar prosesnya diketahui sebelum dibutuhkan. Catat berapa lama pemulihan berlangsung dan data sampai waktu mana yang kembali tersedia. Gunakan hasil latihan tersebut untuk menyesuaikan target operasional, prosedur, dan anggaran pemeliharaan.

Tujuan: menjaga aplikasi tetap bekerja setelah rilis. PostgreSQL menyediakan beberapa pendekatan backup, termasuk SQL dump, backup filesystem, dan continuous archiving. Pilih metode sesuai kebutuhan pemulihan, bukan sekadar karena mudah dijadwalkan. PostgreSQL Backup (2026/10), pengantar; tanggal akses

SQL dump

Dump SQL

PostgreSQL Backup (2026/10), metode backup; tanggal akses

Buat runbook operasional: monitoring uptime, error, database, storage,
queue, masa berlaku domain/sertifikat, serta pembaruan dependensi.
Tetapkan RPO dan RTO bersama sekolah: kehilangan data maksimum yang
ditoleransi dan target waktu pulih. Rancang backup database dan berkas
terpisah dari server utama, terenkripsi, dengan retensi dan kontrol akses.
Jadwalkan uji restore ke lingkungan terisolasi dan catat hasil aktual.
Buat prosedur insiden, rotasi kunci, penonaktifan akun staf keluar,
rekonsiliasi pembayaran dan komunikasi gangguan kepada pengguna.

Hasil dan pemeriksaan: pemulihan pernah diuji, bukan hanya mempunyai file backup. Contoh target internal yang harus disepakati, bukan janji: RPO satu jam dan RTO empat jam. Sesuaikan arsitektur serta biaya jika target tidak tercapai.

Estimasi waktu dan anggaran

Angka berikut estimasi perencanaan penulis, bukan hasil pengukuran proyek, harga vendor, atau jaminan. Asumsi: satu sekolah, data awal cukup rapi, pengembang berpengalaman, ruang lingkup dikendalikan, dan penanggung jawab sekolah aktif mengambil keputusan.

Sebagian pekerjaan dapat tumpang tindih. Perencanaan awal keseluruhan sekitar 3–5 bulan untuk cakupan terkontrol lebih layak dijadikan hipotesis daripada janji selesai dalam beberapa hari. Pemula yang belajar sambil mengerjakan bisa membutuhkan jauh lebih lama. LMS, CBT, akuntansi lengkap, dompet uang saku, multisekolah, atau integrasi perangkat memperluas proyek. Waktu review store berada di luar kendali pengembang.

Jangan langsung membeli banyak layanan. Susun anggaran berdasarkan komponen berikut dan minta penawaran aktual ketika pilihan sudah jelas:

Buat spreadsheet rancangan anggaran dari backlog ini. Pisahkan biaya
sekali bayar, bulanan/tahunan dan per transaksi. Gunakan tiga skenario
jumlah pengguna dan beban, serta cantumkan asumsi. Untuk tarif vendor,
cari halaman resmi terbaru, tanggal akses, mata uang dan pajak; jika
tidak tersedia tulis perlu penawaran. Jangan membuat harga seolah pasti.

Prompt perbaikan dan kelanjutan pekerjaan

Jika terjadi error:

Tahap saat ini: [nomor]. Tujuan: [tujuan]. Perintah: [perintah].
Versi runtime: [versi]. Hasil yang diharapkan: [hasil].
Pesan error yang sudah dibersihkan dari secret: [pesan].
File relevan: [file].
Cari akar masalah, jelaskan bukti, perbaiki seminimal mungkin dan jalankan
tes terkait. Jangan menyelesaikan error dengan menghapus otorisasi,
validasi, atau pengujian. Jangan ubah stack atau mengulang proyek dari nol.

Jika pindah percakapan atau alat AI:

Baca docs/requirements.md, architecture.md, data-model.md, backlog.md,
progress.md, serta lockfile. Ringkas status nyata: selesai, belum selesai,
masalah aktif dan keputusan versi. Periksa kode sebelum mempercayai catatan.
Lanjutkan pekerjaan pertama yang dependensinya sudah siap. Jangan membuat
implementasi duplikat atau menghapus fitur yang sudah bekerja.

Jika hasil AI tampak bagus tetapi belum berfungsi:

Audit fitur [nama] dari klik pengguna sampai database. Identifikasi semua
mock, hardcode, tombol tanpa aksi, respons sukses palsu, dan error yang
ditelan. Hubungkan alur dengan backend dan aturan izin yang benar.
Buktikan data tetap tersimpan setelah refresh dan aplikasi dibuka ulang.
Laporkan apa yang benar-benar diuji dan apa yang masih terhambat.

Kriteria aplikasi benar-benar selesai

Gunakan daftar penerimaan yang disepakati sekolah, minimal:

• Alur utama bekerja dengan database dan API nyata, tanpa placeholder tersembunyi.
• Hak akses diuji pada endpoint, ekspor, dan berkas, termasuk lintas wali/sekolah.
• Tagihan, pembayaran, pembatalan, dan saldo dapat direkonsiliasi.
• Web nyaman digunakan di perangkat target; build mobile produksi telah diuji.
• Staging dan produksi terpisah, secret tidak bocor, queue dan scheduler berjalan.
• Data migrasi disahkan, operator dilatih, dan ada penanggung jawab bantuan.
• Backup dapat dipulihkan dalam target yang disepakati.
• Pengelolaan privasi, retensi dan insiden ditetapkan oleh pengelola.
• Source code, konfigurasi contoh, dokumentasi dan kepemilikan akun diserahterimakan.
• Cacat yang belum selesai dicatat dengan dampak dan jadwal, bukan disembunyikan.

Pertanyaan yang sering diajukan

Apakah pemula bisa mengikuti tutorial ini?

Bisa dimulai dari persiapan dan perencanaan, lalu dikerjakan secara bertahap. Beri tahu AI sistem operasi dan kemampuan Anda. Untuk bagian yang menyangkut transaksi, akses data, dan peluncuran, minta pengembang yang kompeten meninjau hasil implementasi sebelum digunakan sekolah.

Apakah harus langsung membuat aplikasi Android dan iOS?

Dalam alur tutorial ini, web responsif dan backend disiapkan terlebih dahulu. Setelah API stabil, aplikasi mobile dibangun. Cara ini membuat pengujian aturan sekolah dapat dimulai sebelum seluruh jalur distribusi aplikasi selesai.

Apakah semua prompt dikirim sekaligus?

Gunakan prompt induk terlebih dahulu, kemudian prompt tahap yang sedang dikerjakan. Sertakan hasil dan keputusan dari tahap sebelumnya. Mengirim semua tahap dalam satu pesan membuat pemeriksaan hasil per langkah lebih sulit dilakukan.

Apa yang dilakukan jika jawaban AI berbeda dengan proyek?

Kirim versi dependensi, struktur file relevan, perintah yang dijalankan, dan pesan error yang sudah dibersihkan dari secret. Gunakan prompt perbaikan pada artikel ini. Minta AI memeriksa proyek sebelum menulis solusi agar contoh dari versi lain tidak diterapkan begitu saja.

Apakah ilustrasi menunjukkan hasil aplikasi yang langsung diperoleh?

Gambar merupakan ilustrasi AI untuk membantu memahami konteks tiap langkah. Tampilan akhir aplikasi mengikuti implementasi dan keputusan desain Anda. Gambar bukan screenshot produk, bukti pengujian, atau source code yang bisa langsung dipasang.

Apakah aplikasi dianggap selesai ketika dashboard sudah tampil?

Periksa juga penyimpanan data, izin pengguna, transaksi, pengujian perangkat, migrasi, backup dan kemampuan petugas menjalankan tugas. Gunakan kriteria penerimaan di artikel sebagai dasar pembahasan dengan sekolah.

Bacaan dan alat pendukung

Untuk menjelajahi topik teknologi lainnya, kunjungi blog Tumbas.in. Saat membagikan tautan panduan sekolah kepada peserta pelatihan, Anda dapat memakai pemendek tautan dan pembuat QR Code. QR untuk membagikan tautan informasi berbeda kegunaannya dari token kartu siswa dan tidak menggantikan pemeriksaan akses pada aplikasi.

Catatan penggunaan

Panduan ini memakai dokumentasi resmi yang ditelusuri pada 16 Oktober 2026. Contoh sekolah, antarmuka, dan seluruh gambar merupakan ilustrasi. Rancangan teknologi yang dipilih adalah contoh implementasi tutorial, bukan keterangan tentang teknologi internal produk lain. Versi dependensi, kebijakan distribusi aplikasi, dan tarif layanan perlu diperiksa kembali saat proyek dimulai.

Artikel ini menyediakan urutan pembangunan dan prompt. Penerapan pada proyek Anda memerlukan eksekusi, pengujian, serta keputusan pengelola sekolah. Estimasi pengerjaan adalah asumsi perencanaan yang perlu disesuaikan dengan cakupan dan kemampuan tim.

Daftar sumber

SkoolaCloud, 2026/10; akses SkoolaCloud. “Sistem Informasi Manajemen Sekolah.” Halaman produk resmi; klaim penyedia. https://skoolacloud.id/

Laravel Installation, 2026/10; akses Laravel. “Installation.” Dokumentasi resmi 13.x. https://laravel.com/framework/docs/13.x/installation

Laravel Sanctum, 2026/10; akses Laravel. “Laravel Sanctum.” Dokumentasi resmi 13.x. https://laravel.com/docs/13.x/sanctum.md

Laravel Deployment, 2026/10; akses Laravel. “Deployment.” Dokumentasi resmi 13.x. https://laravel.com/framework/docs/13.x/deployment

Flutter Architecture, 2026/10; akses Flutter. “Architecture recommendations and resources.” Dokumentasi resmi. https://docs.flutter.dev/app-architecture/recommendations

Flutter Android Release, 2026/10; akses Flutter. “Build and release an Android app.” Dokumentasi resmi. https://docs.flutter.dev/deployment/android

Flutter iOS Release, 2026/10; akses Flutter. “Build and release an iOS app.” Dokumentasi resmi. https://docs.flutter.dev/deployment/ios

MDN PWA, 2026/10; akses MDN contributors. “Making PWAs installable.” Dokumentasi web. https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Making_PWAs_installable

Midtrans Webhooks, 2026/10; akses Midtrans. “HTTP(S) Notification / Webhooks.” Dokumentasi resmi integrasi. https://docs.midtrans.com/docs/https-notification-webhooks

OWASP API1, 2023 OWASP. “API1:2023 Broken Object Level Authorization.” Panduan keamanan proyek resmi. https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/

UU PDP, 2022/10 Republik Indonesia. “Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi.” JDIH BPK. https://peraturan.bpk.go.id/Details/229798/uu-no-27-tahun-2022

PostgreSQL Backup, 2026/10; akses PostgreSQL Global Development Group. “Backup and Restore.” Dokumentasi resmi. https://www.postgresql.org/docs/current/backup.html