Dalam dunia software development, kita sering terjebak dalam dilema klasik: “Kode lama ini sampah, kita harus rewrite semuanya,” atau “Biarkan saja, yang penting jalan.”
Saya baru saja menghadapi situasi ini secara langsung. Kami memiliki basis kode (codebase) berusia 7 tahun. Arsitekturnya adalah Single Page Application (SPA) berbasis React (CRA lawas). Secara fungsional, aplikasi ini stabil tapi nyatanya tidak meng-generate revenue dengan efektif.
Namun, ketika bisnis memutuskan untuk melakukan rebranding dan menjadikan aplikasi ini sebagai ujung tombak Marketing Funnel, masalah fatal muncul.
Seringkali muncul bias yang wajar terjadi di era dominasi SPA, yaitu Ilusi Kecepatan Pasca-Load. Argumen “Setelah load awal selesai, transisinya akan sangat cepat” mungkin valid untuk aplikasi internal, namun ia menjadi jebakan fatal dalam konteks Growth.
Dalam dunia User Acquisition, First Contentful Paint (FCP) dan Largest Contentful Paint (LCP) adalah raja. Pada SPA lawas (CRA), browser harus mengunduh berkas JavaScript raksasa (seringkali 2MB+) sebelum bisa menampilkan satu piksel pun konten yang berarti.
Bagi pengguna dengan koneksi seluler standar (4G/3G), ini berarti layar putih kosong selama 3-10 detik. Dalam funnel, pengguna tidak peduli seberapa cepat transisi halaman kedua, jika mereka sudah bounce (keluar) di halaman pertama.
Ini kesalahan dalam mem-framing solusi teknologi ke kebutuhan bisnis.
Sebagai Technical Product Manager, tugas saya adalah mengatakan kebenaran yang tidak nyaman: Dalam konteks funnel, “cepat setelah loading” adalah definisi lain dari kehilangan pelanggan.
Teknologi ada untuk melayani bisnis, bukan sebaliknya. Saat corong penjualan (funnel) Anda macet karena arsitektur usang, saatnya berhenti bernostalgia dengan kode lama dan mulai membangun untuk growth.
Inilah bagaimana saya menolak melakukan rewrite total yang berisiko, namun berhasil mengubah arsitektur tua ini menjadi mesin pertumbuhan yang meningkatkan impresi SEO sebesar 511%, memangkas cost pengembangan, dan mempercepat siklus pengiriman fitur hingga 12x lipat.
Diagnosis: The “Context Mismatch”
Masalah utamanya bukan pada React atau kodenya, tapi pada konteks penggunaan. Kegagalan memahami ini adalah akar dari kegagalan produk.
-
Ops Tool (Konteks Lama): Penggunanya adalah karyawan. Mereka adalah Captive Audience. Mereka rela menunggu loading awal 5 detik karena mereka akan bekerja di dalam aplikasi selama 4 jam. Caching bekerja sempurna di sini.
-
Growth Funnel (Konteks Baru): Penggunanya adalah prospek dari iklan. Mereka adalah Fickle Audience. Jika website tidak muncul dalam 2 detik, mereka bounce. Mereka tidak peduli seberapa canggih fitur di dalamnya jika pintunya terkunci.
Memaksa SPA lawas (Client-Side Rendering) untuk kebutuhan SEO dan Ads adalah bunuh diri bisnis.
Mungkin ada jalan pintas: “Rewrite semuanya!” atau “Pasrah saja.” Saya memilih jalan ketiga: Framing, Pre-packaging, dan Eksekusi Brutal. alias pragmatis aja wahahaha.
Sebelum menyentuh building, saya mengajak tim mundur sejenak dan banyak mengobrol ke lintas divisi alias interview masalah product. Menggunakan filosofi Framing dari Ryan Singer, kami membedah masalah ini dengan metafora “Menyeberang Sungai”.
Aturannya tegas: Dilarang membahas fitur atau teknologi (“Jembatan”) sebelum kedua sisi sungai terdefinisi.
Sisi Kiri Sungai (Current Context - Realita Pahit):
-
User Struggle: Cold traffic melihat layar putih 5-8 detik.
-
Business Pain: Biaya iklan mahal (High CPC) karena performa buruk. SEO organik nol.
-
Dev Pain: Siklus rilis fitur butuh 3 bulan karena kompleksitas kode lama.
Sisi Kanan Sungai (Desired Outcome - Keadaan Ideal):
-
User Goal: Halaman instan (<1 detik).
-
Business Goal: Googlebot bisa membaca konten (SEO). Tim marketing bisa tes 10 landing page dalam seminggu.
-
Success Metric: Delivery cycle 1 minggu, Performance Score 90+.
Hanya setelah “Sisi Kiri” dan “Sisi Kanan” disepakati memiliki Appetite (nilai bisnis), barulah kita bicara soal “Jembatan”.
Fase 2: Shaping (The Hybrid Bridge)
Karena outcome-nya jelas, solusinya bukan rewrite total, melainkan Hybrid Strangler Pattern.
1. Decoupling dengan Astro (The Speed Layer) Saya memisahkan funnel depan menggunakan Astro (bukan Next.js, untuk menghindari overhead React runtime berlebih).
-
Tujuan: Mencapai “Sisi Kanan” (Speed & SEO) tanpa beban aplikasi lama.
-
Hasil: HTML statis murni, zero JS di awal load.
2. The Invisible Bridge (Session Storage Injection) Tantangannya: Bagaimana menghubungkan Astro ke Legacy App (Ops/Transaksi) tanpa user sadar?
- Mekanisme: Saat user klik “Beli” di Astro, data produk disuntikkan ke Session Storage. Saat redirect terjadi, Legacy App membaca data tersebut, mem-bypass halaman depan, dan langsung masuk ke checkout.
- Catatan Teknis: Meskipun pendekatan ini terkesan tidak ortodoks, ia sangat aman karena kami tidak menyimpan data sensitif (PII), melainkan hanya metadata produk untuk menjaga kontinuitas experience tanpa perlu melakukan rewrite pada sistem autentikasi yang sudah ada.
3. Legacy Hygiene Di aplikasi lama, saya melakukan perbaikan spesifik:
-
Security: Mematikan JS Source Maps (default CRA) untuk keamanan dan ukuran file.
-
SEO Prep: Memperbaiki dynamic HTML variable agar link prefetching bekerja maksimal saat transisi.
Fase 3: The Impact (Validation)
Strategi ini bukan sekadar teori. Data membuktikan bahwa pragmatisme menang:
-
Growth (SEO): Impresi Google Search Console naik +511%.
-
Speed (Execution): Siklus delivery turun dari 3 bulan menjadi 1 minggu (12x Faster). Kami menerapkan prinsip Minimum Lovable Product (MLP).
-
Cost Efficiency (The Pragmatic Save): Dengan menolak rewrite total (estimasi 6 bulan x 1 tim) dan memilih solusi hybrid, saya memangkas biaya pengembangan hingga ~80%. Kami memperbaiki masalah spesifik tanpa membakar rumahnya. Selain itu, perbaikan LCP menghentikan kebocoran budget iklan akibat bounce rate tinggi.
-
Ops Efficiency: Adopsi operasional naik +300% karena integrasi data yang mulus (via Session Storage ke Zoho + GA).
-
UX: Skor Lighthouse tembus 90+ di Mobile.
Kesimpulan
Pelajaran terbesar dari studi kasus ini: Validasi masalah (Framing) harus dilakukan sebelum merancang solusi (Shaping).
Sebagai Technical Product Manager, tugas kita bukan sekadar menjaga backlog atau menuruti ego engineering untuk rewrite. Tugas kita adalah mendefinisikan “sungai”-nya. Dengan memisahkan Demand Side dan Supply Side, saya berhasil menyelamatkan investasi kode 7 tahun sekaligus membuka pintu gerbang pendapatan masa depan.
Stop building bridges to nowhere. Frame the river first.
Penutup
Sistem ini ibarat saya baru saja selesai merakit sebuah mobil balap F1 dari rongsokan besi tua. Mesinnya sudah diganti, sasisnya sudah diperkuat (Security Fix), dan bahan bakarnya sudah terisi penuh.
Dan inilah bagian terbaiknya.
Sekarang, mobil ini butuh pembalap yang handal. Saya sangat antusias menyambut Lead Marketing baru kita. Infrastruktur ini dibangun untuk Anda. Tidak ada lagi hambatan teknis, tidak ada lagi “tunggu dev 3 bulan”, dan tidak ada lagi “website lemot”.
Mari kita bertumbuh bareng-bareng.