LemeSherry Portfolio and Blog

Two sites, one codebase

lemesherry.com is my portfolio, and blog.lemesherry.com is my game development blog. Both are built from one monorepo, with one shared design system, one set of components and one command that builds and deploys them. The same codebase also holds a studio site that is still to come.

The stack is plain on purpose: React 19, Vite 8 and React Router 7, with vanilla CSS custom properties as the design tokens. There is no TypeScript, no Tailwind and no CSS-in-JS. The shared package is used as raw source through npm workspaces, so it needs no build step of its own.

3D that steps down on its own

The site treats the device the way a game treats graphics settings. On load it checks for a real graphics card, reads the CPU cores, memory, data-saver mode and screen size, and picks one of four profiles. A strong desktop gets the WebGL loading crystal, the particle field and a 3D object beside each section. A phone gets the same scene, lighter. A device without a GPU gets CSS versions with no WebGL at all, and the lowest profile keeps everything still.

The rule is that the site must work with hardware acceleration switched off, and my test scripts run it with the GPU disabled and the CPU slowed four times. Three.js, GSAP, Lenis and Firebase all load after the first paint, never on the entry path. The 3D scene reads the same colour tokens as the page, so it changes colour with the theme.

Pages that any crawler can read

The sites are single-page React apps on plain Apache hosting. After every build, a headless browser renders each route and saves it as real HTML. Then the build checks that HTML and stops if something is missing. The home page must carry its full text as plain HTML, with every project, career chapter and skill. The résumé page must name every role. No page may point to a local development address.

The résumé page, its PDF in light and dark, and its social card are all generated from one data file, so they always agree. Unknown addresses return a real 404 with a branded page, and branded short links are server-side redirects made from one JSON file.

A blog with accounts and threaded comments

Posts are Markdown files compiled at build time, so no Markdown parser ships to the browser. Each post is its own JavaScript chunk, the index carries only titles and dates, and an RSS feed carries the full articles. A reading rail shows which section you are in.

Readers can like and comment in threads without an account. They can also sign in with Google or an email link, and signing in upgrades the anonymous account in place, so earlier likes and comments stay theirs. The author role is set in the console, and no client can write it. Firebase App Check keeps bots out, and Firebase loads only at idle or when the comments come near the screen, never in the prerendered HTML.

Analytics only after a yes

Google Analytics loads only after a visitor agrees in the cookie banner. One consent cookie covers every subdomain, and it carries a version, so a new cookie category asks everyone again. If a visitor says no, nothing loads and any old analytics cookies are removed.

How it ships, and what I built

One command builds every site, copies the output into a production branch and pushes it, and the host pulls it from there. The source never reaches that branch. Every generated file is deterministic, with no build timestamps, so a deploy with no real change does nothing.

I designed and built all of it, and every commit in the repository is mine. Before each larger change I build a prototype, measure it with a test script, and only then move it into the real site.