Building my portfolio like a product

Most portfolios document finished work.

I wanted mine to demonstrate how I work.

That meant the portfolio could not simply be a polished archive of case studies. It needed to show product judgment, structured thinking, attention to detail, experimentation, and the ability to turn an idea into a functioning experience.

I approached the website as a product: defining its audience, clarifying the value proposition, creating a scalable content system, testing interactions across devices, and progressively shipping improvements into production.

AI accelerated the implementation. It did not make the product decisions for me.

A product portfolio has to serve several audiences at once.

A recruiter may spend less than a minute determining whether the experience is relevant. A hiring manager may want to understand the decisions behind a particular outcome. A product leader may look for evidence of strategic range, technical fluency, and craft.

Trying to satisfy everyone can produce a predictable result: long case studies, repetitive layouts, generic project cards, and too much information competing for attention.

I needed the experience to support both rapid scanning and deeper exploration without turning the homepage into a résumé or reducing complex work to a collection of screenshots.

There was also a second challenge: I had strong product and analytical experience, but I was not approaching the project as a traditional front-end engineer.

The build process needed to let me maintain control over the product while using AI to translate clear direction into working software.

Screens can show what was built. They rarely explain why it was built that way.

Each case study therefore emphasizes the challenge, product choices, trade-offs, operating constraints, and measurable outcomes—not only the final interface.

The first layer of every page should communicate relevance quickly. Supporting detail should be available without being forced on every visitor.

This principle shaped the information hierarchy, project summaries, metric-led sections, navigation, and progressive disclosure throughout the site.

Every new project should not require inventing a new layout.

Work case studies, Playground experiments, project metadata, navigation patterns, cards, metrics, and responsive behaviours were designed as reusable components with enough flexibility to give each story its own identity.

Cursor could generate components, refactor layouts, troubleshoot implementation problems, and accelerate repetitive work.

But it still needed explicit direction.

I remained responsible for the audience, hierarchy, interaction model, visual standards, content, acceptance criteria, and the decision about whether an output was actually good enough to ship.

Before focusing on visual design, I defined the underlying product narrative.

The site needed to position me as a product leader with experience across digital platforms, fintech, loyalty, commerce, travel, and emerging AI-enabled workflows.

It also needed to balance two sides of my work:

• Work for structured case studies and business outcomes
• Playground for prototypes, experiments, and ideas I chose to build independently

Separating those experiences allowed the professional work to remain credible and outcome-oriented while giving the more exploratory projects room to feel playful.

I developed shared patterns for project heroes, metadata, navigation, metric modules, project snapshots, content sections, related projects, and calls to action.

Work and Playground pages use the same visual family, but they do not behave identically.

Work prioritizes organizational context, decisions, and outcomes. Playground prioritizes the experiment, build process, interaction, and learning.

The distinction made the system more coherent without making every page feel templated.

The visual system emerged through repeated cycles of direction, implementation, review, and refinement.

I tested typography, spacing, colour, card density, scroll behaviour, motion, light and dark modes, and responsive layouts. Elements that appeared successful in isolation sometimes broke down when placed into the complete experience.

The process was closer to product iteration than a linear design handoff:

Frame the problem → generate an implementation → test it in context → identify the failure → refine the system

A major part of the work involved learning how to give an AI coding agent enough context to produce reliable results.

Broad prompts generated broad interpretations. Precise prompts produced better software.

My strongest implementation instructions typically included:

• The user experience objective
• The existing component or pattern to preserve
• Desktop, tablet, and mobile behaviour
• Content and data requirements
• Animation start and end states
• Reusability expectations
• Edge cases and scalability rules
• Explicit acceptance criteria
• Elements that must not change

The prompt became a lightweight combination of a product requirement, design specification, and engineering handoff.

The site was deployed through GitHub and Vercel early rather than being held until it felt complete.

That changed the nature of the project.

Testing in production exposed issues that were difficult to anticipate in a static design: viewport-dependent animations, browser behaviour, responsive card layouts, deployment configuration, custom-domain setup, favicon treatment, and interactions that felt different with real scrolling.

Each release created a more accurate feedback loop for the next decision.

The Work section supports stories from Arc'teryx, RBC, Hudson's Bay, and Air Canada while preserving a consistent narrative structure.

Reusable modules allow each case study to feature its most relevant evidence, including product metrics, customer outcomes, platform complexity, strategic decisions, and cross-functional scope.

The Playground is designed for projects that are smaller, more experimental, or personally initiated.

Rather than presenting them as miniature corporate case studies, each post focuses on what I was curious about, the problem or hypothesis, how I approached the build, what I created, what I learned, and what I would explore next.

This creates room for projects such as an AI market-monitoring agent, a restaurant reservation MVP, interactive portfolio experiments, and future prototypes.

Mobile was treated as its own interaction context.

Navigation, content ordering, project snapshots, carousels, cards, and calls to action were reconsidered for smaller screens rather than simply compressed.

The goal was to preserve the hierarchy and personality of the portfolio while reducing unnecessary friction.

Animations were used to create continuity, reinforce hierarchy, and make exploration feel more tactile.

The most difficult interactions were not necessarily the most visually complex. Scroll-linked behaviours, stacking cards, and viewport-dependent end states required careful testing because an animation that worked at one screen size could fail at another.

Those failures reinforced an important product lesson: a polished happy path is not the same as a resilient interaction.

The portfolio moved from a local build to a live Vercel deployment connected to a private GitHub repository and custom domain.

The final experience also required the less visible parts of shipping a web product: DNS configuration, environment management, browser assets, metadata, performance considerations, and production debugging.

AI reduced the distance between deciding what I wanted and seeing a functioning version of it.

I used it to:

• Generate and refactor front-end components
• Translate visual references into implementation requirements
• Diagnose responsive and animation defects
• Explore alternative layouts
• Create reusable component structures
• Develop supporting visual assets
• Improve content hierarchy and copy
• Pressure-test edge cases before implementation

But faster generation also created a new failure mode: it became easy to produce more versions without necessarily producing a better product.

The highest-leverage work was often not writing another prompt. It was recognizing why an output felt wrong, identifying the underlying system problem, and describing the correction precisely.

AI made iteration cheaper. Product judgment determined which iterations were valuable.

The homepage introduces the breadth of my experience and directs visitors toward the most relevant evidence. It does not attempt to tell every story at once.

Work and Playground share a design system but answer different questions.

Work asks: What outcomes have I delivered in complex organizations?

Playground asks: What do I choose to explore and build when I control the problem?

Adding a fifth or tenth project should not require redesigning the site.

Layouts, card systems, filtering thresholds, content schemas, and project-detail components were considered with future scale in mind.

Hand-drawn elements, transitions, hidden interactions, and playful details make the experience feel personal.

They are used as moments of surprise rather than obstacles between a visitor and the information they need.

AI-assisted development rewards the ability to define a problem clearly, communicate constraints, recognize quality, and evaluate implementation trade-offs.

Those are product skills, but they increasingly influence the quality of the software itself.

A layout is not responsive simply because its components resize.

Content priority, interaction models, motion, density, and navigation all need to be reconsidered across viewports.

A component that can support every possible variation often becomes harder to use and easier to break.

The better system was opinionated about common behaviour while exposing only the variations that projects genuinely needed.

Several of the most important improvements emerged only after the site was live.

Real devices, screen sizes, browser tabs, URLs, loading behaviour, and scroll depth exposed issues that were invisible in isolated mockups.

That is not a flaw.

Like any maintained product, it can evolve as the audience changes, new projects are added, and better ways of communicating the work emerge.

The result is more than a place to store case studies.

It is a working demonstration of how I approach product development:

• Start with the audience and the problem
• Create a clear product narrative
• Design reusable systems
• Translate ambiguity into executable requirements
• Test the experience in real conditions
• Learn from failure states
• Ship, observe, and improve

It also gave me a practical environment for exploring where product management, design, engineering, and AI-assisted creation are beginning to overlap.

The next phase is focused on making the portfolio more observable and more interactive.

Planned explorations include:

• Measuring how visitors navigate between projects
• Understanding résumé views and downloads
• Expanding the Playground with more working prototypes
• Continuing accessibility and performance improvements
• Introducing small moments of surprise and delight
• Product Sprint — satirical endless runner on the play page (live in Playground)
• Developing a faster publishing workflow for future projects

The objective is not to add novelty for its own sake. Each addition should either improve understanding, reduce friction, or reward curiosity.