Building My Own QA Journal

When I started adding more QA experiments and projects to my portfolio, I realized I needed a better way to document them.

My existing Projects & Case Studies section worked well for showcasing completed projects, but not everything I wanted to share needed to be presented as a full project.

Some were smaller experiments, things I was learning, troubleshooting experiences, or technical discoveries.

That led me to build a QA Journal.

Instead of creating every article directly in my code, I wanted the journal to be easy to maintain, so I decided to use Notion as the content source and connect it to my Next.js portfolio.

What I Wanted to Build

The idea was fairly simple:

The basic flow became:

Notion
   ↓
Notion API
   ↓
Next.js
   ↓
QA Journal
   ↓
Individual Journal Entry

Using AI as My Development Assistant

Since I was building this while still learning more about Next.js and the Notion API, I used AI throughout the development process.

I used it to help me:

I wasn't simply asking AI to build the entire feature for me.

A lot of the time, I already knew what I wanted to accomplish and used AI to help me figure out how to implement it.

This made the development process much more efficient, especially when I encountered something I hadn't worked with before.

Connecting Notion to Next.js

I created functions in lib/notion.js to retrieve my journal entries.

The journal database contains properties such as:

Title
Description
Category
Tags
Published
Date
Slug

I then mapped those properties into the format my React components needed.

This meant I could add a new journal entry in Notion without having to manually modify my React code.

That was one of the main reasons I wanted to use a CMS-like approach instead of hardcoding every article.

Building the Journal UI

Once I could retrieve the data, I created the journal listing and individual article pages.

The journal cards display information such as:

Clicking an entry takes the user to:

/qa-journal/[slug]

The individual page then retrieves the content blocks from the corresponding Notion page and renders them.

I also added previous and next navigation so visitors can move between journal entries without having to return to the main journal page.

Connecting It to Projects & Case Studies

After getting the journal working, I wanted it to feel more integrated into the rest of my portfolio.

I already had a Projects & Case Studies section, so I decided to allow journal entries to appear there as well.

Instead of changing my existing project data structure, I kept the two sources separate:

Existing Projects
       ↓
data/data.js

QA Journal
       ↓
Notion

I then created a server component that retrieves the journal posts and passes them into my existing Portfolio component.

This allowed the existing project section to display both traditional projects and journal entries without making the architecture unnecessarily complicated.

Testing and Fixing Issues

Of course, getting the feature to work wasn't the end.

I had to test things like:

One issue I encountered was particularly interesting.

A long journal entry wasn't displaying completely. At first, I thought there was something wrong with the rendering.

After investigating the data flow, I discovered that I was only retrieving the first batch of blocks from the Notion API.

The API uses pagination, so longer articles required additional requests to retrieve the remaining blocks.

With the help of AI, I was able to understand the issue and implement pagination using has_more and next_cursor.

That was a good reminder that sometimes what looks like a UI problem is actually a data retrieval problem.

What I Learned

This project helped me understand several things beyond just building a journal.

1. Content and presentation don't have to live together

Using Notion as the content source means I can write and update articles without modifying the application code.

2. Server and client responsibilities matter

I learned why it made sense to retrieve Notion data on the server before passing it into my client-side portfolio components.

3. APIs have their own limitations

The pagination issue taught me that retrieving data isn't always as simple as making one API request. I need to understand how the API actually returns its data.

4. Real content is important for testing

Short placeholder text didn't expose some of the problems that appeared once I started adding actual long-form journal content.

5. AI can make development more efficient

Using AI helped me move faster when learning unfamiliar APIs, debugging issues, and exploring implementation options.

But I still had to understand and validate the code it suggested.

Final Thoughts

Building the QA Journal was a relatively small project, but it gave me the opportunity to explore several things at once: Next.js, React, Notion, APIs, dynamic content, UI development, and QA testing.

More importantly, it gave me a feature that I can continue using as I learn.

Now when I experiment with something new in QA, I don't just have to keep it as a random project or note.

I can document it, publish it, and make it part of my portfolio.