From Blog to Technical Portfolio: Hashnode, GitHub and AI

The technical foundations of my personal website: Hashnode Pro, GitHub, Codex, content management, and integration possibilities.

This is the third and final article in my series, Building davidpataki.com with AI.

In the first part, I explained why I decided that building a personal technical blog still makes sense in the age of AI.

In the second part, I described how I collected my earlier technical content and used ChatGPT and Codex to build a catalog of 102 records.

In this final part, I'll focus on the technical implementation: why I chose Hashnode, how I use GitHub and Codex, and what opportunities I see for future integrations.

Why Hashnode Instead of Building My Own Website?

As a developer, I could have built my own website.

I've spent more than twenty years developing business applications with Oracle Database and Oracle APEX. Building a simple CMS wouldn't have been a particularly difficult technical challenge.

But that was exactly what I wanted to avoid.

I didn't want another application to develop, operate, and maintain. My goal was to organize and publish technical content, not build another content management system.

That's why I chose Hashnode, a platform well suited to publishing technical content.

Markdown editing, code blocks, a custom domain, SEO settings, RSS, series, and GitHub integration were all useful features for this project.

Another important consideration was keeping my articles accessible outside a single provider's platform. With Markdown and GitHub, the content can be preserved and processed independently.

Why I Subscribed to Hashnode Pro

You can start using Hashnode for free, but I decided fairly early to subscribe to Pro.

At the time of writing, it costs $5 per month, or $50 per year when billed annually.

For me, that's a reasonable price to avoid maintaining a separate publishing infrastructure.

Pro offers features such as custom domains, GitHub backups, access to the GraphQL API, webhooks, AI-assisted writing tools, bulk Markdown import, and scheduled publishing.

I don't use all of these features yet.

My custom domain and GitHub backup are already part of the workflow. The API and webhooks are options I'd like to explore later.

As a developer, I particularly like knowing that documented interfaces are available if I eventually want to connect my content catalog directly to the blog.

Limited Design Options Can Be an Advantage

One limitation of Hashnode is that you can't customize its appearance as freely as you could with a website you've built yourself.

There are layout choices, colors, logos, and other branding options, but you can't redesign every part of the interface.

At first, this felt restrictive. As a developer, I'm used to implementing things differently when I want to.

Then I realized there was an upside.

When you don't have endless design options, it's harder to get lost in the details.

I picked a simple, clean design, configured the necessary branding elements, and focused on the content.

If I ever need a completely custom interface, Hashnode's headless CMS capabilities could allow me to use a separate frontend.

For now, though, I don't see much point in making something more complicated when the whole idea was to simplify it.

A Custom Domain with a Few DNS Settings

It was important to me that the website run under my own domain, davidpataki.com.

In the Hashnode Publication Dashboard, the platform provides the DNS records that need to be configured with the domain's DNS provider.

According to Hashnode's documentation, a typical apex-domain configuration uses the following records:

The exact setup can depend on the DNS provider and configuration, and some situations require an additional TXT record for verification. The values above are from Hashnode's documentation, not a live export of my domain's DNS zone.

After the records are configured, Hashnode verifies the domain mapping and automatically handles SSL certificate issuance.

So I didn't need to set up a separate web server, configure HTTPS, or arrange certificate renewals.

Using my own domain also means davidpataki.com remains the permanent entry point for readers, regardless of the publishing platform behind it.

Posts, Pages, and Series

I used three Hashnode features to organize the content:

• Posts: Regular blog articles displayed chronologically.

• Pages: Permanent content pages with their own URLs, which can also be added to navigation.

• Series: Collections of related blog posts.

The seven permanent pages described in the second article provide entry points into my technical portfolio. Individual posts explore particular topics, while series connect articles that belong together.

I also had to make a compromise with navigation. I didn't want every page to appear as a top-level menu item, especially on mobile.

So the main topics are directly accessible, with the remaining pages available under the More menu.

GitHub: Backup and a Foundation for AI-Assisted Work

For me, one of the most valuable Hashnode Pro features is its GitHub integration.

I configured a private GitHub repository to preserve the blog content in Markdown format.

My original reason was backup. I don't want my technical articles to exist only in an external provider's editing interface.

But GitHub turned out to be useful for more than that.

I also configured the repository in my Codex working environment, so I could use earlier articles in AI-assisted work.

Codex can help check whether I've already written about a particular topic, identify relevant articles to link to, and find overlap between publications.

GitHub therefore has two roles:

A backup of my content and a source that AI tools can work with.

Hashnode also offers ways to publish Markdown articles from GitHub. I haven't adopted that workflow yet; I still review and publish the final content through Hashnode's editor.

How I Structured the Codex Project

Alongside the blog's GitHub backup, I created a separate local project:

C:\Codex\ACE

This is where we processed my earlier technical materials and built the 102-record content catalog described in the second article.

We didn't need another database or CMS. We stored the information in straightforward, manageable file formats.

Some of the key project files were:

We archived the source files separately and created Python and PowerShell scripts to process them.

The scripts handled CSV, PDF, HTML, and ZIP files, compared Oracle ACE, LinkedIn, and website data, and generated structured catalogs and validation reports.

We preserved the original files and recorded SHA-256 checksums so the processed data could be traced back to its sources.

The workflow was divided into smaller, verifiable steps:

Sources → Extraction → Reconciliation → Structuring → Validation → Editing

One important lesson was that a working script isn't necessarily a safely repeatable automation. Some tools were written for one-time imports, so we also kept status notes and protective checks to avoid overwriting later changes.

When Markdown Didn't Behave as Expected

Hashnode's Markdown support made AI-assisted editing much easier. We prepared the articles and pages in Markdown, then finalized them in Hashnode.

However, while preparing the two video course pages, we found that not every embedding method behaved as expected. One YouTube embed syntax appeared as plain text instead of a video.

We ended up using linked thumbnails, playlist links, and organized lesson lists.

It was simpler, but it did the job.

SEO and Validation

Hashnode supports SEO titles, meta descriptions, canonical URLs, a sitemap, and RSS feeds.

We also checked the published website with Codex. On September 30, 2026, the HTTP audit covered 28 starting URLs and 86 additional verification targets.

We found a broken internal link and metadata that didn't appear exactly as expected.

It reinforced a simple lesson: you need to check the actual published website, not just the Markdown or the values entered in the editor.

What Else Could I Integrate?

Hashnode Pro's documentation describes several options that I haven't implemented yet but may explore later.

GraphQL API: Programmatic access to supported publishing data and operations. This could provide a direct connection between my content catalog and the blog.

Webhooks: Hashnode can send HTTP notifications when an article or page is published, updated, or deleted. An external system could use these events to update the catalog or prepare a LinkedIn post.

Bulk Markdown import: Pro supports importing Markdown with frontmatter metadata, including original publication dates. This could be useful for the backdating problem I mentioned in the second article.

Analytics and newsletters: Visitor data and subscriber tools could help me understand which subjects readers are interested in and stay in touch with them directly.

Headless CMS: If I eventually want a custom frontend, Hashnode could still manage the content while a separate application handles presentation.

These are possibilities, not integrations I've already built.

Why This Matters for the Oracle ACE Program

One of the main motivations behind this project was my participation in the Oracle ACE Program.

As an Oracle ACE Pro, regular technical knowledge sharing is important to me. But writing an occasional article or giving a conference talk isn't enough to establish a sustainable publishing practice.

I need a stable foundation that helps me create, organize, publish, and retrieve technical content consistently.

A technical contribution isn't always a single publication.

One conference talk may have a presentation deck, a video recording, a blog article, a social media post, and an Oracle ACE contribution record associated with it.

When those items live independently across several platforms, they become difficult to track and present later.

That's why I wanted a central website where I could connect earlier work, link to original sources, and publish new material within a consistent structure.

That's the role davidpataki.com now plays.

GitHub and Codex help preserve and process the material, while Hashnode provides the public publishing platform.

This doesn't mean I need to move every older resource onto the site. It's more important that related materials remain discoverable and that their place in my broader technical work is clear.

And there's another benefit that matters just as much to me.

davidpataki.com is also a professional portfolio that keeps growing.

It doesn't just show what I'm currently working on. It provides a way to explore the problems I've worked on, the experience I've gained, and how my professional focus has evolved over time.

AI didn't replace that experience. It helped me organize it and make it easier to share.

This three-part series is now complete, but the project itself isn't.

My goal is for davidpataki.com to become the central platform for regular technical knowledge sharing and a professional portfolio that I can keep building over the long term.