A production-oriented portfolio, technical blog, contact service, and calendar booking system in one typed React application.
Turned this portfolio into a working product with case studies, publishing, contact, and booking workflows.
9+
public experiences
Portfolio, blog, booking, contact, legal, and content routes ship as direct URLs.
4
server workflows
Availability, booking, management, and contact APIs support real user actions.
5+
security controls
Validation, Turnstile, rate limits, headers, and idempotency protect the public surface.
01 / Project evidence
Original illustration
Portfolio platform identity visual
A custom social-preview graphic for the site, not a browser screenshot.
02 / System design
A prerendered React frontend shares route and content models with the build pipeline, while Vercel functions connect validated browser actions to external services and durable storage.
The same route and content models feed prerendering and the browser application.
React 19 + TypeScript
Page modules, project data, Markdown posts, and route metadata.
Vite + prerender scripts
Generates route HTML, feeds, sitemap, and metadata.
Vercel
Delivers prerendered pages and client assets with security headers.
History routing + lazy pages
Hydrates the selected route and loads page modules as needed.
Availability and booking actions pass through server functions before changing calendar or stored booking state.
React calendar
Shows available dates, time slots, and the visitor’s timezone.
Vercel functions
Validates payloads, Turnstile tokens, rate limits, and duplicate requests.
Browser → server trust boundaryGoogle Calendar API
Checks availability and creates or updates the event.
External calendar providerDurable store
Persists status and a protected self-service management token.
Email + Meet / calendar links
Returns the meeting and calendar details to the visitor.
The contact endpoint validates and protects submissions before triggering email delivery.
React client
Collects name, email, and message.
Vercel function
Checks origin, input shape, and field limits.
Browser → server trust boundaryTurnstile + rate limit
Rejects automated or excessive submissions.
Resend
Sends the validated message using server-only credentials.
External email providerArrows show the main request or data handoff. Boundary labels mark local-only processing, browser-to-server transitions, or external services.
03 / Engineering decisions
Decision 01
Choice: Generate HTML for public routes while keeping interactive booking and contact workflows in server functions.
Trade-off: Direct links and page metadata are available immediately, while interactive state still requires the browser bundle.
Decision 02
Choice: Keep availability, booking, management, and contact as distinct server-side operations.
Trade-off: The boundaries make validation and permissions clearer, but external calendar and email services remain dependencies.
Evidence
Public platform review snapshot. Credentials, booking tokens, provider responses, and personal submissions are excluded.
SYSTEM: production portfolio platform
CONTROL: secrets and booking tokens remain server-side
OUTPUT: route HTML, feeds, metadata, and protected workflows generatedRoute, workflow, and control counts describe the current application and source. No booking-conversion or visitor-growth metric is claimed.
05 / Verification
Designed the site as a working product surface rather than a collection of resume sections, with direct routes for every meaningful experience.
Validated form input server-side and added origin checks, Turnstile, rate limits, idempotency, and hashed booking management tokens.
Used typed tests, production builds, prerendered output, sitemap generation, and SEO assertions to check both behavior and discoverability.
06 / Ownership
This section separates my direct contribution from broader project outcomes.
