Portfolio Website

This portfolio itself: a bilingual Next.js site with its own admin dashboard, built to manage projects, achievements, and messages without ever touching code or redeploying.

Every route is locale-prefixed (/en/..., /id/...) through next-intl, with full translation-key parity between English and Indonesian kept by convention rather than tooling. Switching language is a client-side transition, not a reload, and it deliberately keeps your scroll position: a bug fixed after tracing why the page seemed to jump on locale switch. Next.js resets scroll to top on every navigation by default; the fix was one option, scroll: false.

Theme, dark by default with light available, is handled by next-themes with no system-preference fallback. That means no flash of the wrong theme on first paint and no dependency on a visitor's OS setting.

Performance, SEO, and Loading States

Every route and every image carries a skeleton loading state: a loading.tsx per route, plus an ImageWithSkeleton wrapper around next/image, replacing what used to be spinners. That wrapper exists because of a real edge case: a cached image can finish loading before a React onLoad listener even attaches, so the component also checks .complete directly on mount as a fallback.

SEO is handled per page: unique metadata and OG images per route per locale, sitemap.xml, robots.txt, and hreflang tags linking the EN and ID versions of each page. This was measured, not assumed. A mobile Lighthouse audit scored 99 for Performance and 100 each for Accessibility, Best Practices, and SEO.

Production builds run through Webpack instead of Next.js 16's Turbopack default. An audit found Turbopack's production output was shipping roughly 18 KB of legacy browser polyfills to every visitor through a plain <script> tag. Webpack ships the same fallback behind <script nomodule>, so modern browsers, over 99% of traffic, skip it entirely.

Security and Rate Limiting

The contact form and the Love button are both rate-limited per IP with an in-memory sliding window, so neither can be flooded into spamming the database. Every input is validated with Zod on the client, for fast feedback, and on the server, the boundary that actually matters, since a client-only check can always be bypassed. Contact form messages render as plain text, never through dangerouslySetInnerHTML, so a message can't inject markup into the admin inbox.

Workflow

Work on this site is tracked in Notion, task by task, each carrying an explicit "done when" checklist before it gets marked complete. That discipline exists for a reason: this project stalled once before, built without any scope boundary at all.

The one time data had to move outside the running app itself, migrating real project and certificate data from a development Supabase project into the production one, ran entirely from the command line: pg_dump piped into psql for the database rows, rclone for the storage files, both installed locally through Homebrew. That migration never touched the deployed app; it was a one-off operation, not a dependency of the site.

Tech Stack

Architecture Decisions Worth Noting

• No separate API layer. Reads go through Server Components straight to Prisma; writes go through Server Actions. A REST layer would only add a layer with no consumer outside this app.
• Two databases, not one. Development and production run on separate Supabase projects, so a leaked dev credential, or an accidental local seed reset, can never touch real visitor data.
• Fresh data without a full rebuild. Pages driven by the database use time-based revalidation, and every admin write calls revalidatePath() for the routes it affects, so a change made in the dashboard is visible on the public site by the next request, not the next deploy.

Links

• Live site: fatihaljabar.com
• Source: github.com/fatihaljabar/portfolio