# Architecture Decisions (ADRs) — Diana Website (v1)

This file records stable architectural decisions and their rationale. Items here should remain valid even as implementation details evolve.

## ADR-001 — Static website as the delivery model
- **Status**: Accepted
- **Context**: Site is primarily informational/lead-capture, needs strong SEO, and is expected to change infrequently.
- **Decision**: Build as a **static website** (pre-rendered HTML) suitable for hosting behind a Caddy reverse proxy.
- **Rationale**:
  - SEO-friendly (fully indexable content)
  - Fast and reliable on mobile
  - Low maintenance
- **Alternatives considered**:
  - WordPress/CMS: easier editing but higher maintenance/security surface
  - SPA-only: SEO/performance risks and complexity
- **Consequences**:
  - Contact form delivery must be handled via a static-compatible approach (see ADR-002)

## ADR-002 — Form backend: existing AWS service
- **Status**: Partially accepted (details pending)
- **Context**: The site must collect quote request form submissions (FR-3, FR-5). The site is static, so a backend service is required.
- **Decision**: Use an **existing AWS service** owned/operated by the stakeholder.
- **Rationale**:
  - Reuses existing infrastructure
  - Avoids new third-party service dependencies
- **Remaining open items** (blocking `38-lead-capture-spec.md`):
  - Which AWS service is used (e.g. SES, API Gateway + Lambda)?
  - What is the form submission endpoint URL?
  - What spam protection is in place or expected (e.g. honeypot, reCAPTCHA, AWS WAF)?
- **See also**: OQ-3

## ADR-003 — Mobile-first, performance-first design
- **Status**: Accepted
- **Context**: Most traffic is expected on mobile; SEO and conversion depend on usability and speed.
- **Decision**: Adopt a **mobile-first** layout and performance budget mindset throughout.
- **Rationale**:
  - Improves conversion on mobile
  - Supports SEO (Core Web Vitals)
- **Consequences**:
  - Images must be optimized (sized, compressed, lazy-loaded); avoid heavy JavaScript
  - Ensure accessible typography and touch-friendly tap targets

## ADR-004 — Service pages: grouped by search intent for SEO
- **Status**: Accepted
- **Context**: Individual pages per service produce better SEO but only if pages have sufficient unique content. Some services (carpentry/mounting, flooring/wood refinishing) share search intent and image assets.
- **Decision**: Organize service pages into **9 grouped pages** (down from 10+ individual items), grouped by search intent:

  | Page | Slug | Services grouped |
  |------|------|-----------------|
  | Painting | `/services/painting/` | Interior & exterior painting, trim |
  | Tile Setting | `/services/tile-setting/` | All tile types, all rooms |
  | Drywall & Sheetrocking | `/services/drywall/` | Drywall, sheetrocking, patching |
  | Minor Plumbing | `/services/plumbing/` | Sinks, toilets, showers |
  | Minor Electrical | `/services/electrical/` | Lights, fans, fixtures |
  | Carpentry & Mounting | `/services/carpentry-and-mounting/` | Carpentry, mounting, assembly |
  | Flooring & Wood Refinishing | `/services/flooring/` | Flooring, decks, stairs, refinishing |
  | Security & Safety Equipment | `/services/security-safety/` | Grab bars, locks, cameras |
  | Boat Work | `/services/boat-work/` | Marine woodwork, paint, hardware |

- **Rationale**:
  - Grouped pages have richer content and avoid thin-page SEO penalties
  - Carpentry + Mounting share the installation/assembly search intent
  - Flooring touch-ups + Wood Refinishing share the surface/finishing search intent and asset library
- **Consequences**:
  - Each grouped page must contain enough unique content to serve its target keywords
  - Internal linking from the Services hub must cover all sub-topics

## ADR-005 — No analytics or tracking in v1
- **Status**: Accepted
- **Context**: Stakeholder decided against tracking for simplicity.
- **Decision**: **No analytics scripts, no ad pixels, no cookie consent banner** in v1.
- **Rationale**: Reduces complexity, avoids consent/privacy obligations at launch.
- **Consequences**:
  - No data-driven iteration on traffic or conversions at launch
  - Adding analytics later will require revisiting privacy policy needs