ARTDANTECH
Post-mortemStudio siteLet's Talk

Artdantech

A post-mortem on building our own studio site — the constraints we imposed, the trade-offs we made, and what we'd do differently. The site you're reading is the case study.

Overview

Most agencies can't afford to use their own website as proof of work — because it wouldn't survive the scrutiny they ask clients to pay for. We took the opposite bet: ship our own site under the exact same constraints we sell, and let prospects audit it in real time. This is the post-mortem of that decision — what we built, what we cut, and what we'd do differently if we started over tomorrow.

The bet

Treat our own site as the most demanding client engagement we'd ever run — and publish the post-mortem as the first case study.

The hard part

No client brief means no constraints. No external deadline means no forcing function. Self-directed projects die from optionality, not from difficulty.

The standard

Every promise we make on our service pages — speed, clarity, SEO, accessibility, editorial control — had to be verifiable on the site making the promise.

The outcome

A site that holds up under technical audit, ranks on its own positioning queries, and qualifies prospects before the first call.

Here's the uncomfortable truth: if you can't trust what you're reading right now — the load time, the typography, the way this paragraph breaks on your screen — there is no reason to trust us with your own project. This site is the interview.

Constraints we imposed on ourselves

Self-directed projects fail because nothing is forbidden. We started by writing down what we were not allowed to do — the constraints that would force every decision to mean something.

  • No template, no theme, no starter kit. Every component written from scratch, or it doesn't ship.
  • Sub-second LCP on 4G mobile. Not "fast enough." Measurably under one second on a throttled connection, or the page gets rebuilt.
  • Zero client-side JavaScript on content pages. Case studies and service pages render as static HTML. Interactivity is opt-in, never default.
  • Lighthouse 100/100/100/100, or we don't ship the page. Performance, accessibility, best practices, SEO. No exceptions, no "we'll fix it later."
  • Every word written before the design. If the copy doesn't survive in plain text, it doesn't deserve a layout.
  • Editable in MDX by a non-developer. If publishing a new case study requires touching a .tsx file, the architecture has failed.

These weren't aspirations. They were the pass/fail criteria.

The technical trade-offs

Why Next.js with Server Components, not a static site generator

We considered Astro and Eleventy. Both would have shipped less JavaScript by default. We chose Next.js App Router because Server Components let us render case studies as pure HTML while keeping a single mental model for the rare interactive elements (contact form, filters). The cost: a heavier framework. The benefit: one codebase, one deployment pipeline, one set of conventions.

ISR over full SSG

Pure static generation would have been marginally faster at build time. We chose Incremental Static Regeneration so case studies can be updated without redeploying the entire site. On a portfolio that ships new work every month, build time compounds.

Edge Runtime for the contact endpoint

The contact form runs on Vercel's Edge Runtime, not a Node serverless function. Cold start under 50ms, geographically distributed, no container spin-up. For a form that fires twice a day, this is overkill — and that's the point. The infrastructure is the proof.

LCP optimization: the part nobody talks about

The hero image on every case study is the LCP element. We preload it via <link rel="preload"> with fetchpriority="high", serve it as AVIF with WebP fallback, size it via next/image with explicit dimensions to prevent CLS, and inline the critical CSS for the first viewport. Result: LCP under 800ms on simulated 4G across every case study page.

Key results

Sub-second LCP, every page

Largest Contentful Paint under 1s on throttled 4G across the entire site. Verifiable in any Lighthouse run.

Zero render-blocking JS on content

Case studies and service pages ship as static HTML. The browser parses, paints, and the user reads — no hydration tax.

Prospects who self-qualify

The copy is calibrated to filter, not to seduce. Inbound leads arrive pre-aligned on scope, budget and standard.

A publishing system that scales

New case studies ship as MDX files. No CMS, no admin panel, no migration risk. Git is the editorial workflow.

What we'd do differently

No project ships without scars. Here's what we'd revisit if we restarted from scratch — the kind of honesty most agencies edit out of their case studies.

  • We over-engineered the MDX component library. We built ten custom components when four would have carried the entire site. The remaining six exist because we wanted them to exist, not because the content demanded them. Lesson: build components against real content, not in anticipation of it.
  • We delayed analytics too long. We launched without instrumentation because we wanted "privacy-first by default." Three months in, we had no idea which case studies prospects actually read. We'd ship Plausible from day one now.
  • We wrote the French version first. Translating to English produced a version that was technically correct but tonally borrowed. The version you're reading was rewritten from scratch in English — and it's the one that converts. Lesson: for international positioning, write in the target language first.
  • The contact form is too easy. Three fields, no qualification questions. We get well-fit inquiries, but also tire-kickers we could have filtered earlier. Next iteration: a structured intake that respects the prospect's time and ours.

Tech stack

  • Next.js 15 (App Router, Server Components, ISR)
  • React 19
  • MDX with custom component layer
  • Tailwind CSS (no UI library)
  • AVIF/WebP image pipeline via next/image
  • Edge Runtime for the contact endpoint
  • Plausible Analytics (cookieless)
  • Vercel (CI/CD, Edge Network)
  • Lighthouse CI in the deployment pipeline

The bar

You've spent the last few minutes auditing our work without realizing it. The load time, the type, the way the page held together as you scrolled — every detail was a silent argument. If the standard you've just experienced is the one you want for your own project, the next step is a 30-minute working session where we figure out, honestly, whether we're a fit. If we're not, we'll tell you in the call. Straight answers only.

If this is the bar you want for your own project — let's see if we're a fit.