This Website: Building My Portfolio as a Working Product

I did not want a portfolio that felt like a cleaned-up CV or a template with my name dropped into it.

I wanted a working product that could show how I think, what I have built, and how I like to shape the awkward space between idea, logic, wording, and delivery.

That mattered for two reasons. First, the site needed to sound like me rather than like generic portfolio language. Second, I wanted a place where I could keep my product sense active by building, testing, fixing, and refining something real.

I built the site from scratch with AI as a fast building partner, while I stayed responsible for tone, scope, hierarchy, and what deserved to stay.

The practical loop was simple:

• write or rewrite a section
• see it in context quickly
• click through the page properly
• notice what felt off
• refine the wording, spacing, or logic

That made the work faster, but it did not make the judgement automatic. AI helped me get rough ideas into the browser early. The useful part was being able to react to something real instead of discussing an abstract outline for too long.

The site became a small system rather than a single page.

It includes:

• a homepage that explains my Builder Method and where I fit best
• an examples section for practical product work, redesigns, and AI-assisted building
• a writing section for shorter notes on product, AI, and delivery
• an about page that gives the longer version of how I work and why
• a content structure that makes it easy to keep adding examples and writing without rebuilding the whole site each time

The important part was not only that these pages existed. It was that they worked together. The examples needed to support the claims on the homepage. The writing needed to sound like the same person. The about page needed to deepen the story without turning into corporate profile copy.

Most of the useful work sat in the refinement rather than the first draft.

I kept adjusting the pace of the pages, the wording of headings, the order of examples, and how much detail each section should carry before it became too much. Some changes were visual. Some were structural. A surprising amount was just about making the tone feel more human and less rehearsed.

I also used the site as a place to keep smoothing rough edges: fixing bugs, tightening copy, improving navigation, checking mobile layouts, and removing little pieces of friction that would quietly make the experience worse.

This is one of the reasons I think building matters for product roles. Once you click through something properly, you notice the unclear transitions, the missing states, the parts that technically work but still feel wrong.

This site reminded me that AI is fast, but judgement is slower.

It is easy to generate sections, layouts, and variations quickly. The harder part is deciding what actually sounds true, what belongs on the page, what is trying too hard, and what still needs another pass. That is where the work still feels very recognisably like product work.

It also reinforced something I already believed: building real things helps me stay sharper as a Product Owner. It keeps my eye on detail, makes trade-offs visible, and gives me a more grounded sense of what is awkward, what is clear, and what still needs simplifying before other people have to carry it forward.

I do not see this kind of work as replacing engineering or design. I see it as a practical way to reduce translation tax, make ideas testable earlier, and arrive at better conversations with people who will take the work further.