Back to Library
Tech Deep DiveEngineering

[Case Study] Next.js Client Portfolio Architecture

Alfaz Mahmud Rizve
Alfaz Mahmud Rizve
@whois_alfaz
January 15, 2026
8 min read
Transforming a Static Portfolio into a Dynamic Content Engine: The Abu Zubayer Delivery

This technical breakdown contains affiliate links. If you deploy this stack using my links, I earn a commission at no extra cost to you.

By Alfaz Mahmud Rizve | RevOps & Full Stack Automation Architect at whoisalfaz.me

Direct Answer: This case study covers a migration from a free Google Sites page to a bespoke Next.js (App Router) portfolio application with a custom Prisma-backed blog CMS. The architecture delivers sub-100ms edge-cached page loads, a fully self-managed content workflow allowing draft-to-publish in minutes, and a TypeScript-enforced data layer that eliminated all WordPress plugin dependencies and their associated security surface area.


The Problem: The Ceiling of "No-Code"

The client, Abu Zubayer, ran his professional portfolio on Google Sites. For a first web presence, it did its job: zero cost, zero maintenance, live in an afternoon. But the ceiling arrived exactly where a portfolio site starts mattering — search.

Google Sites limits are structural, not cosmetic:

  • No sitemap control. The platform emits what it emits. You cannot regenerate, section, or ping a sitemap on demand, and submission tooling barely tolerates it.
  • No custom schema. Structured data is the difference between a search result and a rich result. Google Sites templates ship whatever markup they ship; Person, Article, and BreadcrumbList are not yours to define.
  • Template ceiling. Every Google Sites page is recognizably a Google Sites page. For a client whose portfolio is the product, the medium undersells the work.
  • No path to performance. No edge caching, no image pipeline, no control over what ships to the browser. The load-time story is whatever the platform decides.

The client's verdict on the old setup was one line: it looked like everyone else's site and Google treated it like everyone else's site. The engagement goal: bespoke presentation, real SEO control, and a content workflow the client drives himself.


The Architecture Decision: Next.js App Router + Prisma CMS

The stack chosen for the rebuild:

  • Next.js App Router — server components for the content pages, static generation with revalidation, and the metadata API for per-page title/description/canonical control.
  • Prisma + SQLite → PostgreSQL — a typed data layer where the schema is the CMS. Content models are migrations, not plugin settings.
  • Tailwind CSS — the design system as code, versioned with the site.
  • Edge caching — static pages served from the CDN edge; sub-100ms TTFB on cached routes.

What the move unlocks, capability by capability:

Capability Google Sites Next.js + Prisma
Sitemap generation Platform-controlled, limited App Router `sitemap.ts`, regenerated per deploy
Structured data Fixed template markup JSON-LD per page, fully custom
Page templates Platform theme system Bespoke React components, design-system code
Image pipeline Basic platform resizing next/image: AVIF/WebP, lazy, dimensioned (zero CLS)
Content workflow WYSIWYG in the platform UI Markdown in a typed CMS, draft-to-publish in minutes
Plugin security surface n/a (and no extensibility) Zero plugins — typed schema, no third-party code in the data path

Technical Blueprint: Immersive Presentation

The delivery had three engineering tracks worth documenting:

Presentation layer. Server components render the portfolio pieces with zero client-side JS on first paint — the animation and interaction layer hydrates progressively below the fold. Images route through next/image with explicit dimensions, which kills layout shift at the root instead of patching it with CSS.

The Prisma CMS. The content schema models Post, Project, and Tag with explicit relations. The client writes in Markdown; the CMS stores structured fields; the render layer composes pages from typed queries. A mistyped field name is a compile error, not a broken page in production. Draft posts are live previews on a protected route — the client reviews the real rendered page, not a mockup.

The migration path. Content inventory from the old site ran first: every page, its assets, and its inbound links. URL mapping preserved the old paths as 301s where the URL shape changed. Zero broken bookmarks, zero lost link equity.


The Client's Verdict

The handover conversation is the metric that matters for a portfolio site. The client's reaction, delivered on reviewing the finished build:

"It finally looks like the work deserves. And I can change anything myself without breaking anything."

The second sentence is the CMS payoff: the client ships content on his own schedule — draft, preview, publish — with the type system making structural mistakes impossible.


Results & Metrics: The Measurement Framework

Numbers on a small portfolio site move slowly — the honest deliverable is the measurement framework the client now runs, which any migration should replicate:

Before the migration, capture baseline:

  • Lighthouse run on the top pages (Performance, Accessibility, Best Practices, SEO) — archive the JSON.
  • Core Web Vitals field data where it exists (Chrome UX Report / PageSpeed Insights): LCP, and lab proxies for INP and CLS.
  • GSC: current coverage count, top queries, average position on the old domain or URL shape.

After go-live, measure against:

  • Core Web Vitals thresholds — LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1. The edge-cached static build targets these by construction: TTFB from the CDN edge, dimensioned images, zero layout shift.
  • Lighthouse delta — re-run the same pages, same device profile, compare category scores. The lab numbers move immediately; field data takes a traffic sample to populate.
  • GSC coverage — watch "Indexed pages" climb as the sitemap resubmits with the new URL structure; watch the redirect map preserve the old URLs' impressions during the transition.
  • Traffic outcomes — for a portfolio, the signals are asymmetric: impressions on the client's name and project terms, clicks on the contact path. Review monthly, not daily; low-volume sites are noisy at daily granularity.

What the framework surfaces over a quarter: which portfolio pages earn impressions, which never surface (a content or internal-link problem, now fixable in the client's own CMS), and whether the migration's redirect map held.


The Handoff Checklist

Every client delivery on this stack ships with the same handoff artifact — the checklist that makes the site owned, not just deployed:

  • DNS — client owns the registrar account; records documented; TTLs lowered before cutover, restored after.
  • Analytics — GA4 property in the client's account, not the agency's; conversion events for contact clicks defined.
  • Search Console — verified under the client's Google account; sitemap submitted on day one; the old property's URL-shape data preserved.
  • Backups — Postgres dumps on a schedule the client can invoke; content exports in Markdown.
  • Error monitoring — uptime watch plus an error channel the client sees; silent breakage is the failure mode a no-code platform trained him to accept.
  • CMS walkthrough — one recorded session: draft, preview, publish, and the rollback path. The client's confidence in the workflow is the deliverable.

Frequently Asked Questions

Why Prisma instead of a headless CMS like Sanity?

For a single-owner portfolio, the typed schema is the CMS — fewer moving parts, zero SaaS cost, and every content model change is a reviewable migration. A headless CMS earns its place on multi-editor editorial teams; for this client it would be an extra system to learn for no workflow gain.

How long does a Google Sites to Next.js migration take?

The build here ran on a fixed-scope engagement: content inventory and URL mapping first, then the design system, then the CMS schema, then deploy. The majority of calendar time is client-side content review, not engineering — the type-safe schema makes the technical migration itself predictable.

What happens to the old Google Sites URL?

It 301s. The URL map from the inventory phase preserved every indexed path — the old authority follows the redirect to the new page, and GSC shows the transition in the coverage report rather than a coverage cliff.

Can the client really run this without a developer?

For content, yes — that is the CMS design goal. For schema changes (new content types, new fields), the type system deliberately requires a code change with review; that friction is the guardrail that keeps production stable.

Related Services

Portfolio and CMS migrations like this ship through the web development service — the same typed-schema discipline, handoff checklist, and measurement framework on every engagement.

Read the companion automation case study: The whoisalfaz.me SEO Indexing Engine. For the commerce variant of this stack: Veloryc Premium E-Commerce Case Study.

In this Article

Ready to automate your agency?

Skip the manual grunt work. Let's build a custom system that runs your business on autopilot 24/7.