Why My Portfolio Case Studies Use a Problem-Solution Format
When I designed the portfolio schema for this site (it lives in src/content.config.ts), I deliberately added two optional fields beyond the standard ones (title, description, technologies): problem and solution. They’re not required, but for the projects I consider most representative — the ones marked featured: true — I always make a point of filling them in.
The reasoning is simple but it stuck with me: a portfolio entry that just says “App X, built with React and Go” doesn’t tell you anything about how I actually think. I used to write portfolio entries exactly like that years ago, and when a client once asked “why this approach and not another one,” I realized the answer wasn’t written down anywhere in my own portfolio — it only lived in my head. That’s a problem, because the person looking at my portfolio usually isn’t getting the in-person explanation.
The format
problem gets filled with the context for why the project exists at all — what constraints the client or user faced before this app got built. solution gets filled with the actual technical or product decisions I made, not a list of features visible on screen.
The difference is obvious side by side. The old version (which I don’t write anymore): “Bina Insan Cendekia — a company profile website built with Laravel, with an online bookstore, a printing page, a tourism page.” That’s a feature list. The problem-solution version: the problem was one business with several very different service lines (publishing, printing, tourism, vehicle rental) needing a single unified platform so it didn’t look scattered to a prospective customer; the solution was a Laravel site with per-service navigation plus an integrated bookstore. Both mention Laravel, but only the second tells you why it’s structured that way.
Dodolanan.com — another agentic-AI experiment of mine — had a problem around giving kids safe, light entertainment without a clunky install step; the solution was a browser-based platform with 25+ mini games and built-in age filters. Both are written in the same order: problem first, then solution, then technology as supporting detail at the bottom — not the other way around, which is how most developer portfolios I’ve seen do it.
Why optional, not required
Not every portfolio entry deserves a full case study. Some projects — especially smaller ones or one-off experiments — are fine as a pure visual showcase, a screenshot and a tech list, without me forcing a problem-solution narrative that doesn’t actually have an interesting story. Forcing it on everything just buries the entries that do have a real story under a pile of empty templates.
An effect I didn’t expect: writing this field before writing the technical description forces me to actually re-think the decisions I made on a project. A few times I realized a decision that felt deliberate was actually just habit, once I tried to write down “why” and couldn’t find a solid reason.
A good portfolio isn’t a feature catalog. It’s evidence of how you think — and the easiest way to prove that is by actually writing the process down, not just the result.