Austin Eischeid — Authority Platform & Editorial System

10 min read

Overview

This project was not a traditional portfolio build. It was delivered as a full system redesign — content model, frontend architecture, and editorial workflow — not just a visual refresh.

The objective was to design and engineer a digital authority platform for a planting designer operating at a high level of landscape architecture — someone collaborating with institutions, public gardens, and internationally recognized designers.

Most portfolio sites present images. This needed to present credibility, thinking, and proof.

The result is a system that functions as:

• a case study archive
• a botanical knowledge base
• a press and recognition layer
• an event and speaking platform
• and a structured data-backed entity on the web

All built on a modern, performance-first stack with a strong emphasis on editorial control, accessibility, and long-term scalability.

Problem

Austin's existing web presence — like most in the field — suffered from a common set of issues:

• Work was presented as image galleries, not as documented case studies
• There was no clear authority signal despite high-level collaborations
• Press, events, and projects existed, but were not connected into a coherent narrative
• There was no structured representation of Austin as a recognizable entity on the web
• The site did not support how landscape architecture is actually evaluated: longevity, seasonal performance, planting strategy, collaboration context

Approach

The approach shifted the project from a "website build" to a system design problem.

Instead of asking "how should this look?" the guiding question became: "How does a serious design practice establish authority, credibility, and trust digitally?"

From that, several principles were defined:

1. Case studies over galleries

Every project needed to function as a narrative: context, approach, planting strategy, outcome over time.

2. Authority must be visible immediately

Institutional work, collaborations, and press needed to be surfaced clearly and early.

3. Content must be interconnected

Projects, press, events, and plants should reinforce each other — not exist as isolated pages.

4. Editorial control over hardcoding

The system needed to allow Austin and his team to evolve the site over time without engineering bottlenecks.

5. Restraint over spectacle

No unnecessary animation, no visual noise, no trend-driven UI decisions. The work should carry the weight.

Architecture

The platform is a static-first Next.js application backed by Sanity as the structured content layer. Pages are statically generated at build time, served from Vercel's edge, and hydrated only where interactivity is required.

Stack

• Next.js (App Router) for rendering, routing, and performance
• Sanity CMS for structured content and editorial workflows
• TypeScript + Zod for type safety and runtime validation
• Next/Image for responsive, optimized media delivery
• Server Components for security and reduced client overhead

Content Model

The system is driven by structured content types:

• Projects — case studies
• Plants — knowledge base
• Press — editorial validation
• Events — talks and visibility
• Collaborators — authority and network
• Global pages — About, Process, Homepage

This allows the site to behave less like a static portfolio and more like a living editorial system.

Performance Strategy

• Images delivered via Next/Image with responsive sizing, automatic format negotiation (AVIF/WebP), and lazy loading. Source images live in Sanity's CDN and are resolved through the Next image optimizer at request time.
• Minimal JavaScript on the client — content pages ship zero application JS beyond what React Server Components require for hydration of small interactive islands.
• Motion is driven by CSS transitions only — no animation libraries — with prefers-reduced-motion fully respected.
• Fonts are self-hosted as variable WOFF2 with display: swap and explicit preload, eliminating third-party CDN dependencies and font-loading layout shift.

SEO & Entity Layer

A key part of the architecture is structured data:

• A canonical Person entity representing Austin
• Connected CreativeWork, NewsArticle, and Event schemas
• Sitemap and crawler governance strategy
• Clean metadata and indexing control

This allows search engines to understand not just pages, but relationships.

Engineering Challenges

Several parts of this build required real thought, not just configuration.

Modeling content relationships at the right level of abstraction

The system supports a rich internal graph: projects connect to plants, plants connect to other projects, collaborators connect to events, press connects to projects. Building the graph wasn't the hard part. The hard part was deciding which relationships to surface as public features versus which to keep as internal editorial structure. A site that exposes every database relationship turns into a reference manual and the work disappears under the structure. The discipline was to build the full graph for editorial workflows and curate which subsets become visible features — treating the public site as a deliberately edited view of the content, not a 1:1 projection of the schema.

Balancing editorial flexibility with schema constraints

Sanity makes it easy to give editors complete freedom. That freedom is exactly what causes most CMS-driven sites to drift into inconsistency over time. The schemas were intentionally constrained — every content type validates against a strict shape, with required fields where structure matters and optional fields only where genuine flexibility is needed. Editorial flexibility lives inside the constraints, not around them.

Handling large image payloads

Landscape and planting work is image-heavy. The naive approach — load the original photographs — produces multi-megabyte hero images that destroy mobile performance. Every image flows through Next/Image with explicit dimensions, modern format selection, and aggressive lazy loading. Hero images use priority loading; everything below the fold defers until needed. The result is a content-rich, image-heavy site that still hits mobile LCP under 2 seconds.

Aligning designer intent with system constraints

This is the work that doesn't show up in any code commit. Translating Austin's design instincts into a system that holds together over time meant constant negotiation between what looks right in a single comp and what scales across dozens of projects, pages, and content types. The discipline was to build the system so that the right defaults produce good outcomes, and the wrong choices are difficult to make accidentally.

Decisions & Tradeoffs

This project involved several non-obvious decisions that materially shaped the outcome.

1. Internal richness, public clarity

The system models a rich content graph. Projects, plants, collaborators, press, events — all connected internally and used by Austin and his team for editorial workflows. The public site does not expose every one of those connections as a navigable feature.

Reason: The site's job is to communicate the work, not to be a database. Surfacing every internal relationship would shift visitor attention from "what did this designer build" to "what's in this database." The work would disappear under the structure.

Tradeoff: Less surface area for internal linking and tag-style navigation, in exchange for clarity and focus on the work itself. The internal structure remains available without constraining the visitor's experience.

This is editorial discipline applied to data architecture: build the right thing, then edit what becomes visible.

2. No image "protection" tactics

Common approaches like watermarks, right-click blocking, and overlays were explicitly rejected.

Reason: They degrade user experience, signal insecurity, and are easily bypassed.

Instead, the system relies on controlled image resolution, optimized delivery, and strong attribution and context — authority through provenance.

Tradeoff: Images can still be saved, but the experience remains clean and professional.

3. Allow discovery, block training

Crawler strategy was carefully defined: allow search engines and AI search tools (discovery) while blocking AI training crawlers where possible.

Reason: The site is meant to be found, cited, and explored — but not silently absorbed into training datasets.

Tradeoff: Slightly more complexity in crawler governance in exchange for better control over how content is used.

4. Restraint over visual complexity

No animation libraries. No heavy transitions. No unnecessary UI patterns.

Reason: In this domain, excessive motion undermines credibility.

Tradeoff: Less "flash," more clarity, focus, and longevity.

5. Editorial system over static build

The system was designed so content could evolve: new projects, additional press, future events, expanded plant database.

Tradeoff: More upfront complexity in exchange for long-term flexibility and independence.

Outcome

The final result is not just a website — it is a platform for professional positioning.

The system supports:

• Deep, narrative-driven case studies
• Clear authority signals through press and collaborations
• A botanical knowledge layer reinforcing expertise
• Event and speaking visibility
• A structured, interconnected content graph
• A high-performance, accessible user experience

Concrete results from the production audit pass:

• Lighthouse Accessibility: 100/100 across all eight page types, verified against WCAG 2.1 AA. Zero critical blockers, full keyboard navigation, contrast ratios meeting AAA on primary text.
• Lighthouse Best Practices & SEO: 100/100 across all pages. Full structured data coverage (Organization, Person, CreativeWork, BreadcrumbList) and a 30-entry sitemap.
• Cumulative Layout Shift: 0 on every page. Achieved by migrating to next/font with size-adjusted fallback metrics, eliminating font-swap shift.
• Total Blocking Time: 20–150ms across all pages — well under the 200ms target.
• SecurityHeaders.com: Grade A with HSTS preload, scoped CSP (default-src 'self'), Referrer-Policy, Permissions-Policy, and frame-ancestors for Sanity Studio embedding.
• 28/28 legacy URL redirects preserving SEO equity from the previous site, all permanent (HTTP 308).

Performance is the most nuanced number. On desktop, FCP is 0.5s and LCP is 1.2s. On simulated Slow 4G mobile, LCP runs 3.1s on text-dominant pages and up to 6.1s on the most image-heavy project pages. This is a deliberate tradeoff: the site is a visual portfolio where the work is the product, and degrading image quality to optimize a synthetic mobile metric would harm the brand more than it helps. Every optimization that doesn't compromise the photography is in place — Next/Image with format negotiation, priority on heroes, lazy loading below the fold, LQIP blur placeholders, Sanity CDN delivery, self-hosted fonts.

More importantly, the site now positions Austin not as a designer with projects, but as a practitioner with a documented body of work.

This is not a portfolio. This is a practice.

Reflection

The most important lesson from this project is that most websites fail at the wrong layer.

They optimize visuals, layout, and animations — but ignore authority, structure, narrative, and trust.

This project succeeded because it treated the website as a system of meaning, not just a presentation layer. It closely reflects the principles outlined in How I Build — architecture-first thinking, deliberate restraint, and engineering decisions made in service of a product outcome.

From a technical standpoint, the build is clean, performant, and scalable. From a product standpoint, it does something more important: it makes the work understandable.

And in a field where the difference between good and exceptional is often invisible to non-experts, that is where the real value lies.