Most designers I know have the same problem. We spend years crafting interfaces, solving problems, shipping products — and almost none of it gets recorded properly.
I'm one of them.
Over the past six years, I've worked across banking, e-commerce, gambling, and e-learning. I've led design systems, growth experiments, mobile apps. But if you asked me to show you what I learned along the way — the thinking behind the decisions, the trade-offs, the things that didn't work — I'd have fragments scattered across Google Docs, Figma files, and Slack messages nobody will ever read again.
This portfolio exists because I got tired of that.
The problem with designer portfolios
Back in the day, building a portfolio was straightforward. You'd put together a static HTML page, maybe use a template, upload it somewhere, and call it done. The content was baked into the code.
Then website builders came along — Squarespace, Webflow, Cargo. They made things look polished, but they came with trade-offs:
| Approach | Cost | Customisation | CMS flexibility | Ownership |
|---|---|---|---|---|
| Static HTML | Free | Full control | None — content baked in code | You own everything |
| Squarespace / Cargo | $16–33/mo | Template-bound | Built-in but rigid | Platform-locked |
| Webflow | $14–39/mo | High (visual) | Good but complex | Exportable with limits |
| Next.js + Notion (this site) | Free | Full control | Full — write in Notion | You own everything |
Monthly subscriptions add up. You're locked into design constraints. And the moment you want something slightly custom, you're fighting the platform instead of building.
But here's the bigger issue nobody talks about: most portfolio tools treat your work as a gallery. A grid of thumbnails. A collection of pretty pictures.
They don't give you a place to think out loud. To write about your process. To capture the messy, honest story behind the polished final screens. And that's exactly the kind of content that makes a designer memorable.
What I wanted wasn't a portfolio. It was a central hub — a place to store my knowledge, my insights, and my work. Somewhere I could write articles, publish case studies, share social posts, and keep everything connected.
Why a CMS changes everything
The moment I separated content from code, everything clicked.
With a CMS, I don't touch the codebase to publish new work. I open Notion, fill in a few properties, write my content, and it goes live. No pull requests. No deployments. No context-switching between writing and coding.
Here's what this unlocks:
- I can publish a case study while sitting in a cafe with just my phone
- Social posts from LinkedIn or X get reposted with one entry — the card links directly back to the original
- Featured work on my home page updates by ticking a checkbox
- Password-protected case studies for NDA work — toggle it on and off from Notion
- Everything is in one place: articles, projects, contact form submissions
The CMS isn't about making the site easier to maintain. It's about removing every excuse not to share your work.
How I built it
The build has three parts: design, code, and content infrastructure. Each one is deliberately simple.
Part 1: Design — Figma, kept clean
I designed the initial style system in Figma. Black and white. Minimal borders. Generous whitespace. A few accent colours — yellow, green, pink — used sparingly for moments that need attention.
The philosophy: if the design system is simple, the content does the talking. I didn't want the portfolio to compete with the work it's showing.
I set up a small token system — border-radius values, spacing scales, colour variables — and mapped them directly to what the code would use. No design-to-dev translation gap.
Part 2: Code — Claude Code and Next.js
This is where it gets interesting. I used Claude Code — Anthropic's CLI tool — as my primary coding partner.
The stack:
- Next.js 14 with TypeScript — static generation and ISR (pages rebuild every hour without a full deploy)
- Tailwind CSS — utility-first styling mapped to my Figma tokens via CSS custom properties
- Notion API — the CMS layer, fetching content at build time
- Framer Motion — subtle animations that make interactions feel polished
- Vercel — hosting with zero-config deployment from Git
Why this stack? Because every piece earns its place. Next.js gives me static performance with dynamic content via ISR. Tailwind keeps my styles close to the markup — no stylesheet archaeology. The Notion API is free and the data model is flexible enough to handle both structured case studies and freeform articles.
Claude Code handled the heavy lifting. I'd describe what I needed — "split the CMS into separate modules for articles and projects" or "add a password gate for protected case studies" — and it would write the implementation, refactor across files, and run the build to verify. The workflow felt less like prompting an AI and more like pairing with a senior engineer who types faster than you.
The codebase is split cleanly:
lib/notion/client.ts— shared Notion utilities and block fetchinglib/notion/projects.ts— work/case study querieslib/notion/articles.ts— article and social post queriescomponents/NotionRenderer.tsx— converts Notion blocks into React components
Each content type has its own module, its own types, its own data flow. When I add a new property to the CMS, the change is isolated to one file.
Part 3: Content — Notion as the CMS
Notion is the engine behind everything. Two databases — one for Work, one for Articles — each with property descriptions that tell you exactly what to fill in.
For Work entries, I set the title, company, team, timeline, and a few multi-select tags for filtering. The URL auto-generates from the title. Cover images come from Notion's built-in page cover. The content is written directly in Notion using headings, text, images, and embeds — a custom renderer converts all of it to the site.
For Articles, it's even simpler. Title, excerpt, tags, and content. But here's the part I like most: the Type property. Set it to "Article" and it's a full page on the site. Set it to "Social Post" and the card links directly to the original LinkedIn or X post. One database handles both — long-form writing and quick social reposts live side by side.
No markdown files. No separate CMS dashboard. No build step to preview. I write in Notion and the site updates.
What's next: connecting the dots
The portfolio is live, but the vision is bigger.
Right now, content flows one direction: from Notion to the site. But I want to close the loop. When I publish a LinkedIn post or write a thread on X, I want that content to flow back into the hub automatically. Not just as a link — as a first-class entry in the articles database, tagged and categorised alongside everything else.
The aspiration is a single system where every piece of my professional output — case studies, articles, social posts, talks — lives together and connects. A personal knowledge base that also happens to be a portfolio.
That's the direction. One step at a time.
For designers thinking about building
If you're a designer sitting on years of undocumented work, here's what I'd say:
You don't need a beautiful portfolio to start. You need a system that makes publishing effortless. Because the biggest barrier isn't design or code — it's friction. Every extra step between "I should share this" and "it's live" is a reason to procrastinate.
Here's a starting point:
- Pick a CMS you already use (Notion works)
- Set up a simple site with static generation (Next.js + Vercel is free)
- Use AI tools like Claude Code to handle the code — you don't need to be an engineer
- Keep the design minimal — your content is the design
- Start with one case study. Then one article. Then keep going.
The tools are better than they've ever been. A designer today can build a custom, CMS-driven portfolio in a weekend — for free — that would have taken a developer weeks to set up a few years ago.
The question isn't whether you can. It's whether you will.
Start documenting. Start sharing. The work you've already done deserves to be seen.

