Back to selected work

ENGINEERING CASE STUDY · PORTFOLIO ARCHITECTURE

Building an AI-powered
engineering portfolio.

NEXT.JS · REACT · TYPESCRIPT · CLOUDFLARE WORKERS · WORKERS AI

I built my portfolio as a serverless web application rather than a collection of static pages. It combines a custom interface, server-rendered content, API endpoints, and an AI assistant that answers questions about my professional experience and projects.

The goal was to create a portfolio that demonstrates the engineering capabilities it describes while keeping hosting and operational overhead low.

01 / ARCHITECTURE

The architecture

The application uses Next.js App Router conventions, React Server Components where appropriate, and TypeScript for application code. Vinext and its Cloudflare integration provide the build and runtime path for deploying the application to Cloudflare Workers.

The deployed application uses Cloudflare's asset and AI bindings, with API route handlers for health checks and conversational requests.

How a visitor request and a chatbot question move through the deployed application.

CLIENT

Browser

Renders the React interface, including the project gallery, timeline, contact form, and floating chat panel. Client-side state is used only where interaction needs it.

Website request

Browser → Cloudflare Worker → Server-rendered React page or static asset

Health check

Browser → /api/health → Worker route handler → JSON status response

AI conversation

Chat interface → /api/chat → Request validation → History preparation → Workers AI → JSON reply

02 / AI ASSISTANT

A grounded conversational assistant

The chatbot uses the @cf/meta/llama-3.1-8b-instruct-fp8 model through the Cloudflare Workers AI binding. Rather than introducing a vector database and retrieval pipeline for a small knowledge base, curated professional information and response rules are included in a system prompt.

The backend validates the request, accepts user and assistant messages, limits conversation history, truncates individual messages, and checks that the latest message comes from the user before calling the model.

This keeps the implementation relatively simple while demonstrating AI integration, API design, input validation, and server-side model invocation.

03 / INTERFACE

Interface engineering

The interface uses custom CSS rather than a component library. It includes responsive navigation, a filterable project gallery, an interactive experience timeline, technology badges, and a floating chat interface.

Most page content is server-rendered, while client-side React state handles interactions that need it. CSS variables and custom animations support the visual system, with reduced-motion handling for applicable effects.

04 / DEPLOYMENT

From GitHub to Cloudflare

The source code is maintained on GitHub. Changes pushed to the main branch trigger the configured Cloudflare Workers Builds pipeline, which builds and deploys the application.

The build uses the project's vinext-specific scripts. The application runs on Cloudflare's serverless infrastructure without a separately managed Node.js server.

npm run build:vinextnpm run deploy:vinext

05 / DECISIONS

Engineering decisions

01

Add a free contact path with an automatic reply.

The contact form posts to Formspree, and a small Google Apps Script sends an acknowledgement email with a per-address cooldown, avoiding a paid service.

02

Keep the architecture proportionate to the problem.

A curated system prompt is sufficient for a relatively small, stable professional knowledge base. A retrieval pipeline would add complexity without necessarily providing a meaningful benefit at this stage.

03

Validate at the API boundary.

The chat endpoint checks request structure, allowed message roles, message content, history length, and the final message role before invoking the model.

04

Keep the main experience lightweight.

Server-rendered page content reduces the need for client-side data fetching. Interactive components use client-side state only where necessary.

05

Make operational behavior visible.

The health endpoint and chatbot request trace give visitors a way to see that the interface communicates with a real backend.

06 / TRADE-OFFS

Current limitations

This project is an evolving demonstration, not a claim of enterprise-scale infrastructure.

  • No dedicated automated test suite yet.
  • No application-level rate limiting on the chat endpoint.
  • AI responses are not streamed.
  • Chat accessibility can be improved, including keyboard navigation and focus management.
  • The chatbot's origin check is a basic browser-request guard, not authentication or complete abuse prevention.
  • The contact form's automatic acknowledgement is sent from a free Google Apps Script, so it can land in the sender's spam folder.

What I would improve next

  • Add API rate limiting and abuse monitoring.
  • Implement automated tests for validation, chat behavior, and main user flows.
  • Stream AI responses to improve perceived responsiveness.
  • Improve keyboard navigation and focus management in the chat panel.
  • Add a sitemap, structured metadata, and a self-hosted CV file.
  • Consolidate professional profile data so the website and chatbot knowledge base remain consistent.

THE RESULT

A working serverless application.

The portfolio brings together frontend engineering, backend route handlers, AI integration, custom UI development, and automated deployment. It is also an ongoing engineering project: a place to demonstrate implementation decisions, identify limitations, and improve the quality of a real application.