A Portfolio Should Show How You Work
Why this site separates professional work, experiments, and the decisions worth documenting.
A project list only shows the output
A portfolio can make a project look complete in a few seconds: a name, a screenshot, a stack, and a short description. That is useful evidence. It shows that something was made.
But it is not the only evidence I want my site to leave behind. Over time, I wanted it to become less like a collection of finished pieces and more like a record of work: what I have delivered, what I choose to build, and the decisions that were worth keeping visible.
A project page can explain the problem, the role, and the shape of what was built. It can show enough scope for someone to understand that the work is real. What it often cannot show is the reasoning between the first requirement and the final interface: the constraint that changed the approach, the trade-off that made one solution better than another, or the thing that was deliberately not claimed.
I do not think every project needs a long explanation. Sometimes the work itself is the clearest proof. But a portfolio made entirely of outputs can make the process disappear. For my own site, that felt incomplete. Building software is not only a sequence of screens or repositories. It is also the decisions that shape them.
Work and experiments are different evidence
Work and Labs exist separately for that reason. Work is for software delivered in a professional context. It should be honest about the role, the system, and the limits of what can be shared. A professional delivery should not be framed as a personal experiment.
Labs are for things I choose to make, test, and evolve. A Lab can reveal product instinct, a technical direction, or an unfinished idea without pretending it is already a finished commercial case study. Keeping those categories apart makes both more legible.
About has a quieter job: provide enough context about the person behind the work without asking the rest of the site to become an autobiography.
Write when there is something worth documenting
Finished code and interfaces rarely expose every important choice. That is where Notes fit. They are not summaries of every project; they are short records of a decision, trade-off, mistake, constraint, or lesson that deserves to remain attached to the work.
The Notes on Image Toolkit and Qibla Finder are early examples. They exist because each product had a boundary worth explaining, not because the site needed more articles.
That is the rule I want to keep: build first. Write when there is something worth documenting. A Notes section should not become a publishing quota.
The site should not only say what I can build. Over time, it should leave enough evidence to show how I build.