A Site Template for Architecture Practices

Overview

ArchFirm Chartered Architects of Faketown, Midshire does not exist. Neither do its projects, its clients, its people or its address. The practice, the work and the town are invented, the phone number comes from Ofcom’s reserved drama range, and the email domain is reserved under RFC 2606 — so neither can reach a real party. The live site says as much on every page, in a dismissible banner. You can see it at arch.adamjonesdevelopment.com.

Nobody commissioned it, and that is the point. With no client to please and no brief to satisfy, the build could be aimed squarely at the thing worth proving: how quickly a well-structured codebase becomes a different practice’s site. There are no traffic figures or enquiry rates here, because there is no business behind it to measure. What there is, is the build.

Built as a template, not a site

Regional architecture and design practices need close to the same site: who they are, what they do, selected projects, how to reach them. Building each one from scratch means paying for the same decisions again every time. So this is a build-time template. Standing up a new practice is a content and theme swap, not a fork of the code:

• site.config.ts — practice identity, contact details, deployment behaviour
• theme.ts — every colour, font stack, radius, shadow, rhythm and motion value in one file. A script generates the CSS variables from it, and the OG image and favicon import it directly, so the palette is never written down twice.
• src/content/ — typed content modules. A missing field is a compile error, not a blank section on a live page.
• studio.config.ts — my own brand, kept separate on purpose, so the byline and the demo banner survive a re-skin untouched.

No component holds a practice name, service description, project title or contact detail as a string literal. A full re-skin takes roughly three to four hours, and a new-practice script scaffolds one and prints the checklist.

Two deployment modes, no code change

Environment variables switch the build between two modes:

• Portfolio — indexed, published as a piece of work.
• Prospect demo — noindex on every route, a robots.txt disallow, and an empty sitemap.

It defaults to the non-indexable mode, so a variable nobody remembered to set cannot leak a client demo into search results.

What it measures

Lighthouse, mobile, against a production build:

• Accessibility 100 on every route
• Best Practices 100 on every route
• SEO 100 on every route
• Cumulative Layout Shift 0 on every route
• Performance 87–95, depending on the route

Stack and privacy

• Next.js 16 on the App Router, built with Turbopack
• TypeScript in strict mode
• Tailwind CSS v4
• No analytics, no cookie banner, no chat widget, no tracking scripts
• All imagery self-hosted and credited, with no third-party image CDN at runtime
• One external request in the whole site: a lazy-loaded Google Maps embed on the contact page

What this proves, and what it doesn’t

Every practice, project, client, person, address and place name in it is invented — this is a template demonstration, not a client engagement, and the live site says so on every page. It is built to prove exactly one thing: how the code is organised, and how little of it has to change to stand up the next practice. It makes no claim about traffic, enquiries or revenue, because there is no business behind it to make one about.

See it running at arch.adamjonesdevelopment.com.