Kenapa Case Study Portfolio Saya Pakai Format Problem-Solusi

Waktu saya desain schema portfolio buat situs ini (ada di src/content.config.ts), saya sengaja nambahin dua field opsional di luar yang standar (title, description, technologies): problem dan solution. Field ini nggak wajib diisi, tapi buat proyek yang saya anggap paling representatif — yang ditandai featured: true — saya selalu usahain isi.

Alasannya sepele tapi nyangkut lama di kepala saya: portfolio yang cuma bilang “Aplikasi X, dibangun pakai React dan Go” nggak ngasih tahu apa-apa soal cara saya mikir. Saya pernah nulis portfolio kayak gitu bertahun-tahun lalu, dan waktu ada klien nanya “kenapa milih pendekatan ini, bukan yang lain,” saya sadar jawabannya nggak ada di mana pun di portfolio saya sendiri — cuma di kepala saya. Itu masalah, karena orang yang liat portfolio saya duluan itu biasanya bukan saya yang jelasin langsung.

Format-nya

problem saya isi dengan konteks kenapa proyek itu ada sama sekali — batasan apa yang dihadapi klien atau user sebelum aplikasi ini dibuat. solution saya isi dengan keputusan teknis atau produk yang beneran saya ambil, bukan daftar fitur yang keliatan di layar.

Bedanya kentara kalau dibandingin langsung. Versi lama (yang nggak saya pakai lagi): “Bina Insan Cendekia — website company profile dengan Laravel, ada toko buku online, halaman percetakan, halaman wisata.” Itu daftar fitur. Versi problem-solusi: masalahnya satu bisnis dengan beberapa lini layanan yang beda-beda jauh (penerbitan, percetakan, wisata, sewa kendaraan) butuh satu platform terpadu biar nggak keliatan berantakan di mata calon customer; solusinya website Laravel dengan struktur navigasi per layanan plus toko buku terintegrasi. Sama-sama nyebut Laravel, tapi yang kedua ngasih tahu kenapa strukturnya kayak gitu.

Dodolanan.com — eksperimen agentic AI saya yang lain — problem-nya soal hiburan ringan buat anak yang aman dan gampang diakses tanpa proses instalasi ribet; solusinya platform 25+ mini game berbasis browser dengan filter usia bawaan. Dua-duanya saya tulis dengan urutan yang sama: masalah dulu, baru solusi, baru teknologi sebagai detail pendukung di paling bawah — bukan sebaliknya kayak kebanyakan portfolio developer yang saya lihat.

Kenapa opsional, bukan wajib

Nggak semua entri portfolio pantas dapet case study penuh. Beberapa proyek — terutama yang lebih kecil atau eksperimen sekali jalan — cukup ditampilin sebagai showcase visual doang, screenshot dan daftar teknologi, tanpa saya maksain narasi problem-solusi yang sebenarnya nggak ada cerita menariknya. Maksain itu ke semua entri malah bikin yang beneran punya cerita jadi tenggelam di tengah yang cuma template kosong.

Efek sampingnya yang nggak saya duga: nulis field ini duluan sebelum nulis deskripsi teknis bikin saya sendiri lebih jelas mikir ulang keputusan yang saya ambil pas ngerjain proyeknya. Beberapa kali saya baru sadar ada keputusan yang sebenarnya nggak sengaja — cuma kebiasaan — pas saya coba jelasin “kenapa” secara tertulis dan nggak nemu alasan yang kuat.

Portfolio yang bagus itu bukan katalog fitur. Itu bukti cara berpikir — dan cara paling gampang buat mbuktiin itu ya emang dengan nulis prosesnya, bukan cuma hasilnya.