This
Portfolio

I built my portfolio the way I’d build a product. I wrote a brief, set the constraints, made a small design system, and shipped it, owning every part along the way.

There is a second idea underneath that. AI has changed what a solo designer who can build looks like, and this site is where I put it to the test. I wrote every line of HTML and CSS with Claude as my implementation partner. No Webflow, no template, no developer handoff. The brief, the critique and the direction stayed with me.

Constraints first

I started by defining what I wouldn’t do, because constraints produce better decisions than open-ended briefs.

It comes from Brasília

This site is neo-brutalist, and that is not an accident. I grew up in Brasília, the capital of Brazil, a city designed from scratch, where the bones of a building are always left showing: raw concrete, exposed structure, the load-bearing logic on display instead of hidden behind a finish.

Brutalism there was never about ugliness. It was about honesty, and I have kept that in the work. The thick borders and hard shadows are the structure, left on show on purpose. The colours are mine, a bit plural and a bit loud, picked by me instead of pulled from a UI kit. And I care about buttons that look like buttons, because an interface should feel like something you can press.

The colour comes from the same place. A building in Brasília is never only concrete. Look again and there is green growing through it and flowers breaking against the grey, and that contrast between raw structure and vivid life is the other half of the language. The accent colours across this portfolio are those colours, the loud greens, oranges and pinks of Brazilian nature, set against an honest concrete frame.

Design structure

The token set is deliberately small, and I decided each value rather than reaching for a default: a warm off-white ground (#F7F6F3) under near-black ink (#0A0A0A, softer than pure black), two warm greys for text, one structural 3px black border, a lime-and-yellow accent pair plus a per-case accent, and three hard-offset shadow steps. Type is all Nunito, one family loaded once, running at three weights, 600 for body, 800 for the small uppercase labels, 900 for headings, with sizes snapped to a fixed rem scale and the big type set in clamp() so it flexes without a breakpoint each. Spacing follows a four-step rhythm, from tight padding inside chips and buttons up to the 4.5rem gap between sections. Enough to stay consistent across eleven cases, not so much it needs a manual.

Shadows mean you can touch it

A hard shadow here is a signal, not decoration. It marks something you can interact with, a button or a card or a nav link, anything that lifts on hover and presses down on click. Everything static, the tables and images and callouts, stays flat. So if it casts a shadow, you can press it.

There are three steps, all hard offset with no blur. The motion follows the look: a card lifts when you reach for it and sinks when you commit, so it reads as physical weight. Blur would soften that, so I left it out.

Per-case accent system

Each case redefines --accent locally, one colour per project, picked to fit the character of the work. The colour carries feeling more than decoration, and it is a big part of what makes the site feel like one person’s body of work rather than a template. That is the part people remember.

Three patterns worth noting

These three interactions each needed a real decision. They are UX calls, not UI widgets, and the wrong choice on any of them would have broken something.

Reflow, not horizontal scroll

I built the site desktop-first and tested it down to 320px. Three breakpoints do most of the work: 900px drops the two-column grids and every data table to one column, 640px tightens the gutters, and 600px swaps the top navigation for a fixed bottom tab bar, the way a native app does.

Nothing is hidden on mobile and nothing overflows sideways. The one thing that scrolls horizontally is the "More cases" strip at the bottom, and that is deliberate, the way a shelf of cards should behave.

AI as implementation partner

I built the site over several sessions in Cowork, the Claude desktop app, with Claude as the implementation partner. It was not a case of describing a portfolio and watching it appear. It felt more like pairing with a very fast developer who needs clear direction on everything that matters.

Vague direction gives you generic output; specific direction gives you something that looks designed. That is the real skill in any AI-assisted workflow. The question is not whether you can use the tools, it is whether you can say what you want clearly enough to get back something worth keeping.

Built in from the start

Accessibility runs through my case work, so the portfolio had to show that I apply it rather than just claim it. I built each of the decisions below in from the start.

• Skip link to #main, visible on focus, so keyboard users can bypass the nav.
• Semantic landmarks: <nav>, <main>, <section aria-labelledby>, so screen-reader navigation works.
• Card accessibility: one focusable element per card, not a stack of links. A role="list" container with a labelled link.
• Focus ring: 3px solid black, 3px offset. Visible and on-brand, not the default browser blue.
• Contrast enforcement: fixed hex values, not opacity hacks. opacity: 0.4 on small text fails AA, so every value is set explicitly at 4.5:1 or better.
• Reduced motion: @media (prefers-reduced-motion: reduce) drops every transition.
• Focus & keyboard: section labels are real tab stops; the nav ring is dual white-plus-black, so it stays visible on any accent.
• Per-accent contrast: light accents (lime, yellow, coral) switch to a darkened token for text and black on fills, so every case clears WCAG AA.

Shipped, and live:

The portfolio is in production, and it holds to the brief it set itself.

1. Live on Vercel as a static site, served straight from hand-written HTML and CSS, with no framework and no build step.
2. WCAG AA across all eleven case pages: keyboard focus order, contrast, reflow to 320px, reduced-motion support, and semantic landmarks.
3. One design system, eleven cases. Each retheme is a single accent token, so a new case inherits the whole frame for free.
4. Written as I built it, rather than reconstructed afterwards, so the notes and annotations are the real record.
5. Owned end to end by one designer: the brief, the copy, the visual direction, the accessibility, and the code.

What I’d do differently:

1. Be specific earlier. Precise direction ("change this stripe from yellow to lime, text stays black") beat "the colours feel off, what do you think?" every time. The hours spent writing down exactly what something should do, before touching a surface, paid off the most, since that spec becomes the prompt.
2. Log decisions as they happen. Some calls are worth writing down the moment they are made, not later. A live log keeps the reasoning findable, catches contradictions early, and makes the case stronger. The part I logged as I went is documented well; the earlier part, less so.

What I got right:

1. Treating the portfolio as a product. Brief, constraints, audience, then design, a more coherent result than executing a layout.
2. The per-case accent system. It solves the visual-variety problem without a different layout for every case.
3. The collaboration model. Direction from me, execution from Claude. The quality of the output followed the quality of my direction, pretty directly.