Yang Saya Lakukan di Level CTO — Strategi Bisnis Melalui Teknologi

Saya mengirim fitur nyata ke pengguna nyata. Saya merusak produksi dan memperbaikinya sendiri jam 2 pagi. Saya membangun aplikasi mobile banking dengan 680 ribu unduhan, sistem armada tambang yang menghemat $200K/tahun, dan platform operasi lapangan untuk 4,1 juta pengguna. Inilah gambaran nyata engineering mid-level — proyek, metrik, dan insiden produksi yang menjadikan saya seorang engineer sejati.

"Mid-level adalah fase di mana kamu berhenti menulis kode yang berfungsi dan mulai menulis kode yang bertahan." — Saya, setelah rollback produksi ke-14
Tahun-tahun mid-level mengubahmu dari "seseorang yang bisa coding" menjadi "seseorang yang bisa mengirim produk." Perubahannya fundamental: kamu tidak lagi dinilai dari apakah kode kamu berjalan. Kamu dinilai dari apakah kode kamu bertahan di produksi — dalam skala besar, di bawah beban, saat semuanya kacau jam 3 pagi.
Sebelum (Junior): "Bisakah kamu menulis kode yang berfungsi?" Sekarang (Mid): "Bisakah kamu memiliki sebuah fitur dari ujung ke ujung — desain, bangun, tes, deploy, monitor, debug, dan iterasi — tanpa ditemani orang lain?"
Peran: Backend Engineer Tunggal Stack: Go, Flutter, ISO 8583, PostgreSQL Skala: 680 Ribu+ unduhan Google Play, zero downtime selama lonjakan transaksi Lebaran
Ini adalah sistem produksi "sungguhan" pertama saya. Bukan situs WordPress. Bukan aplikasi CRUD. Sebuah aplikasi mobile banking yang harus terintegrasi langsung dengan sistem inti bank melalui protokol ISO 8583.
Yang terjadi: Selama libur Idul Fitri (volume transaksi tertinggi tahun ini), jembatan ISO 8583 mulai timeout pada 30% permintaan. Mainframe bank merespons dengan benar — jembatan kamilah yang jadi hambatan.
Akar masalah: Kami membuka koneksi TCP baru untuk setiap pesan ISO. Pada 500+ permintaan konkuren, kumpulan koneksi habis. Perbaikannya adalah menerapkan koneksi persisten dengan health check.
Pelajaran: Integrasi tingkat protokol bukan "sekadar API lain." ISO 8583 memiliki keunikan dalam manajemen koneksi, urutan byte, dan encoding field yang akan menghancurkanmu jika kamu perlakukan seperti REST.
Yang terjadi: Pengingat pembayaran berhenti terkirim. Tingkat pengiriman 0% selama 6 jam. Pengguna melewatkan tenggat pembayaran dan dikenakan denda keterlambatan.
Akar masalah: Token Firebase Cloud Messaging kedaluwarsa setiap 30 hari. Kami menyimpan token saat login pertama tetapi tidak pernah memperbaruinya. Perbaikannya sederhana — tetapi butuh 6 jam untuk diagnosis karena log error terkubur di dashboard Firebase, bukan di monitoring kami.
Pelajaran: Dependensi layanan eksternal perlu health check di monitoring KAMU, bukan di monitoring mereka. Jika kamu bergantung pada Firebase, monitor Firebase.
| Metrik | Sebelum | Sesudah |
|---|---|---|
| Unduhan aplikasi | 0 | 680 Ribu+ |
| Waktu pemrosesan transaksi | 3-5 hari kerja (manual) | Real-time |
| Tingkat keterlambatan pembayaran | 22% | 18% |
| Uptime sistem | N/A (sistem baru) | 99,7% |
Peran: Full-Stack Engineer Stack: Microservices Go, React PWA, MQTT, PostgreSQL Skala: 3 provinsi, 100+ truk, 50 ribu event telemetri/detik
Ini adalah perkenalan saya dengan IoT — dan semua yang saya kira saya tahu tentang "sistem yang andal" diuji oleh kenyataan: lokasi tambang terpencil dengan konektivitas satelit intermiten, pelacak GPS yang melaporkan data sampah, dan pengguna yang belum pernah memakai smartphone sebelumnya.
Kami membeli 50 pelacak GPS dari vendor terkemuka. 12 di antaranya melaporkan koordinat yang mustahil secara fisik — truk "teleportasi" 500 meter dalam 2 detik. Setelah 2 minggu debugging kode kami, kami menemukan: pelacak dikonfigurasi untuk melapor pada 1Hz (sekali per detik), tetapi ketika kehilangan kunci satelit, mereka menyangga pembacaan dan membuang semuanya sekaligus saat tersambung kembali. Sistem kami menginterpretasikan semburan data itu sebagai data real-time.
Perbaikan: Validasi kecepatan di sisi server. Jika perubahan koordinat menyiratkan >120 km/jam untuk truk tambang, tandai dan gunakan posisi terakhir yang diketahui baik. Menyelamatkan kami dari mengejar truk hantu selama sebulan.
Lokasi tambang di pedalaman Kalimantan memiliki konektivitas yang membuat 3G terlihat seperti fiber. Kami mendesain untuk "konektivitas eventual" — MQTT dengan QoS 1, buffer SQLite lokal di gateway tepi, unggahan batch ketika link satelit kembali. Arsitekturnya berhasil, tetapi kami meremehkan berapa lama "jendela offline" sebenarnya: kadang 6-8 jam.
Pelajaran: Desain untuk jendela offline terburuk, bukan rata-rata. Pengguna tidak akan peduli bahwa "rata-rata" konektivitas baik jika shift 8 jam mereka berakhir tanpa sinkronisasi data.
| Metrik | Sebelum | Sesudah |
|---|---|---|
| Utilisasi truk | 65% | 79% |
| Insiden pencurian BBM | Tidak diketahui (tak terdeteksi) | Terdeteksi bulan pertama |
| Penghematan tahunan | — | Rp 3,2 Miliar ($200K) |
| Waktu laporan HSE | 5 hari (kertas) | Real-time (digital) |
Peran: Full-Stack Engineer Tunggal Stack: Monolit Go, Flutter mobile, SQLite, MQTT Skala: 4,1 juta pengguna akhir, dibangun sendiri dalam 30 hari
Ini adalah proyek yang mengajarkan saya perbedaan antara "membangun" dan "memiliki." Ketika kamu satu-satunya pengembang, tidak ada tim backend untuk disalahkan saat database lambat. Tidak ada tim frontend untuk memperbaiki UI. Tidak ada tim DevOps untuk menangani deployment.
| Metrik | Sebelum | Sesudah |
|---|---|---|
| Tingkat kehilangan data | 23% | 0% |
| Pengguna akhir yang dilayani | 0 | 4,1 Juta |
| Waktu pembangunan | N/A | 30 hari (MVP) |
| Waktu keputusan pembiayaan | 3-5 hari kerja | Real-time |
| Item Portofolio | Apakah Saya Melakukannya? | Catatan |
|---|---|---|
| 2-3 studi kasus kerja | ✅ | SiTepat, HPU, Tepati — semuanya dengan dampak terukur |
| Metrik terukur | ✅ | 680 ribu unduhan, utilisasi 65→79%, kehilangan data 23% tereliminasi |
| Kontribusi open source | ❌ | Celah karir terbesar — mulai terlalu terlambat |
| Artikel teknis | ⚠️ | Menulis dokumentasi internal, tidak pernah dipublikasikan |
| Penanganan insiden produksi | ✅ | Bertahan dari 4 insiden besar, belajar lebih banyak dari itu daripada fitur mana pun |
Mid-level adalah tahap karir yang paling diremehkan. Di sinilah kamu mengumpulkan luka produksi yang membuat portofolio senior-mu autentik. Setiap insiden, setiap rollback, setiap perbaikan jam 2 pagi — itu bukan trauma. Itu konten.



