Solo — Strategy, Design, Engineering, Deployment

I built this. All of it.

This case study is not about a website. It's about what happens when a design leader removes the walls between disciplines and runs the whole product lifecycle himself. The website is evidence. The process is the point.

RoleSolo — Strategy, Design, Engineering, Deployment
Timeline~3 weeks, content strategy → live CMS
StackNext.js 15, TypeScript, GitHub API, Vercel
Repogithub.com/codye91/cody-eanes-portfolio
Git Repohttps://github.com/codye91/cody-eanes-portfolio

The Brief

A portfolio that was contradicting itself

Most designers outsource everything outside of design. This project was about closing those gaps.

The real brief

The surface problem: I needed a portfolio. The deeper problem: a static Squarespace site was actively contradicting the claim that I think in systems and ship things.

Every update required cloning a repo and manually editing code. For a site that needed to evolve as fast as a job search, that friction was a liability.

So this became two briefs. Build a portfolio that proves systems thinking. Then — post-launch — build the tools to keep it current without engineering overhead.

Phase 1

Content strategy before design

Before a single pixel, a content audit. Most designers skip this step. It's a discipline problem, not a tool problem.

The Audit

  • Scraped every page of the existing site
  • Catalogued every headline, tagline, and description
  • Tagged each line: validates the past, or claims the future?

The Filter

  • One question: does this reflect a CD candidate?
  • Everything that answered no got cut
  • What remained was rewritten to close the gap

The Output

  • A structured markdown brief
  • Single source of truth for design, engineering, and copy
  • Every subsequent decision traced back to it

Phase 2

Design system before site

Tokens first, components second. One-sentence brief: near-black, amber-accented, editorial — typographically bold where it counts, sparse everywhere else.

Color

  • Near-black (#0D0D0D) primary surface
  • Amber accent — 3–4 touches per viewport max
  • Warm authority, not loudness

Typography

  • Roboto for display weight
  • DM Sans for body — readable and distinctive
  • Fluid scale via CSS clamp() — no breakpoint hacks

Tokens

  • All spacing as CSS custom properties
  • Background variants: default, surface, surface-alt
  • System defined before pages, not extracted from them

Reference + Divergence

  • Referenced editorial and design-forward portfolios
  • Diverged: less decoration, more typographic weight
  • Everything ornamental was a question, not a default

Phase 3 — v1.0.0

Engineering & first launch

First launch shipped May 20. The design didn't stop at Figma — it went all the way to production.

This is where AI's role becomes explicit. Accelerant, not author. Every architectural decision was made by a human who understood the tradeoffs.

Stack

  • Next.js 15 App Router
  • TypeScript
  • Custom CSS — full token control
  • Static generation via generateStaticParams

Deployment

  • Vercel — auto-deploy on push to main
  • Zero manual steps after initial config
  • Custom domain, SSL, edge CDN

AI's Role

  • Accelerant, not author
  • Architectural decisions made by a human
  • AI removed the parts that don't require judgment

Post-Launch

The second brief

The Friction

Every update required a commit

Adding a project meant editing JSON files, running a local build, and pushing a commit. For a site evolving as fast as a job search, that's unacceptable.

The Decision

Build custom over adopt headless

Sanity and Contentful solve the right problem — but add dependency, cost, and abstraction. This was solvable in-house. Building it was itself a proof point.

The Scope

Password-protected /admin with full CRUD

JWT auth, protected routes, project editor with visual section builder, site content editor. One surface, no external services, no ongoing cost.

The Build Arc

Four versions. One direction.

Each version solved a specific problem. The direction never changed — only what was possible.

v1.0.0

Design + Launch

Content strategy, design system, full-stack build. Live on Vercel in ~2 weeks.

v1.1.0

Core CMS

JWT auth, project editor, site content editor. No code required to update the portfolio.

v1.2.0

Section Builder

13 section components. Visual card-based editor. Case study page: 800 lines → 110.

v1.3.0

Production Persistence

GitHub API writes. Every save commits to the repo. Vercel rebuilds automatically.

The CMS

The /admin interface handles the full content lifecycle without touching code.

Projects, sections, and site content are all editable from a single password-protected dashboard. Every save commits directly to the repo — no terminal, no deploy command, no engineering overhead.

The /admin CMS dashboard — project list and visual section editor

What shipped

By the numbers

800→110Lines on the case study page
13Reusable section components
3 wksBrief to live CMS
  • Visual section builder — no schema knowledge required to author content
  • All case study content editable from /admin without touching code or a terminal
  • Every content save is a traceable, reversible git commit

Phase 6 — v1.3.0

Solving the production persistence problem

Vercel’s serverless runtime has a read-only filesystem. The right fix depended on which tradeoffs were worth accepting.

The Constraint

  • Vercel serverless functions can’t write to the filesystem
  • Every CMS save was silently failing with EROFS in production
  • Surfaced only after adding proper error handling to API routes

Options Considered

  • Vercel KV: instant writes, but external dependency and no git history
  • GitHub API: 1–2 min rebuild, no external service, every save is a commit
  • Filesystem fallback: fine locally, not viable on Vercel

The Decision

  • GitHub Contents API — chosen for simplicity and auditability
  • Fetch file SHA → commit updated JSON → Vercel detects push and rebuilds
  • No database. No ongoing cost. Every change is traceable and reversible.

The Mechanism

  • lib/github.ts — 50 lines, no abstraction layers
  • Entire write path is transparent with no silent failure points
  • Identical behavior locally (filesystem) and in production (GitHub API)

Reflection

Running the whole lifecycle myself is what lets me teach it. You can't turn a handoff into a repeatable pattern for your team until you've stood on both ends of it.

You understand the real cost of a late design change. You know which engineering decisions are genuinely constrained and which are just habit. You write better briefs because you've been on the other end of bad ones. This project was built with Claude as a collaborator throughout — content strategy, design direction, every line of code. The judgment calls — what to cut, what to build, what tradeoff to make — were human. AI accelerated every phase by removing the parts that don't require judgment. That's the integration model, not the replacement model. The walls between disciplines are expensive. This project is proof that they're also optional.

Next Case Study