Muhammad Royhan
Senior Fullstack Engineer · Team Lead
Sistem yang salah angkanya berarti gaji orang tidak sampai — payroll, kredit, compliance.
Tujuh tahun membangun sistem yang tidak boleh salah.
Backend dan frontend. Tujuh tahun, tiga promosi, satu perusahaan. Cara kerja saya bertumpu pada systems thinkingMemahami sistem dari cara bagian-bagiannya saling memengaruhi dari waktu ke waktu, bukan dari satu bagian yang dilihat terpisah. dan fokus ke hal yang bisa dikendalikanDikotomi kendali dari Stoikisme: keluarkan tenaga hanya untuk hal yang benar-benar bisa kita pengaruhi, lalu rancang sistem untuk mengantisipasi sisanya., supaya sistemnya tetap bisa dirawat setelah saya serahkan.
- 7 tahun, 1 perusahaan
- 3 promosi sampai Team Lead
- Payroll 800+ karyawan
- Perbankan · ERP · Marketplace
Apa tech stack Royhan?
Frontend: React.js, Next.js, Flutter, TypeScript. Backend: Node.js, Express.js, NestJS, Sequelize.js. Infra: MySQL, Docker, AWS SQS. Saya pilih tool yang tetap stabil waktu sistem sedang ramai, bukan yang paling baru.
Ceritakan tentang proyek sistem payroll.
Sistem payroll untuk 800+ karyawan, mencakup PPh 21 (metode TER), BPJS, dan PP 58/2023. Setiap run idempoten, setiap angka bisa dilacak balik ke sumbernya lewat audit trail generik di sepuluh entitas. Saya bangun dari sistem internal kecil di 2024 sampai rilis produksi penuh Juni 2026, dan masih saya rawat sampai sekarang.
Apakah Royhan terbuka untuk kerja kontrak?
Ya. Saya remote-first, di WIB (UTC+7), terbuka untuk EOR, kontrak, atau full-time dengan notice period dua minggu. Paling cocok untuk sistem yang salah angkanya berkonsekuensi hukum atau finansial — payroll, kredit, compliance.
Kenapa Royhan bertahan 7 tahun di satu perusahaan?
Bukan karena passion menulis kode. Saya bertahan karena makin lama saya di bidang ini, makin banyak orang bergantung pada hasil kerja saya. Tiga promosi kemudian (Junior sampai Team Lead), saya masih di sana, sekarang memimpin sistem yang gaji dan utang orang lain bergantung padanya.
Junior Software Engineer
Mulai dari kode legacy orang lain
Saya menghindari pekerjaan sebagai Software Engineer karena terlalu banyak saingan, tapi Moving Bytes Digital memberi saya kesempatan di tahun 2019. Pekerjaan pertama saya melanjutkan proyek ERP yang sudah berjalan, disusul proyek marketplace sewa barang yang sebelumnya sudah dikerjakan tim lain.
Sampai 2021 saya merawat marketplace itu sembari membangun aplikasi mobile-nya bersama tim. Dari situ muncul pertanyaan yang saya bawa sampai sekarang. Bagaimana caranya mengambil keputusan yang benar kalau variabelnya bukan milik kita?
Senior Software Engineer
Sistem bank, dari nol sampai serah terima
Tahun 2022 saya pegang sistem kredit karyawan untuk Bank Perkreditan Rakyat. Dari commit pertama sampai serah terima. Proyek pertama yang saya kerjakan sendiri dari awal, di bidang yang tidak menoleransi kesalahan sekecil apa pun.
Di sistem kredit karyawan, tidak ada bug yang sifatnya cuma tampilan. Angka yang salah itu utang seseorang. Tapi yang paling banyak mengajari saya justru serah terimanya: kode yang dilepas ke tim lain harus bisa menjelaskan dirinya sendiri, tanpa saya di ruangan.
Team Lead — Maintenance Sistem Legacy
Dipromosikan untuk merawat sistem orang lain
Promosi Team Lead datang tahun 2023. Bukan yang membangun sistem baru, bukan juga yang memimpin proyek unggulan. Yang menjaga semua sistem yang sudah rilis tetap jalan.
Hampir sepanjang tahun itu saya bekerja di dalam keputusan yang bukan saya buat, di kode yang tidak boleh saya tulis ulang, dengan tenggat yang bukan saya tentukan. Pelajarannya satu. Sistem yang kita lanjutkan hampir tidak pernah bisa kita kendalikan. Yang bisa kita kendalikan cuma satu: apakah orang berikutnya menerimanya dalam kondisi lebih jelas.
Setelah tujuh tahun, kira-kira begini saya memilahnya. Coba dulu beberapa sebelum lihat jawaban saya.
Codebase yang kita lanjutkan
Jawaban saya: Tidak bisa — Keputusan yang sudah terlanjur dibuat bukan pilihan kita. Yang jadi pilihan kita cuma satu: apakah orang berikutnya menerimanya lebih jelas.
Tenggat dari klien
Jawaban saya: Tidak bisa — Jarang kita yang menentukan. Yang milik kita adalah sejujur apa kita menyusun scope terhadap tenggat itu.
Struktur codebase
Jawaban saya: Bisa dikendalikan — Ini benar-benar milik kita. Sebagian besar pekerjaan ada di sini.
Cara rekan tim melakukan debugging
Jawaban saya: Tidak bisa — Kita bisa kasih konteks dan dokumentasi. Kita tidak bisa memaksa orang berpikir dengan cara kita.
Apakah API pihak ketiga tetap hidup
Jawaban saya: Tidak bisa — Yang bisa kita atur cuma perilaku sistem kita saat API itu mati.
Test coverage di kode yang kita rilis
Jawaban saya: Bisa dikendalikan — Tidak ada orang lain yang menentukan ini. Kalau tipis, itu keputusan kita sendiri.
Team Lead
Payroll untuk 800+ karyawan
Dua tahun, dua sistem, satu engineer di masing-masing. Scroll untuk lihat bagaimana skalanya berubah, dan apa akibatnya ke arsitektur.
Satu perusahaan
2024. Sistem payroll untuk perusahaan sendiri. Internal, skala kecil, risikonya masih terkendali. Kalau ada yang rusak, saya dengar langsung dari meja sebelah.
Jalan benar selama setahun. Sistem itu lalu jadi fondasi untuk versi klien. Bukan bikin ulang, tapi melanjutkan.
2025. Masalah yang sama, tapi untuk klien dengan lebih dari 800 karyawan. Di titik ini angka yang salah bukan lagi laporan bug. Itu gaji yang tidak sampai.
Jadi saya dahulukan keterlacakan di atas kecepatan. Setiap angka bisa dilacak sampai ke sumbernya, setiap payroll run bisa dihitung ulang dari nol.
Rilis Juni 2026. Jalan terus sejak itu, dan sampai sekarang masih saya yang rawat.
Ringkasan prinsip
- Premis I
- Salah hitung payroll bukan laporan bug. Itu gaji yang tidak sampai.
- Premis II
- Angka yang tidak bisa dihitung ulang dari sumbernya cuma bisa dipercaya, bukan diverifikasi.
- Kesimpulan
- Bangun supaya setiap angka bisa dihitung ulang. Kepercayaan bukan pengendalian.
Team Lead
Posisi saya sekarang
Balik ke pertanyaan di awal. Bagaimana caranya mengambil keputusan yang benar kalau variabelnya bukan milik kita?
Sampai sekarang saya belum punya jawaban yang tepat. Saya sudah berhenti menunggu. Yang saya punya adalah prinsip kerja: pisahkan yang bisa dirancang (batas modul, kepemilikan, keterlacakan) dari yang cuma bisa dihadapi.
Saya masuk bidang ini bukan karena passion. Saya bertahan karena ada orang yang bergantung pada hasil kerja saya. Ternyata itu alasan yang jauh lebih kuat.
Di luar proyek payroll, Maret–Juni 2025 saya dipercaya perusahaan untuk proyek sampingan lintas negara. Semacam pembuktian apakah saya bisa sejajar dengan engineer dari negara lain.
Proyek Terpilih
Sistem produksi di balik cerita di atas, dibahas lengkap.
2024 — 2026 · Team Lead
Sistem Payroll 800+ Karyawan→
Engine payroll dengan PPh 21 TER, BPJS, dan PP 58/2023. Payroll run idempoten, audit trail 10 entitas, setiap angka bisa dilacak sampai ke sumbernya.
- NestJS
- TypeScript
- MySQL
- AWS SQS
- React.js
- Docker
2022 · Senior Software Engineer
Sistem Kredit Karyawan untuk Bank Perkreditan Rakyat→
Proyek pertama yang saya pegang penuh, dari commit pertama sampai serah terima. Tiga portal, alur approval berjenjang, dan output akhirnya bukan layar — tapi PKS yang ditandatangani.
- Node.js
- Express.js
- Sequelize.js
- MySQL
- React.js
Tech Stack
Alat yang saya pakai. Dipilih karena tidak bikin kejutan waktu sistem lagi ramai.
Frontend
- React.js
- Next.js
- Flutter
- TypeScript
Backend
- Node.js
- Express.js
- NestJS
- REST API
- Sequelize.js
- JavaScript
Infra & Tools
- MySQL
- Docker
- GitHub
- Postman
Kapan saya cocok direkrut
Hubungi kalau situasinya salah satu dari ini.
- Angka yang salah punya konsekuensi hukum atau finansial. Payroll, kredit, compliance, apa pun yang hasilnya ditandatangani orang.
- Codebase payroll, kredit, atau compliance yang sudah tidak ada lagi yang paham sepenuhnya.
- Tim kehilangan senior engineer yang memegang konteksnya.
- Sistem yang harus lolos audit, atau diserahterimakan ke tim yang tidak ikut membangunnya.
- Remote-first
- WIB · UTC+7
- EOR, kontrak, atau full-time
- Notice period 2 minggu
Sedang mencari Senior Fullstack Engineer atau Team Lead?
Silakan hubungi langsung, tidak perlu isi form.