This Site — Portfolio as a Product

Problem

A resume asserts seniority; it can't demonstrate it. I wanted a portfolio that is itself a production system — every feature a verifiable work sample a recruiter can click, read, and interrogate.

My role

Everything: product, design, backend, frontend, and operations — designed, built, and run solo.

Constraints

• Serverless deployment must not exhaust Postgres connections, and public pages must stay ISR-cacheable behind strict security headers.
• Content ships in English, Spanish, and German without triple-authoring every post.
• The AI assistant answers from my real content only, within a daily cost budget, and has to resist prompt injection.

Architecture

Next.js 14 App Router with TypeScript and Prisma on Postgres. The assistant is retrieval-augmented: site content is chunked and embedded into pgvector, retrieved per question, and answered with OpenAI models — with prompt-injection defenses, per-IP rate limits, a daily token budget, and cron-driven re-indexing. An LLM translation pipeline generates the Spanish and German locales with hash-based staleness detection. The admin surface sits behind NextAuth credentials plus WebAuthn passkeys under a nonce-based CSP. The resume PDF is rendered server-side with PDFKit in all three languages. Blog search uses Postgres full-text search; every route emits canonical/hreflang metadata, JSON-LD, per-route Open Graph images, a sitemap, RSS, and llms.txt.

Outcome

The site you are reading: multilingual blog and case studies, an AI assistant grounded in my own writing, and a recruiter-ready PDF resume — all generated from one codebase and operated in production.

What I'd do differently

Design the i18n routing from the start — retrofitting it meant every public page now exists in two route trees. And put project metrics in the schema instead of prose so they can render as highlight chips.