Kenapa Case Study Portfolio Saya Pakai Format Problem-Solusi

Waktu desain schema portfolio buat situs ini (src/content.config.ts), saya sengaja nambahin dua field opsional: problem dan solution, di luar title, description, dan technologies yang standar.

Kenapa? Karena portfolio yang cuma nampilin “Aplikasi X, dibangun pakai React dan Go” nggak ngasih tahu apa-apa soal cara saya mikir. Rekruter atau klien yang liat portfolio biasanya bukan cuma pengin tahu teknologi apa yang saya pakai, tapi masalah apa yang saya selesaikan dan kenapa saya milih pendekatan tertentu.

Field problem saya isi dengan konteks kenapa proyek itu ada — batasan apa yang dihadapi klien atau user sebelum aplikasi ini dibuat. Field solution saya isi dengan keputusan teknis atau produk yang saya ambil, bukan cuma daftar fitur.

Contoh konkretnya ada di case study Bina Insan Cendekia dan Dodolanan di halaman portfolio. Bina Insan Cendekia problem-nya soal satu bisnis dengan beberapa lini layanan (penerbitan, percetakan, wisata, sewa kendaraan) yang butuh satu platform terpadu; solusinya website Laravel dengan toko buku online dan halaman per layanan. Dodolanan problem-nya soal hiburan ringan buat anak yang aman dan gampang diakses tanpa instalasi; solusinya platform 25+ mini game berbasis browser dengan filter usia. Dua-duanya ditulis dengan pola: masalah dulu, baru solusi, baru daftar teknologi sebagai detail pendukung — bukan sebaliknya.

Kedua field ini sengaja opsional di schema, karena nggak semua entri portfolio butuh case study penuh — beberapa proyek cukup ditampilin sebagai showcase visual doang. Tapi buat proyek yang saya anggap paling representatif (ditandai featured: true), saya usahakan selalu isi problem/solution-nya.

Portfolio yang baik itu bukan katalog fitur, tapi bukti cara berpikir.