Building my own studio, end to end.

If I build websites for others, mine can't be the orphan.

A&C Meridian launched from zero. No template to start from, no leftover scaffolding to lean on. The studio's own site had to land at the same standard I'd hold a client build to, day one.

And because I'd be publishing case studies and shipping copy changes weekly, the project split naturally into two parts: the public marketing site, and the internal admin panel that powers it.

Built to the studio's own standard.

The site is designed in the studio's visual language: large serif italic display type, generous whitespace, a quiet grid, and a single hero motion piece that reveals the studio mark as a kinetic composition. Restrained on the outside, custom everything underneath.

• Type-driven editorial layout system, mobile-first
• Bespoke hero animation written from scratch. No third-party library
• Server-rendered for SEO, then progressively enhanced on the client
• Image pipeline with on-the-fly resizing & lazy loading

An entire studio operating system, written from scratch.

Most studios log into WordPress and call it done. I wanted a control surface that fit how I actually run the studio: a place to publish, to track prospects, to audit client sites, and to do it all without leaving the brand. The marketing site's editorial type system carries straight into the admin: Fraunces italic display, mono labels, paper background, restrained motion. Logging in feels like the same studio.

Sign in with a magic link. Inside, fifteen admin pages cover every content type on the site (journal, glossary, FAQs, services, tiers, partners, ticker copy) and every operations surface the studio actually uses. A built-in audit pipeline dispatches a headless Chromium scan against any prospect or client site and surfaces severity-graded findings inside the same dashboard. Prospects, audit reports, sales briefs, all of it sits on the same Cloudflare stack as the public site.

• Magic-link sign-in. 32-byte random tokens, SHA-256 hashed at rest, single-use, 15-minute expiry
• Three-role permission matrix (Admin · Editor · Viewer), enforced server-side on every CRUD endpoint
• Drag-drop image uploads straight to R2, attributed to the editor on file
• Live markdown preview, auto-slug from title, scheduled publishing on a cron tick
• Dynamic OG image generation per post via workers-og (Satori + resvg)
• Built-in audit pipeline: headless Chromium on a separate Worker, results stored in R2, surfaced as a severity-classified report in the admin
• Prospect CRM with effort estimates and owner attribution (developer / sales / SEO) per finding
• Editorial visual system carried into the internal tool, not just the public site

What I picked, and what I didn't.

1. 01

   Build the studio's operating system. Don't stitch one together from SaaS.

   The admin is a 15-page custom CMS with role-based permissions, drag-drop image uploads to R2, scheduled publishing, dynamic OG image generation, a built-in audit pipeline that dispatches headless Chromium against client sites, and a prospect CRM with severity-classified findings. Eight thousand lines of admin code, written without a framework. Total runtime dependencies in package.json: one (workers-og, for the OG cards).

   Considered: Notion + Sanity + a separate uptime SaaS (four bills instead of one), WordPress with plugins, a React admin SPA

2. 02

   Split runtime. Pages Functions for the CMS, a separate Worker for site audits.

   The audit pipeline opens a headless Chromium session and renders client sites. Pages Functions cap at 50ms CPU per request and can't bind the BROWSER service. A second Worker handles that workload on a daily cron and shares the same D1 + R2 by account-level binding. Two runtimes, one data layer, each tuned to its actual constraint.

   Considered: One Pages Functions deploy doing everything, a third-party uptime/perf SaaS

3. 03

   Magic-link auth. No passwords ever.

   Studio admin is a two-person allow-list. Magic-link gives 32-byte random tokens, SHA-256 hashed in D1, 15-minute expiry, single-use, then a __Host- prefixed cookie. A database leak does not expose live sessions. No password reset flow to build. No "which OAuth provider did I use last time?" tax.

   Considered: Password auth + bcrypt, OAuth (Google / Apple), Clerk

React would have shipped 45KB of runtime to do a 12KB job.

The default question from another developer reading this is: "wait, no React?" Fair question. React earns its weight when many components are reused across many surfaces, when state flows reactively between unrelated views, or when a large library ecosystem (shadcn, react-query, react-hook-form) is part of the build. None of those applied here.

The admin is fifteen single-purpose pages. Each one loads a list, clicks a row, edits a form, posts JSON. That's a request/response loop, not a state graph. The browser already does that natively. fetch() and document.getElementById() are the entire React substitute.

• ~45KB gzipped React runtime never shipped to a single visitor
• No build step, no JSX transpiler, no bundler config to maintain
• LCP holds in the 200–400ms range on cold visits
• One runtime dependency in package.json. One.

Adding a framework to translate fetch + DOM into JSX so the same logic can be written in a different syntax is the kind of decision that ships a 2MB bundle to do a 12KB job. I matched the tool to the job. The job didn't need a framework, so I didn't ship one.

The studio publishes weekly. The site keeps up.

A&C Meridian now has a marketing site that reads like work the studio would ship for any client, and an admin that lets me publish without leaving the brand. No developer in the loop on my own studio's website, no third-party CMS bill, no template fighting the brand.

The studio site is no longer the orphan. It's the first piece of work prospects see, and it stands up next to everything else in the portfolio.