Automation
Connecting My QA Journal to My Portfolio Projects
I connected my Notion-powered QA Journal to the portfolio's existing Projects & Case Studies section, allowing journal entries and case studies to be displayed alongside my existing QA projects.
The Change
I already had a Projects & Case Studies section on my portfolio that showcased some of the QA projects I had worked on.
However, I also started building a separate QA Journal where I could write about experiments, case studies, things I learned, and projects that didn't necessarily need to be presented as traditional portfolio projects.
That created a small separation between the two.
I wanted the journal to feel like part of the portfolio rather than a completely disconnected section.
So I decided to connect the two.
The Goal
The goal was to make the existing Projects & Case Studies section capable of displaying both:
This means I can now write an article in Notion and have it automatically appear on my portfolio without having to manually add another card to my React code.
The flow became:
Notion
↓
QA Journal
↓
Next.js
↓
Projects & Case Studies
↓
Journal Card
↓
Full ArticleThe Existing Project Structure
My existing project cards are stored in a local data file.
They contain information such as:
This works well for projects that I want to manually curate.
However, journal entries are different.
Their content lives in Notion, so I didn't want to duplicate the information inside my React project.
Connecting Notion to the Portfolio
Instead of changing the existing project data structure, I kept the two sources separate.
The portfolio continues to load the existing projects from:
data/data.jswhile the journal entries are retrieved from Notion through:
lib/notion.jsI then created a small server component that retrieves the journal entries before passing them into the existing client-side Portfolio component.
This allows the client component to receive both datasets.
The Server Component
The new wrapper acts as the bridge between Notion and the existing portfolio component.
import Portfolio from "./Portfolio";
import { getQAJournalPosts } from "@/lib/notion";
export default async function PortfolioSection() {
const journalPosts = await getQAJournalPosts();
return <Portfolio journalPosts={journalPosts} />;
}This was useful because my existing Portfolio.jsx is a client component due to the animations and interactive UI.
Instead of trying to call the Notion API directly from the client component, the data is retrieved server-side first.
The Journal Card
I then created a separate card specifically for journal entries.
The card follows the same visual language as the existing project cards.
It includes:
This keeps the section visually consistent while still making it clear that the entry is a journal article rather than a traditional project.
Why Keep a Separate Card?
I could have forced the Notion data into the existing ProjectCard component.
But I decided against it.
The two types of content have different purposes.
A project might represent:
A product
A client project
A testing engagement
A development projectwhile a journal entry might represent:
A QA experiment
A case study
A lesson learned
A technical note
A workflow
A personal projectKeeping separate components makes the code easier to understand and gives me more flexibility later.
Internal Navigation
The original project cards use LinkPreview because some of the projects point to external websites.
For the QA Journal, however, the destination is an internal Next.js route:
/qa-journal/[slug]So I switched the journal card to use Next.js Link.
For example:
<Link
href={`/qa-journal/${post.slug}`}
className="flex items-center gap-2"
>
Read Entry
</Link>This is more appropriate for internal navigation and keeps the journal entries connected to the Next.js routing system.
The Result
The Projects & Case Studies section can now contain both types of content.
Projects & Case Studies
┌─────────────────────┐
│ CASE FILE #001 │
│ │
│ Existing QA Project │
│ │
│ ROLE │
│ QA Engineer │
│ │
│ QUALITY FOCUS │
│ Automation │
│ Accessibility │
└─────────────────────┘
┌─────────────────────┐
│ QA JOURNAL #001 │
│ ● PUBLISHED │
│ │
│ Turning My Portfolio │
│ Into a QA Test │
│ Subject │
│ │
│ #Accessibility │
│ #n8n #WCAG │
│ │
│ Read Entry → │
└─────────────────────┘The important part is that the journal card doesn't need to be manually added to the portfolio.
Creating a new published entry in Notion is enough for it to become available to the application.
What I Learned
This change made me think more about separating content from presentation.
Previously, adding a new project generally meant changing the code.
Now, journal content can be managed separately from the application itself.
That gives me a much easier workflow:
Write
↓
Publish in Notion
↓
Portfolio retrieves the entry
↓
Entry appears on the siteIt also means I can focus on writing the content without worrying about manually creating a new React component or modifying a data file every time.
What's Next
There are a few improvements I'd like to make from here.
Cover Images
I'd like to pull the cover image directly from the Notion page and display it on the journal cards.
This would make each entry more visually distinct.
Better Journal Filtering
The QA Journal already supports search and filtering by category and tags.