Dari Freelance ke Fullstack Developer: 3 Tahun yang Mengubah Cara Saya Memandang Kode

Jam 2 pagi. Layar laptop masih nyala. Saya menatap kode yang sudah saya tulis selama 3 minggu.

Client bilang: "Mas, ini bukan yang saya butuhkan."

Tiga minggu kerja. 18 jam sehari. Dan satu kalimat itu menghapus semuanya.

Saya tidak marah ke client. Yang lebih menyakitkan — saya sadar dia benar.

Itu momen paling menyebalkan sekaligus paling penting dalam karier saya. Dan cerita ini bukan tentang bagaimana saya jadi developer hebat. Ini tentang bagaimana saya belajar bahwa menulis kode yang benar itu bukan soal kode — tapi soal memahami masalah yang sebenarnya.

Bab 1: Awal yang Naif

Saya mulai seperti banyak developer lain: bisa nulis kode, merasa pintar.

Tahu apa yang saya pikirkan waktu itu? "Kalau aku bisa bikin fitur ini, client pasti senang."

Spoiler: client tidak senang.

Proyek Pertama yang (Hampir) Berantakan

Client pertama saya adalah pemilik UMKM. Dia butuh sistem inventory sederhana. "Yang bisa tracking barang masuk dan keluar," katanya.

Saya langsung coding. Tanpa banyak nanya. Tanpa paham workflow-nya. Hasilnya?

Sistem yang secara teknis sempurna — tapi tidak bisa dipakai.

Kenapa?

Karena saya tidak tahu bahwa dia dan timnya mencatat inventory di buku tulis. Mereka butuh sesuatu yang semudah buka aplikasi, tap 2 kali, selesai. Yang saya kasih malah dashboard dengan 15 menu dan form yang harus diisi 8 field.

Client saya hampir batal bayar. Bukan karena sistemnya jelek — karena sistemnya tidak menyelesaikan masalahnya.

Dia bilang sesuatu yang masih nempel sampai sekarang:

"Mas, saya tidak butuh sistem yang canggih. Saya butuh sistem yang tim saya bisa pakai tanpa perlu training."

Kalimat itu bikin saya introspeksi 3 hari.

Pelajaran Pertama: User Tidak Peduli Seberapa Keren Kode Anda

Mereka peduli apakah hidup mereka jadi lebih mudah atau lebih ribet.

Setelah itu, saya mulai melakukan sesuatu yang sebelumnya saya anggap "tidak penting": duduk bareng user, lihat cara mereka kerja, baru coding.

Hasilnya?

Sistem yang sama — tapi saya rebuild dari nol dengan 3 tombol utama. User happy. Client bayar lunas. Dan saya dapat pelajaran yang tidak bisa diajarkan di bootcamp manapun.

Bab 2: Proyek yang Mengubah Segalanya

Fast forward 6 bulan. Saya dapat proyek yang jauh lebih besar.

Sebuah perusahaan butuh Document Management System (DMS). 4 departemen. Ribuan file. Ini proyek yang kalau berhasil, bisa jadi portfolio utama. Kalau gagal? Malu besar.

Minggu 1-2: Saya Mulai dengan Salah

Tahap awal, saya langsung teknis: database schema, API endpoints, UI components. Semua sudah saya rencanakan di kepala.

Lalu saya present ke stakeholder.

Mereka diam 10 detik. Terus salah satu bilang: "Mas, Anda sudah tanya ke tim gudang belum?"

Saya tidak.

Minggu 3: Saya Turun ke Gudang

Besoknya saya datang ke kantor mereka. Bukan ke ruang meeting — ke gudang.

Duduk sama tim yang setiap hari ngurus file. Tanya: "Sebenarnya masalah terberat kalian apa?"

Jawabannya bukan yang saya ekspektasikan.

Mereka bilang: "Kami tidak susah nyari file. Kami susah waktu harus minta approval dari 3 orang sebelum upload. Kadang orangnya lagi cuti, file numpuk, terus lupa."

Bukan masalah pencarian. Masalahnya adalah approval workflow.

Kalau saya tidak turun ke gudang, saya akan bangun sistem pencarian canggih yang tidak mereka butuhkan. Dan masalah utama mereka tetap tidak tersentuh.

Minggu 4-8: Rebuild Ulang dengan Prioritas yang Benar

Saya ubah total roadmap:

Fitur utama → approval workflow dengan notifikasi otomatis
Fitur kedua → upload massal dengan template
Fitur ketiga → baru pencarian (tapi tidak secanggih rencana awal)

Hasilnya?

DMS yang diluncurkan dan dipakai semua departemen dalam 2 bulan. Time retrieval turun 80%. Tapi yang lebih penting: tim gudang tidak lagi lembur karena approval bottleneck.

Client puas sampai sekarang. Dan mereka merekomendasikan saya ke 3 klien lain setelahnya.

Pelajaran Kedua: Jawaban Tidak Pernah Ada di Kode. Jawabannya Ada di Lapangan.

Sejak hari itu, saya punya ritual: sebelum coding apapun, saya habiskan minimal 1 hari untuk paham masalah. Bukan masalah versi manager — masalah versi user yang setiap hari hidup di dalamnya.

Bab 3: Titik Balik — Ketika Saya Mulai Paham "Kenapa"

Setelah DMS itu, proyek mulai datang. Bukan banyak — tapi cukup.

Dan sesuatu berubah di cara saya berpikir.

Sebelumnya, mindset saya: "Client mau fitur A, saya bikin fitur A."

Setelah DMS, mindset saya berubah: "Client minta fitur A. Tapi kenapa? Apa masalah yang sebenarnya? Apakah fitur A benar-benar solusinya?"

Pertanyaan "kenapa" ini kecil tapi powerful.

Kasus yang Membuktikan Itu

Seorang founder startup menghubungi saya. Dia mau build platform e-learning dengan fitur video streaming, quiz, leaderboard, sertifikat — lengkap.

Budget-nya? Terbatas.

Kalau saya ikuti permintaannya, budget habis di fitur video streaming doang. Sisanya tidak cukup.

Saya tanya: "Sebenarnya apa yang mau kamu capai?"

Dia jawab: "Aku mau orang belajar skill baru dan bisa buktiin kalau mereka sudah kompeten."

Oke. Jadi yang dia butuhkan bukan video streaming canggih. Yang dia butuhkan adalah sistem assessment dan sertifikasi yang credible.

Akhirnya kami sepakati:

Video → embed dari YouTube/Vimeo (murah, sudah cukup)
Fokus budget → sistem quiz yang robust, auto-grading, dan sertifikat terverifikasi
Leaderboard → ditunda ke phase 2

Hasilnya? Platform yang diluncurkan on-budget. User engagement tinggi karena quiz-nya challenging dan sertifikatnya diakui industri.

Client bilang: "Kamu satu-satunya developer yang nanya kenapa sebelum langsung bilang bisa."

Pelajaran Ketiga: Developer yang Baik Menjawab Pertanyaan. Developer yang Lebih Baik Mempertanyakan Pertanyaan.

Kedengarannya sok filosofis. Tapi di lapangan, ini yang membedakan proyek yang berhasil dan proyek yang menghabiskan budget tanpa hasil.

Bab 4: Ketika Saya Mulai Fokus pada Dampak, Bukan Output

Ada satu proyek yang tidak saya ambil. Dan itu keputusan terbaik.

Seorang calon klien datang. Mau build aplikasi mobile. Budget besar. Kelihatan proyek yang bagus.

Tapi setelah diskusi, saya sadar: dia sebenarnya butuh konsultasi bisnis dulu. Belum jelas product-market fit. Belum validasi apakah orang memang mau pakai aplikasinya.

Kalau saya terima, saya dapat duit. Tapi 6 bulan kemudian, kemungkinan besar aplikasinya tidak dipakai dan dia nyalahin saya.

Saya bilang: "Maaf, saya rasa Anda belum butuh developer. Anda butuh validasi ide dulu. Ini beberapa resource yang bisa membantu."

Dia terdiam. Terus bilang makasih.

3 bulan kemudian, dia hubungi lagi. Sudah validasi. Sudah ada 50 user yang interested. Dan kali ini, proyek yang kami bangun bersama memang berhasil.

Kenapa Saya Menolak Proyek Itu?

Karena saya sudah terlalu sering melihat pattern ini: startup build aplikasi → tidak ada yang pakai → developer disalahin → everyone lose.

Saya tidak mau jadi developer yang kasih ikan. Saya mau jadi developer yang bantu pahami kenapa ikan itu dibutuhkan.

Pelajaran Keempat: Menolak Proyek yang Salah Itu Lebih Berharga daripada Menerima Proyek yang Salah.

Income saya waktu itu berkurang. Tapi reputasi saya sebagai partner yang jujur — itu yang mendatangkan klien-klien berkualitas setelahnya.

Bab 5: Evolusi yang Masih Berjalan

Sekarang, 3+ tahun kemudian, saya sudah handle 20+ proyek. Berbagai tipe:

UMKM yang butuh web pertama mereka
Startup yang butuh MVP dalam 4 minggu
Perusahaan enterprise yang butuh sistem yang bisa scale ke ribuan user
Founder yang butuh integrasi AI untuk otomatisasi

Dan setiap proyek mengajarkan sesuatu yang berbeda.

Dari UMKM: Kesederhanaan Itu Sulit

UMKM mengajarin saya bahwa membuat sesuatu yang simpel itu jauh lebih sulit daripada membuat sesuatu yang kompleks.

Ketika user Anda tidak tech-savvy, setiap tombol ekstra, setiap field yang tidak perlu, setiap notifikasi yang membingungkan — itu semua adalah friksi yang bisa bikin mereka stop pakai sistem Anda.

Kesederhanaan bukan tentang apa yang Anda tambahkan. Kesederhanaan adalah tentang apa yang berani Anda hilangkan.

Dari Startup: Kecepatan Itu Segalanya

Startup mengajarin saya bahwa MVP yang sempurna itu kontradiksi.

MVP itu harus cukup bagus untuk menarik early user, tapi cukup simpel untuk bisa dibangun cepat. Kalau Anda spend 3 bulan build MVP, Anda sudah telat.

Saya belajar untuk bilang: "Ini bisa kita tunda ke phase 2." Lebih sering daripada yang saya duga. Dan hampir tidak pernah ada client yang marah karena fitur ditunda — selama alasannya jelas.

Dari Enterprise: Skalabilitas Bukan Cuma Soal Teknis

Perusahaan besar mengajarin saya bahwa skalabilitas bukan cuma soal server yang kuat dan kode yang efisien.

Skalabilitas juga soal: apakah sistem ini bisa dipahami oleh tim baru? Apakah dokumentasinya cukup jelas? Apakah ada proses onboarding yang smooth?

Kode yang hanya dimengerti satu orang adalah kode yang tidak scalable. Titik.

Dari Proyek AI: Teknologi Baru Butuh Kematangan Lama

Integrasi AI mengajarin saya bahwa ekspektasi management itu lebih penting daripada model selection.

Client sering datang dengan: "Saya mau AI yang bisa jawab semua pertanyaan customer 100% akurat."

Dan saya harus jujur: "Itu belum ada. Tapi kita bisa capai 80% dengan AI, dan 20% sisanya kita route ke manusia yang terlatih."

Mengelola ekspektasi bukan tentang mengurangi excitement. Itu tentang memastikan client tidak kecewa di tengah jalan karena ekspektasi yang tidak realistis.

Momen yang Tidak Pernah Saya Lupakan

Di antara semua proyek, ada satu momen kecil yang terus saya ingat.

Setelah launching DMS untuk perusahaan yang saya ceritakan tadi, saya dapat pesan WhatsApp dari salah satu staff gudang. Isinya:

"Pak, terima kasih sistemnya. Pertama kali saya bisa pulang tepat waktu dalam 2 tahun."

Saya nangis baca itu. Bukan karena saya sentimentil — tapi karena itu konfirmasi yang paling nyata: apa yang saya kerjakan berdampak ke kehidupan seseorang.

Bukan ke metrics perusahaan. Ke kehidupan manusia.

Dan itu yang saya cari sekarang. Bukan proyek yang terlihat keren di portfolio. Tapi proyek yang membuat seseorang bilang: "Ini bikin hidup saya lebih baik."

Apa yang Berubah dari Diri Saya

Kalau saya harus rangkum transformasi 3 tahun ini dalam beberapa poin:

Dulu:

❌ Fokus pada "bagaimana cara build ini"
❌ Merasa smart code = good code
❌ Mengikuti semua permintaan client
❌ Mengukur sukses dari jumlah fitur
❌ Takut menolak proyek

Sekarang:

✅ Fokus pada "apa masalah yang sebenarnya"
✅ Merasa simple code = good code
✅ Mempertanyakan permintaan yang tidak tepat
✅ Mengukur sukses dari dampak yang tercipta
✅ Nyaman menolak proyek yang belum siap

Perbedaannya bukan di skill teknis. Perbedaannya di cara berpikir.

Kenapa Saya Menulis Ini

Bukan untuk pamer. Jujur — ada banyak kegagalan yang tidak saya ceritakan di sini. Proyek yang meleset timeline. Fitur yang harus diulang 4 kali. Client yang tidak puas di awal dan harus saya handle dengan komunikasi, bukan dengan kode.

Saya menulis ini karena saya percaya transparansi itu penting.

Kalau Anda cari developer yang bilang "semua bisa saya kerjakan dengan cepat" — itu bukan saya.

Kalau Anda cari partner yang akan bilang "tunggu dulu, kita perlu paham ini lebih dalam sebelum coding" — mungkin kita cocok.

Jika Anda Mencari Developer yang Berpikir Dulu, Coding Kemudian

Itu saya sekarang.

Bukan developer yang langsung buka VS Code. Tapi developer yang buka percakapan dengan pertanyaan:

"Apa yang ingin Anda capai?"
"Siapa yang akan pakai ini?"
"Apa yang terjadi kalau kita tidak build ini?"
"Bagaimana kita tahu ini berhasil?"

Pertanyaan-pertanyaan ini mungkin terdengar seperti consultant, bukan developer.

Tapi di pengalaman saya, developer yang baik itu memang harus sedikit jadi consultant. Karena teknologi yang benar dimulai dari pemahaman masalah yang benar.

Ayo Mengobrol

Jika Anda punya proyek dalam pikiran — atau bahkan baru berupa ide yang belum jelas — saya senang diajak bicara.

Tidak ada sales pitch. Tidak ada janji manis. Hanya percakapan jujur tentang apa yang Anda butuhkan, apa yang masuk akal, dan apa yang sebaiknya ditunda.

Karena pada akhirnya, saya tidak di sini untuk menulis kode. Saya di sini untuk membantu Anda membangun sesuatu yang benar-benar bekerja.

Ayo ngobrol — karena solusi terbaik dimulai dari percakapan yang jujur.