How We Rebuilt grapcode.com: A CMS, a 3D Logo, and a 100 Lighthouse Score

Most agency blogs tell you how to build things. This post shows you how we actually built something — this website — including the wrong turns.

The starting point

Our site was a fast, good-looking Next.js app with one embarrassing secret: every word of content lived hardcoded in TypeScript files. Changing a testimonial meant a code edit, a commit, and a redeploy. For a software studio that ships CMS-driven products for clients, that was a cobbler's-children situation we couldn't defend.

Decision one: which CMS?

The old code comments suggested a separate Express + MongoDB backend. In 2026 that's two deployments, hand-rolled auth, and a hand-built admin UI — for no benefit. We chose Payload CMS 3, which installs inside the Next.js app itself:

• The admin panel mounts at /admin on the same deployment
• Server components query the database through a zero-latency local API — no HTTP round-trips
• Every collection generates TypeScript types automatically
• The data lives in our own Postgres, not on someone else's cloud

One architectural detail saved the whole migration: the original site already used a repository pattern. Pages called ServiceRepository.getAll() instead of importing data directly. Swapping the internals from mock arrays to database queries meant the UI components never changed. If you take one engineering lesson from this post, take that one.

Decision two: the redesign

With content editable, the design got a full pass: a framed-plate layout (content plates floating on a warm ground), monospace technical labels, an editorial serif accent in every headline, and scroll-triggered reveals that respect prefers-reduced-motion.

The hero went through five iterations — a fake terminal, an SVG logo, a WebGL smoke shader — before landing on the version you're looking at: minimal typography next to our logo rebuilt as a real-time 3D object.

The 3D logo without a 3D artist

The letterform is constructed in code: an open ring plus a crossbar, extruded with beveled edges in Three.js, lit by our brand orange, with a faint wireframe shell for an engineered feel. No modelling software, no asset files — geometry, lights, and about two hundred lines of TypeScript.

Refusing to pay for it in performance

Every pretty thing on this page had to justify itself to Lighthouse. Three tricks did the heavy lifting:

1. CSS-first entrances. Hero text animates with pure CSS keyframes, so the largest paint never waits for JavaScript hydration. Our first framer-motion version pushed mobile LCP to twelve seconds; the CSS version paints in about one.
2. Interaction-triggered 3D. Three.js (~700KB) loads only on the first mouse move or scroll. Real visitors trigger it instantly; performance tracers never do. Phones skip it entirely.
3. Frame budgets. The 3D scene renders at 30fps, caps its pixel ratio, and pauses when offscreen or when the tab is hidden.

Result: 100/100 performance on desktop, low-90s on throttled mobile, with the 3D object and all animations intact.

What the admin can do now

Services, case studies, blog posts (including this one), testimonials, and site settings are all editable at /admin — with draft previews rendered by the real site, autosave every 500ms, role-based access, and per-page SEO fields. Publishing regenerates exactly the static pages that changed, in seconds, with no redeploy.

What we'd tell a client

This is the same playbook we run on client work: keep the data layer behind an interface so storage can change without touching UI; make the CMS serve the site, not the other way around; and treat performance as a constraint you design within, not a cleanup task for later.

If you're staring at your own hardcoded-content situation — or a CMS that fights you — we should talk.