Carter Steinhoff

An independent studio site built to the standard of the work inside it.

Live site

Carter Steinhoff homepage hero with the name set large in a serif display face over a photograph of a desk at night

Year: 2026
Role: Design, development & writing
Stack: Next.js 16 · React 19 · TypeScript 7 · Tailwind CSS 4 · Biome · Playwright · Vercel
Status: Live and in production

Selected views

The work, before the process.

Two representative views establish the range before the case study moves into the decisions behind them.

Portfolio index showing project cards in browser chrome, each with a screenshot, title, platform, year, and one line of summary — The work gallery
Each project sits in browser chrome with its real domain, then links into a case study with a separate path to the live site.

Services page with an oversized statement heading and a rule-topped summary column — Services
What I actually do, stated without the padding that usually surrounds it.

Project story

A portfolio that exposes both the work and the decisions behind it.

The site has to present a broad practice across product design, full-stack development, automation, and cloud work without reading like a résumé or hiding behind surface polish. I built an editorial system where each case pairs the finished interface with its constraints and reasoning.

The design challenge is credibility: keep the identity unmistakable, let current screenshots lead, and make a sparse visual language support the evidence instead of competing with it.

Proof

The portfolio itself is part of the evidence.

Prospective clients experience the typography, pacing, imagery, accessibility, and performance as evidence of the same skills the case studies describe. The site therefore has to act as proof, not merely as a wrapper around it.

Range

Different kinds of work still need one point of view.

The projects differ in audience, operating model, and technical depth. One editorial structure had to make those differences legible without giving every project a different template or reducing all of them to thumbnails.

Editorial system

Give every case the same evidence hierarchy.

A shared case structure lets readers compare context, constraints, decisions, architecture, and screens across very different projects. That consistency makes the work easier to judge without erasing what makes each project distinct.

Decisions

The type scale is tokens, not conventions

Heading size, line height, and tracking are Tailwind theme tokens exposed to both utilities and CSS Modules. Components choose a rank instead of inventing one.

One request-time endpoint

Every page prerenders; contact is the only request-time endpoint. That keeps the production surface small while preserving a real way to get in touch.

Tests assert on structure, not on screenshots

Playwright checks document hierarchy, links, image priority, reduced motion, project ordering, and overflow. Those contracts catch drift without coupling tests to pixels.

The case studies say why, or say nothing

Screenshots show what a thing does; prose explains why it is built that way. The Decisions section is optional because a plausible rationale reconstructed after the fact is worth less than an honest gap.

The build

A static-first studio stack with one live endpoint.

Next.js and React generate the editorial site, Tailwind and shared tokens hold the visual system together, and Vercel runs the contact boundary without adding a database or CMS.

What I owned

01
Product direction, editorial writing, and the full responsive visual system
02
Data-driven App Router case studies and static route generation
03
A shared fluid type scale as Tailwind v4 theme tokens, consumed by utilities and CSS Modules alike
04
Build-time social cards, structured data, and production browser checks across desktop and mobile

Technology roles

Experience

Next.jsApp Router pages, metadata, and static case-study routes
ReactServer-first component model with four interactive boundaries
TypeScriptTyped project data and route contracts
Tailwind CSSFluid type tokens and responsive layout utilities

Delivery

VercelStatic pages, image optimization, and contact function
ResendServer-only contact delivery

System architecture

A build-time site with one moving part.

The pages, the social cards, and the type scale are all resolved before a visitor arrives. The only thing that runs on request is the contact form, and the only thing that runs in their browser is the handful of components that genuinely need state.

Experience
Next.js 16 App Router and React 19 Server Components, with four client components
Design system
Tailwind CSS v4 theme tokens for a fluid type scale, with CSS Modules per route
Build output
Static prerendering for every route plus build-time OpenGraph cards
Quality gates
TypeScript 7, Biome, and Playwright checks on desktop and mobile

Selected screens

The system, seen in practice.

Readable views of the site and the system behind it.

Decisions
The section this whole site exists to carry: the reasoning behind a build, in two columns of real paragraphs rather than a bulleted feature list.
About
The career story as dated chapters, from a COBOL internship on a mainframe to an independent studio in Phoenix.
Contact
A focused project brief keeps the site’s only request-time feature direct and useful.