Ketika Aplikasi Buatan AI-mu Melampaui Iterasi Pertamanya: Refactor vs. Tulis Ulang

Kamu sudah merilis sesuatu. Pengguna menyukainya. Sekarang ada sepuluh pengguna, dan mereka menginginkan fitur yang tidak cocok dengan bentuk aslinya. Kamu berdiri di sebuah persimpangan: tambal aplikasi agar cocok dengan use case baru, atau akui bahwa versi pertama adalah prototype dan bangun ia dengan benar. Inilah pertanyaan yang membunuh lebih banyak proyek kecil daripada yang lain, karena tidak ada jawaban teknis untuknya — hanya jawaban bisnis.

Momen kamu menyadari aplikasinya sukses

Sebagian besar aplikasi buatan AI mulai sebagai satu hal dan menjadi hal lain. Kamu membangun formulir intake klien untuk praktik coaching-mu; sekarang klien ingin melihat janji temu sebelumnya dan menjadwalkan ulang sendiri. Kamu membangun sebuah tools lead scoring; sekarang tim sales-mu ingin ringkasan diekspor ke CRM mereka. Kamu membangun sebuah sistem pengarsipan; sekarang orang ingin berkolaborasi di dalamnya.

Setiap permintaan masuk akal. Masing-masing menarik aplikasi sedikit menjauh dari apa yang dirancang untuknya. Dan pada titik tertentu — enam bulan kemudian, atau dua bulan, kadang dua minggu — kamu merasakan friksinya. Setiap hal yang kamu tambahkan melawan fondasinya. Fitur baru menuntut “oh, kita perlu menyusun ulang bagian itu dulu.” Aplikasinya melambat. Mengubah hal-hal jadi makan waktu lebih lama.

Perasaan itu adalah sinyalmu untuk memikirkan apakah ini masih aplikasi yang sama, atau apakah kamu sudah melampauinya.

Apa yang dibeli dan dibiayai oleh refactoring

Refactoring berarti mempertahankan aplikasi yang sama, tapi merapikannya supaya kamu bisa membangun lebih banyak di atasnya. Kamu meminta AI builder-mu menyusun ulang kodenya, memecah workflow yang terlalu rumit, atau mendesain ulang sebuah layar yang sudah jadi tempat pembuangan fitur. Ia memakan beberapa jam. Ia tidak menambahkan fitur baru. Ia hanya membuat fondasinya lebih kuat.

Ketika refactoring berhasil, ia ajaib. Kamu merasa seperti sedang melawan aplikasi; tiba-tiba kamu tidak lagi. Kamu menambahkan tiga fitur baru dalam seminggu yang sebelumnya akan butuh tiga minggu.

Tapi refactoring hanya berhasil kalau masalahnya adalah bentuk dari apa yang kamu miliki. Kalau kamu membangun formulir intake dan pengguna ingin formulir intake yang lebih cepat, mem-refactor bagian yang lambat adalah pekerjaan satu sore. Kalau mereka ingin formulir intake yang lebih cepat dan menyimpan riwayat, ia tetap satu aplikasi, dan refactoring mungkin membantu. Tapi kalau mereka ingin riwayat janji temu, integrasi kalender, pengingat SMS, dan invoicing, kamu tidak lagi membangun formulir intake yang lebih baik — kamu membangun back office untuk sebuah praktik coaching. Itu produk yang berbeda.

Apa yang dibeli dan dibiayai oleh penulisan ulang

Menulis ulang berarti: kamu sudah belajar apa yang sebenarnya seharusnya menjadi aplikasi itu, dan kamu akan membangunnya dari nol dengan pengetahuan itu. Kamu tidak membuang versi pertama — penggunamu masih mengandalkannya. Tapi kamu membangun aplikasi baru dari dasar, diinformasikan oleh apa yang diajarkan aplikasi lama, lalu memigrasikan pengguna ketika ia siap.

Menulis ulang terasa boros. Kamu sudah membangun sesuatu, dan sekarang kamu membangunnya lagi. Itu biaya psikologisnya. Biaya praktisnya adalah waktu: kamu akan menghabiskan dua hingga empat bulan untuk versi baru sebelum ia siap memigrasikan pengguna. Kamu tidak akan punya versi pertama sebagai sandaran lagi — kamu mendorong maju tanpa jaring pengaman.

Tapi menulis ulang membelikanmu satu hal yang tak bisa dibeli hal lain: kebebasan. Aplikasi baru tidak dibatasi oleh bentuk aplikasi lama. Kalau yang asli adalah formulir sederhana dan yang baru seharusnya back office penuh, kamu merancang untuk itu sejak awal. Kalau performa penting, kamu merancang untuk itu. Kalau keamanan atau integrasi atau workflow penting, mereka bukan tambalan susulan — mereka bersifat fondasional.

Aplikasi yang sukses setelah dibangun ulang cenderung melakukannya karena pemahaman tim tentang masalahnya sudah bergeser begitu jauh dari kode aslinya sampai mencoba menambal terasa seperti memakai baju yang tidak pas. Menulis ulang berarti membangun untuk diri mereka sendiri sebagai gantinya.

Tiga pertanyaan untuk memilih di antara keduanya

Pertanyaan 1: Apakah bentuk intinya masih benar?

Bentuk inti adalah satu atau dua workflow utama yang mendefinisikan aplikasi. Untuk formulir intake coaching, ia adalah “klien mengisi intake, coach meninjau, coach menjadwalkan.” Kalau kamu menambahkan workflow yang berbeda — invoicing, manajemen kalender, pesan klien — kamu tidak memperluas inti, kamu menempelkan fitur sampingan. Itu tanda kamu sedang membangun produk yang berbeda, yang berarti tulis ulang.

Kalau kamu menambahkan variasi dari inti yang sama — “intake untuk individu, intake untuk tim, intake dengan kolom kustom” — itu masih aplikasi yang sama. Refactor dan perluas ia.

Pertanyaan 2: Kalau kamu refactor hari ini, berapa bulan lagi sampai friksi muncul kembali?

Jujurlah. Kalau friksi hilang selama enam bulan, refactoring adalah langkah yang tepat. Kalau ia akan menyakitkan lagi dalam dua bulan karena masalahnya bukan bentuk kode tapi fondasinya sendiri, maka menulis ulang menyelamatkanmu dari penghematan palsu berupa menambal dua kali. Tanyakan ke AI builder-mu: “Kalau kita merapikan ini, berapa lama sampai kita perlu melakukan ini lagi?” Kalau jawabannya “mungkin tidak lama”, saatnya membangun ulang.

Pertanyaan 3: Apa yang sebenarnya diandalkan penggunamu?

Kalau kamu punya tiga pengguna aktif di v1 dan kamu sedang memikirkan untuk membangun ulang, kamu bisa memindahkan mereka dalam satu atau dua hari. Kalau kamu punya lima puluh pengguna yang bergantung pada aplikasi saat ini untuk operasional, menulis ulang berarti kamu harus menjaga kedua versi tetap berfungsi selama berbulan-bulan, yang merupakan jenis kepedihan tersendiri.

Jalur yang biasanya berhasil

Sebagian besar founder yang berhasil membangun ulang melakukannya secara paralel: mereka menjaga aplikasi asli tetap berjalan dan memakai kapasitas cadangan untuk membangun yang baru. Ketika yang baru sudah punya kesetaraan fitur dengan yang lama, mereka menghabiskan seminggu memigrasikan data dan pengguna, lalu selesai.

Jalur yang biasanya tidak berhasil: refactor, refactor, refactor, sampai tiga refactor kemudian kamu menyadari arsitekturnya masih salah, dan sekarang kamu terlalu terlibat di versi “lama” untuk mengakuinya dan memulai dari awal.

Waktu yang tepat untuk memutuskan

Lain kali kamu merasakan friksinya, tanyakan pada dirimu: “Apakah aku membuat aplikasi ini melakukan apa yang seharusnya ia lakukan, dengan lebih baik? Atau aku memintanya menjadi sesuatu yang tidak pernah dirancang untuknya?” Kalau yang pertama, refactor. Kalau yang kedua, tidak ada yang memalukan dari membangun hal yang seharusnya ia jadi sejak awal. Sebagian besar aplikasi yang sukses berada di versi 2 dari intinya, bukan versi 1.