Skip to content
All posts
· 5 min read

Turning sokpich.dev Into a Personal-Brand Hub

metanextjspersonal-brand

For the past year, sokpich.dev has been one thing: a portfolio. A place to point recruiters at, with the apps I've shipped and the work I'm proud of. That's still its job — but a portfolio alone is a static resume. This post is about the bigger plan: turning the domain into a personal-brand hub, and the architecture decisions behind it.

One domain, many sections

The idea is simple: the portfolio stays exactly where it is — the homepage — and new sections grow around it as siblings.

Hub architecture: sokpich.dev with /, /blog, /oss, and /projects as subpaths

The first real decision was subpaths vs. subdomains. My first instinct was blog.sokpich.dev, coffeecraft.sokpich.dev, one subdomain per project. It looks clean, but it fragments the thing I'm actually trying to build:

  • SEO — search engines treat subdomains as semi-independent sites. Every backlink to blog.sokpich.dev would build authority for the subdomain, not for sokpich.dev itself. Subpaths concentrate everything on one domain.
  • Infrastructure — each subdomain means separate DNS, SSL, and deploy targets. Subpaths are just routes in the Next.js app I already have.
  • Coherence — one nav bar, one theme, one deploy. The hub feels like one site because it is one site.

The blog you're reading

This blog is the first new section, and it follows the same convention the rest of the site already uses: typed data in data/, assets in public/, no CMS, no database.

Each post is an MDX file in the repo. Metadata lives in a typed manifest:

data/posts.ts
export type Post = {
  slug: string;
  title: string;
  excerpt: string;
  date: string;
  tags: string[];
  draft?: boolean;
};

Publishing a post is: write the .mdx, drop attachments in public/blog/<slug>/, add one manifest entry, git push. Vercel rebuilds and the post is live — version-controlled, reviewable, and with zero moving parts to maintain.

OptionEditingInfraVerdict
MDX in repocode editornonechosen
Headless CMSweb UIaccount + API keysoverkill for one writer
Database + admincustoma whole CMS to buildno

What's next

The roadmap, in order — deliberately one piece at a time:

  1. Blog — this. Writing compounds; everything else depends on it.
  2. Open source — an /oss page for my GitHub work, with live star counts pulled at build time.
  3. Project landing pages — maybe. /projects already has deep case studies, so this one can wait.

If you're reading this, phase one shipped.