APMNU — Asosiasi Profesor Muslimat NU

Platform Asosiasi Profesor Muslimat NU: direktori profesor publik, portal self-service untuk profesor, dan panel admin untuk mengelola keanggotaan serta konten. Saya memimpin tim 4 developer sebagai Project Manager sekaligus kontributor utama — dari menerjemahkan kebutuhan klien jadi PRD sampai handover dokumentasi.

Problem

Data guru besar perempuan NU tersebar di dokumen resmi organisasi. Tidak ada direktori publik yang bisa dicari, tidak ada alur pendaftaran anggota yang terverifikasi, dan publikasi kegiatan bergantung pada kanal yang terpisah-pisah. Organisasi juga butuh cara agar profesornya bisa dihubungi sebagai narasumber tanpa admin jadi perantara.

Solution

Membangun monorepo berisi tiga aplikasi — REST API, website publik, dan dashboard admin — di atas satu skema data. Pendaftaran anggota lewat alur tinjauan admin bertingkat, profil profesor bisa diperkaya sendiri setelah disetujui, dan konten organisasi dikelola non-teknis lewat panel admin.

Architecture Decisions

• Turborepo dengan packages/schemas berisi Zod schema bersama — API dan kedua frontend memvalidasi dengan definisi yang sama persis, jadi aturan bisnis tidak pernah menyimpang antar aplikasi
• SK Guru Besar dijadikan satu-satunya dasar verifikasi keanggotaan, sehingga field lain boleh diedit profesor tanpa perlu approval ulang admin — mengurangi beban admin tanpa mengorbankan keabsahan data
• Memisahkan status registrasi (PENDING/APPROVED/REJECTED/NEED_REVISION) dari status keanggotaan (ACTIVE/EMERITUS/DECEASED) sebagai dua konsep berbeda — dua hal ini sering tertukar dan menyebabkan bug data
• Admin dashboard dibuat sebagai aplikasi terpisah, bukan route yang di-gate role di website publik — bundle publik tetap ringan dan permukaan serangannya lebih kecil
• “Undang Narasumber” pakai mailto: langsung ke email profesor, bukan sistem pesan internal — menghindari membangun inbox yang tidak akan dipakai
• Penamaan menu sengaja netral terhadap nama pejabat (“Jejak Intelektual”, bukan nama Ketua Umum) supaya tidak basi saat kepengurusan berganti
• Ketiga app dikemas jadi image Docker terpisah dan didorong ke GHCR dengan tag commit SHA — deploy dan rollback cukup menukar tag, tidak perlu build di server
• CI memakai deteksi perubahan per-path, jadi PR yang cuma menyentuh satu app tidak memicu lint, typecheck, dan build ketiganya

Trade-offs

• Memilih mailto: daripada messaging internal: kehilangan tracking percakapan, tapi hemat satu modul penuh yang belum terbukti dibutuhkan
• Profesor boleh mengedit sendiri field non-SK tanpa verifikasi ulang: menerima risiko data tidak akurat demi menghapus bottleneck admin
• Dua aplikasi Nuxt terpisah berarti sebagian layout dan komponen harus dibagikan lewat packages/ui — biaya setup awal lebih tinggi, tapi terbayar saat kedua app berkembang beda arah

Features

• Direktori profesor publik yang bisa dicari dan difilter
• Pendaftaran anggota dengan alur tinjauan admin bertingkat
• Kartu anggota digital berbasis QR
• Portal self-service untuk profesor mengisi riwayat pendidikan, publikasi, dan URL akademik
• Manajemen berita dan konten organisasi lewat rich text editor
• Visualisasi sebaran anggota
• Halaman kontak organisasi berbasis form
• Dokumentasi API otomatis lewat Swagger

CV Highlights

• Membangun platform organisasi dari nol: website publik, admin portal, dan REST API dalam satu monorepo
• Memimpin tim developer lewat sprint planning dan weekly meeting, sekaligus jadi penghubung langsung ke klien
• Menerjemahkan kebutuhan klien jadi PRD dan backlog di Jira dan Linear, lalu mendistribusikan pekerjaan ke tim
• Memimpin migrasi tracker dari Linear ke Jira
• Menetapkan standar dokumentasi fitur, konvensi API (Swagger dan Zod), dan alur rilis yang diikuti seluruh tim
• Menggerakkan migrasi konten dan data awal dari dokumen resmi organisasi, serta menulis panduan pengguna untuk handover
• Menyiapkan pipeline CI/CD dari lint dan typecheck sampai build image dan deploy otomatis ke VPS staging dan production

Challenges Overcome

• Menjaga konsistensi validasi antara API dan dua frontend tanpa duplikasi aturan
• Merancang alur revisi pendaftaran yang jelas bagi pendaftar sekaligus bagi admin peninjau
• Menyusun kosakata domain yang disepakati tim agar istilah organisasi tidak tertukar di kode
• Memindahkan tim dari Linear ke Jira di tengah project tanpa kehilangan konteks backlog

Lessons Learned

• Menyepakati kosakata domain lebih awal mencegah kelas bug yang sulit dilacak — status registrasi dan status keanggotaan terlihat mirip sampai keduanya salah dipakai di produksi
• Mencatat keputusan arsitektur sebagai ADR membuat pertanyaan “kenapa dulu begini” bisa dijawab tanpa mengganggu orang yang menulisnya
• Sebagai PM sekaligus developer, menulis PRD lebih dulu memaksa kejelasan yang justru mempercepat implementasi