Why I Built My Own Portfolio Instead of Using a Template

Every developer eventually faces this question: do you use a pre-built portfolio template, or do you build your own from scratch? For most people, a template is the sensible answer. But for a software engineer whose primary claim is that they can architect and build complex, scalable web systems — using a template would be a contradiction.

So I built engmoh.com from scratch. This article walks through the architectural decisions, the technical challenges, and the engineering principles that shaped the platform from the ground up.

---

The Architecture: Headless CMS + Next.js Frontend

The core architectural decision was to decouple the content management layer from the presentation layer entirely. This is known as a Headless CMS approach.

Backend: Laravel 13 REST API

The backend is built on Laravel 13 with PHP 8.3. It serves as a pure REST API — responsible for data management, business logic, authentication, and content delivery. The admin panel is powered by Filament v5, which provides a polished, fully-featured management interface without requiring any custom frontend development for the CMS itself.

Key backend capabilities include:

• Multi-language content via Spatie Translatable — all content fields store both Arabic and English simultaneously as structured JSON
• Intelligent caching via Redis for frequently accessed endpoints
• Content-type management for Projects, Services, Blog Posts, and Site Settings — all editable through the admin panel
• Role-based access control and two-factor authentication on the admin interface
• AI-assisted features including voice-to-text transcription and automated content suggestions

Frontend: Next.js 15 + React 19

The public-facing website runs on Next.js 15 with React 19 and the App Router. This combination unlocks React Server Components — which means most page rendering happens on the server, reducing the JavaScript payload shipped to the browser and dramatically improving initial load performance.

Why Next.js specifically? Three reasons:

1. Incremental Static Regeneration (ISR) — pages are statically generated but can be revalidated on-demand when content changes in the CMS, giving the best of both static speed and dynamic freshness
2. App Router — co-locating layouts, loading states, and error boundaries at the route level results in much cleaner code organization than the old Pages Router
3. Built-in optimization — image optimization, font optimization, and automatic code splitting come out of the box

---

The Caching Strategy: Three Tiers

Performance was a non-negotiable requirement. The caching architecture operates at three independent layers:

Layer 1 — Browser Cache

Static assets (images, fonts, JavaScript bundles) are cached at the browser level with long-lived cache headers. Content that rarely changes does not need to round-trip to a server on every visit.

Layer 2 — Next.js unstable_cache + On-Demand Revalidation

API responses fetched by Server Components are cached using Next.js's built-in unstable_cache. These caches are invalidated on-demand via a webhook that fires whenever content is updated in the CMS admin panel. This means: the site is fast like a static site, but content updates go live within seconds of being published — no full rebuild required.

Layer 3 — Module-Level Client Cache

For data fetched on the client side, a lightweight module-level cache stores results in memory during the page session. This prevents duplicate network requests when navigating between routes that share the same data.

The result: most pages load from cache in under 100ms, with no stale content problem because the invalidation chain fires automatically on every publish.

---

The Bilingual System: Arabic + English Without a Library

Supporting both Arabic and English — including right-to-left text direction for Arabic — is a core requirement. Rather than adopting a heavy i18n library, I implemented a custom translation system tailored to how the site actually works.

How It Works

The selected language is stored in a browser cookie. On the server side, Next.js reads this cookie during the request and selects the appropriate language content from the API response — since every content field from the Laravel backend already contains both languages as separate values. On the client side, language switching fires a Custom Browser Event that is caught by a useTranslation hook, causing the UI to update without a full page reload and without duplicating any fetch calls.

The dir attribute on the HTML root element switches dynamically between ltr and rtl, which combined with Tailwind CSS's rtl: variant utilities, handles the entire layout mirroring automatically.

---

AI Integration: From Tool to Feature

AI is not a gimmick in this project — it is integrated as functional infrastructure at multiple points in the workflow.

Voice-to-Text Transcription

The admin panel supports audio uploads that are automatically transcribed using AI voice recognition. This makes it practical to capture long-form Arabic content by speaking rather than typing — something that matters in a bilingual workflow where typing Arabic can be slower.

Content Assistance

When creating blog posts or project descriptions, an AI assistant can generate initial drafts based on structured prompts. These drafts are starting points — the final content is always reviewed and edited manually before publishing. The goal is speed of iteration, not hands-off generation.

The Engineering Approach

AI calls are handled asynchronously via Laravel queues, so they never block the admin interface. Results are written back to the model when ready, and the admin panel notifies the user via real-time Livewire updates. This keeps the experience responsive regardless of how long an AI operation takes.

---

SEO Engineering: Every Detail Accounted For

A portfolio website that does not rank is a portfolio that does not get seen. SEO was treated as an engineering discipline, not an afterthought.

What Was Implemented

• Dynamic Metadata — every page generates its own <title>, <meta description>, canonical URL, Open Graph tags, and Twitter Card tags based on the actual content of that page
• JSON-LD Structured Data — each content type emits the appropriate schema markup: Person, WebSite, Article, Service — helping search engines understand the semantic structure of the content
• Dynamic Sitemap — the sitemap is generated programmatically and includes all published blog posts, projects, and service pages with accurate lastmod timestamps
• Robots.txt — configured to block specific route variants (such as alternate theme URLs) from indexing, consolidating ranking signals on the canonical versions
• Core Web Vitals — Server Components, ISR, image optimization, and deferred loading of non-critical scripts collectively keep LCP, CLS, and FID within green thresholds

---

The Dual Theme System

The blog section of the site ships with two themes: a dark theme at /blog and a light theme at /blog-white. Both are functionally identical and serve different reading preferences. The light theme variant is blocked in robots.txt to prevent duplicate content from splitting SEO signals — canonical URLs point to the primary dark theme version.

Theme switching uses CSS custom properties rather than conditional class logic, which means the theme changes with a single root-level attribute swap rather than re-rendering any components.

---

Technology Stack Summary

For reference, here is the full stack used to build engmoh.com:

• Frontend: Next.js 15, React 19, Bootstrap 5, GSAP 3, SAL.js, Swiper 11
• Backend: Laravel 13, PHP 8.3, Filament v5, MySQL, Redis
• Content: Spatie Translatable, custom bilingual i18n
• AI: OpenAI Whisper (voice transcription), GPT-4o-mini (content assistance)
• Media: Python + Pillow (automated asset generation)
• Infrastructure: Nginx, Linux, Git

---

What I Would Do Differently

In the spirit of honest engineering reflection — a few decisions I would revisit:

TypeScript from day one. The frontend was started without strict TypeScript enforcement, and adding it incrementally is always more painful than starting with it. The type safety it provides, especially across Server/Client Component boundaries in Next.js, is worth the initial setup cost.

Earlier investment in end-to-end testing. The bilingual system and the cache invalidation pipeline both have a lot of moving parts. Playwright tests covering critical paths would have caught regressions faster during development.

Neither of these is a fundamental flaw — they are the kind of tradeoffs that happen when a single engineer is moving fast on a project. They are documented here because they are the lessons worth carrying into the next project.

---

Closing Thoughts

Building your own portfolio is not the right decision for every developer. But for someone whose work involves designing systems for others, there is no clearer demonstration of capability than the platform they built for themselves.

Every architectural decision in engmoh.com was made intentionally, for specific technical or product reasons — not because it was familiar or easy. That is the standard I try to apply to client projects as well.

If you have questions about any part of the implementation, feel free to reach out. The contact details are on the site.