Why My Portfolio Case Studies Use a Problem-Solution Format

When I designed the portfolio schema for this site (src/content.config.ts), I deliberately added two optional fields: problem and solution, alongside the standard title, description, and technologies.

Why? Because a portfolio entry that just says “App X, built with React and Go” doesn’t tell you anything about how I actually think. Recruiters or clients looking at a portfolio usually don’t just want to know which technologies I used — they want to know what problem I solved and why I chose a particular approach.

The problem field is filled with context on why the project exists — what constraints the client or user faced before this app was built. The solution field is filled with the technical or product decisions I made, not just a feature list.

You can see this concretely in the Bina Insan Cendekia and Dodolanan case studies on the portfolio page. Bina Insan Cendekia’s problem was one business with several distinct service lines (publishing, printing, tourism, vehicle rental) needing a single unified platform; the solution was a Laravel site with an online bookstore and dedicated pages per service. Dodolanan’s problem was giving kids safe, easy-to-reach light entertainment without an install step; the solution was a browser-based platform with 25+ mini games and age filters. Both are written in the same pattern: problem first, then solution, with technologies listed as supporting detail rather than the headline.

Both fields are deliberately optional in the schema, because not every portfolio entry needs a full case study — some projects are fine as pure visual showcases. But for the projects I consider most representative (marked featured: true), I make a point of always filling in problem/solution.

A good portfolio isn’t a feature catalog — it’s evidence of how you think.