Design-First Is the Default. It Shouldn’t Be.

The standard workflow for a web project looks like this: a designer creates mockups, the client approves them, and then developers figure out how to build what was designed. Technology choices happen late, driven by what the design requires rather than what the project actually needs.

This approach optimizes for the wrong thing. It optimizes for early visual approval at the cost of late technical surprises. The mockup looks perfect in Figma, but the carousel requires a 150KB JavaScript library, the layout needs a CSS framework, the custom animations need a runtime, and the dynamic content requires a server-side rendering setup that triples the infrastructure complexity.

Architecture-first inverts this. It starts with the structural decisions — what technology, what hosting, what content model, what performance constraints — and then designs within those constraints. The design is no less creative or beautiful; it’s simply informed by reality from the beginning.

What Architecture Decisions Actually Are

Architecture decisions aren’t about choosing between React and Vue. They’re about defining the structural constraints that every subsequent decision must respect. The key decisions for a web project are:

Rendering Strategy

How and when is HTML generated?

  • Static generation: HTML is built once at build time. Best for content that changes infrequently. Fastest delivery, simplest infrastructure.
  • Server-side rendering: HTML is generated per request on the server. Necessary when content depends on the request (user authentication, real-time data).
  • Client-side rendering: HTML is generated in the browser via JavaScript. Appropriate for highly interactive applications, poor for content-focused sites.
  • Hybrid: Different pages use different strategies based on their needs. This is increasingly the default with frameworks like Astro and Next.js.

This single decision shapes everything: hosting requirements, performance characteristics, SEO behavior, development complexity, and operational costs.

Data Architecture

Where does content live, and how does it flow?

  • File-based: Markdown files in a Git repository. Zero infrastructure dependencies. Maximum portability.
  • Headless CMS: Content in a managed service, consumed via API at build time or request time. Better authoring experience, but adds a dependency and ongoing cost.
  • Database-backed: Traditional CMS or custom application with a relational database. Most flexible, most complex.

The choice depends on content volume, editorial team size, update frequency, and the team’s technical comfort level. Making this decision before design begins ensures the content model is solid, and the design accommodates real content structures rather than idealized placeholders.

Hosting and Deployment

Where does the site run, and how do updates get there?

  • Edge CDN (Cloudflare Pages, Netlify, Vercel): Best for static and hybrid sites. Global distribution, automatic scaling, minimal configuration.
  • Container/VPS (Docker on a VPS, Fly.io, Railway): Necessary for server-side applications with persistent state. More control, more responsibility.
  • Managed platform (WordPress hosting, Squarespace): Highest convenience, lowest flexibility.

This decision determines your operational burden for the life of the project. A static site on a CDN needs almost zero operational attention. A container deployment needs monitoring, updates, and scaling management.

Performance Envelope

What are the non-negotiable performance constraints?

Define these before design begins:

  • Maximum page weight (e.g., 500KB compressed)
  • Maximum JavaScript payload (e.g., 100KB compressed)
  • Target Largest Contentful Paint (e.g., < 2.5s)
  • Target Time to Interactive (e.g., < 3.5s)

When these constraints are established upfront, design decisions respect them naturally. A designer who knows the JavaScript budget is 100KB won’t design an interaction that requires a 200KB animation library. A content strategist who knows the image budget is 300KB will plan imagery accordingly.

How This Changes the Design Process

Architecture-first doesn’t diminish design — it focuses it. Instead of designing in a vacuum and hoping the technology can accommodate the vision, designers work within defined constraints that ensure the design is buildable, performant, and maintainable.

Constraint-Driven Creativity

Constraints breed creativity. When you know the site ships zero JavaScript by default, you design interactions that work with CSS transitions and HTML semantics. These solutions are often more elegant than JavaScript-driven alternatives and always more resilient.

/* Accordion without JavaScript — CSS-only with <details> */
details {
  border-bottom: 1px solid var(--color-border);
}

details summary {
  padding: 1rem 0;
  cursor: pointer;
  font-weight: 600;
  list-style: none;
  display: flex;
  justify-content: space-between;
  align-items: center;
}

details summary::after {
  content: '+';
  font-size: 1.25rem;
  transition: transform 0.2s ease;
}

details[open] summary::after {
  transform: rotate(45deg);
}

details > div {
  padding: 0 0 1rem;
  animation: slideDown 0.2s ease;
}

@keyframes slideDown {
  from { opacity: 0; transform: translateY(-0.5rem); }
  to { opacity: 1; transform: translateY(0); }
}

This accordion is accessible, performant, works without JavaScript, and weighs zero kilobytes. It exists because the architecture decision — zero JavaScript by default — made the designer look for native solutions.

Component-Driven Design

When the architecture defines a component model early, designers create within that model. Each design element maps to a defined component with known performance characteristics. There are no surprises during implementation because the design vocabulary and the technical vocabulary are aligned.

Content-Aware Layouts

Because the content model is defined before design begins, layouts are designed for real content structures. The designer knows that blog posts have a title, summary, date, author, category, and body. They know case studies have a client name, industry, challenge, solution, and results. Designs accommodate these structures rather than requiring content to be forced into arbitrary layouts.

The Architecture Decision Record

Every architecture decision should be documented. Not in a 50-page architecture document that nobody reads, but in a lightweight Architecture Decision Record (ADR) format:

# ADR-001: Static-first rendering with Astro

## Status
Accepted

## Context
The client website has 35 pages, updates weekly, requires no
user authentication, and needs to perform well globally.

## Decision
Use Astro with static output as the rendering strategy.
Deploy to Cloudflare Pages for global edge distribution.

## Consequences
- All pages are pre-rendered at build time
- Content updates require a rebuild (automated via CI/CD)
- No server-side runtime to maintain or secure
- Dynamic features (contact form) handled by Cloudflare Workers
- Team must be comfortable with Markdown-based content editing

This document takes five minutes to write and saves hours of “why did we choose this?” conversations later. We create an ADR for every significant architectural decision — typically 4-6 per project.

The Anti-Patterns

Architecture by Resume

Choosing technologies because they look good on a developer’s resume rather than because they suit the project. Kubernetes for a 20-page website. GraphQL for a site with no complex data relationships. A microservice architecture for a team of two. These decisions serve the developer, not the client.

Architecture by Fashion

Adopting whatever technology is trending on Hacker News this month. Tech trends move faster than project timelines. By the time you’ve built with the latest framework, it may already be eclipsed by the next one. Choose proven technology with active maintenance and a clear future.

Architecture by Absence

Making no explicit architecture decisions and letting them happen implicitly through accumulated implementation choices. This is the most common anti-pattern and the most damaging. When architecture decisions are implicit, they’re inconsistent, undocumented, and difficult to change.

Architecture by Committee

Involving too many stakeholders in technical decisions leads to compromises that satisfy nobody. Architecture decisions should be made by the smallest number of people with sufficient expertise and context. Others should be informed, not consulted.

The Payoff

Architecture-first projects have a distinctive quality: they feel simple. Not simplistic — the solutions can be sophisticated. But the overall system has a coherence that comes from structural decisions being made early and consistently applied.

The design serves the content. The content fits the data model. The data model works with the chosen technology. The technology runs on infrastructure that matches the operational capacity of the team. Everything aligns because alignment was the starting point, not an afterthought.

This coherence isn’t free. It requires discipline at the start of a project when the temptation is to jump straight into visual design or code. But the investment pays for itself many times over in reduced rework, smoother implementation, and a final product that’s genuinely maintainable.

Start with structure. The rest follows.