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 this. There was no client and no brief, so there are no results to report — no traffic figures, no enquiry rates, no testimonials. What is worth reporting is how it is put together.

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 — the studio’s 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 is not

This is a concept build. It was not commissioned, there is no client behind it, and there is nothing to claim about what it did for a business. Every practice, project, client, person, address and place name in it is invented. Read it as evidence of how the code is organised and how quickly it re-skins — not as a case study of a commercial result.

See it running at arch.adamjonesdevelopment.com.