Start from defined architecture, not from an empty repository.

Architecture at a glance

Four stages with a one-way dependency direction. The middle two are the foundation; the first and the last are yours.

1. Stage 1

   Site data, content and assets

   Identity, navigation, locales, Markdown content and artwork — the adopter-owned inputs, validated before anything reads them.

2. Stage 2

   Foundation-derived runtime

   Framework-independent domain concepts plus the application services that orchestrate them, with no framework imports of their own.

3. Stage 3

   Presentation, routing and integration seams

   Routes, layout composition, metadata, and the adapter factories that bind booking, enquiry, maps and analytics from configuration.

4. Stage 4

   Deployment

   A static-generation-first build deployed from your own repository to your own hosting account.

Dependency direction is asserted by tests rather than assumed: the core may not import React, Next.js or an outer layer, and the application layer may not reach into a concrete adapter.

ARCHITECTURE.md in the repository

Configure, or code

This boundary is the point of the project. Most business-specific decisions are data; genuine extensions are code, and Foundation is explicit about which is which.

The engineering contract

What the project holds itself to — and what it refuses to claim.

• Strict validated configuration

  One schema, unknown keys rejected, actionable failures, and configuration readable only through the loader.

• Hexagonal boundaries

  A pure core, application ports and services, adapters behind factories, and thin framework routes.

• Dependency enforcement

  Architecture tests walk the source tree and fail on a forbidden import, so the diagram cannot drift away from the code.

• Server-first composition

  React Server Components and static generation by default, with client interactivity confined to the components that need it.

• Real-browser verification

  A committed headless-browser matrix drives desktop, tablet and mobile widths, keyboard and pointer interaction, reduced motion and dark scheme, and fails the run on any assertion failure.

• Architecture and unit gates

  Boundary and unit tests run beside the assets check, type check, lint and production build.

• Capability-claim discipline

  Documented capability claims are checked against the project's own record of what is implemented and verified, so a claim cannot be raised above its evidence.

• An honest upgrade model

  Because your configuration, content and assets live outside the application core, platform improvements can be absorbed instead of overwriting your work.

Where Foundation stops

The same ownership split, stated technically. Foundation deliberately stops before business operational complexity, and provides the seam to whichever service you choose.

Extension works from the outside in: a new provider is an adapter plus a factory branch and a schema enumeration entry, and a new content type or locale is data. A genuinely new capability is platform work.

Adoption workflow

Eight stages. The repository owns the command-level detail — this is the shape of the work.

1. 1

   Get Foundation

   Clone or fork the public repository.

2. 2

   Install and run

   Install dependencies and start the site locally.

3. 3

   Configure

   Set identity, locales, features and provider choices.

4. 4

   Author content and assets

   Write your pages and replace the brand asset roles.

5. 5

   Connect providers

   Point the seams at the services you actually use.

6. 6

   Validate

   Run the project's own gate locally.

7. 7

   Deploy

   Build and deploy from your own repository and account.

8. 8

   Maintain and upgrade

   Absorb upstream improvements without overwriting your material.

The repository's instruction manuals cover each stage, including troubleshooting.

Authoritative documentation

GitHub is the canonical technical source. This website summarises; the repository instructs.

• Repository

  The complete source, its licence, and the project's own statement of what it is and is not.

• README.md

  What the project is, quick start, repository layout and the licence position.

• ARCHITECTURE.md

  Architectural style, boundaries, dependency direction and integration patterns.

• CUSTOMIZING.md

  The downstream user guide and the complete configuration reference.

• DEPLOYMENT.md

  The launch runbook and the post-deployment verification checklist.

• BRAND_ASSETS.md

  The brand-asset swap contract: every replaceable graphic role.

• Instruction manuals

  Adoption, customisation, branding, content, upgrade, validation, deployment and troubleshooting procedures.

Every destination above is a link into the public repository, which is where those documents are maintained.