Product Requirements Document — quarry.team (next-gen)

Status: Accepted
Owner: Product / Engineering
Last updated: 2026-06-12

This PRD defines the pages, features, content model, and acceptance criteria for the next-gen site. It assumes the architecture in docs/adr/. Non-functional targets (performance, a11y, security, SEO) live in non-functional-requirements.md.

1. Pages

Page	Route	Purpose	Primary CTA
Home	`/`	Position Quarry; route to work, services, contact	Start an inquiry
Services / Capabilities	`/services` (+ detail per service)	What we do and how we engage	Start an inquiry
AI Services	`/ai-services`	AI development & integration offering (AI as a product, AI as a feature)	Start an inquiry
Compliance	`/compliance`	Evidence of delivery in regulated environments	Start an inquiry
How we use AI	`/how-we-use-ai`	How Quarry applies AI: leverage, with discipline	Start an inquiry
Work (index)	`/work`	Curated case-study library	Open a case
Work (detail)	`/work/<slug>`	Outcome-led case study	Start an inquiry
About / Team	`/about`, team profiles	Who we are; credibility	Careers / Contact
Blog (index)	`/blog`	Editorial / POV	Read a post
Blog (detail)	`/blog/<slug>`	Article	Subscribe / Contact
Contact	`/contact`	Qualified inquiry capture (primary conversion)	Submit inquiry
Careers (index)	`/careers`	Open roles, culture	Apply
Careers (application)	`/careers/<role>` or apply form	Application capture (secondary conversion)	Submit application
Search	site-wide (Pagefind UI)	Find work/posts	—
System	`404`, `robots.txt`, `sitemap.xml`, `llms.txt`	Errors & discoverability	—

Legacy /cases/<slug> issues a 301 to /work/<slug>; /blog/<slug> is unchanged (ADR 0011).

2. Features

Curated case-study library with filterable index and rich, outcome-led detail pages.
Editorial blog with MDX authoring and embeddable design-system components.
Static search via Pagefind over work + posts, no server.
Lead capture (contact, careers) → same-origin /api/* routes on the Worker → Cloudflare D1, protected by Turnstile and server-side validation (ADR 0014).
Responsive, optimized images generated at build by Astro’s image pipeline from git-committed sources (ADR 0004, ADR 0006).
Privacy-first analytics, no cookie banner (ADR 0010).
SEO: per-page metadata, canonical URLs, OG/Twitter cards, JSON-LD, sitemap, llms.txt.
Design system components driven by tokens (ADR 0003, ADR 0007).
A tasteful browser-console easter egg on the live site (non-functional).

3. Content model

Content lives in Astro Content Collections under apps/web/src/content, validated by Zod (ADR 0004). Authoritative field reference: ../guides/content-authoring.md.

`cases`

Curated case studies (folder-per-entry MDX). Indicative fields: title, client, summary, disciplines[] (enum), industry?, outcome (kicker?/headline/stat?/supporting[]), role?/duration?/team?, releasedDate, updatedDate?, hero (+ heroAlt/heroCredit?), gallery[], featured (bool), order, comingSoon (bool), draft (bool), legacySlug?, seo (title/description). Body = MDX.

`posts`

Editorial blog (folder-per-entry MDX). Indicative fields: title, description, publishedDate, updatedDate?, author (plain string, default Quarry), category?, tags[], hero (+ heroAlt/heroCredit?), draft. Body = MDX. Slugs map 1:1 to legacy /blog/<slug>.

`services`

Capabilities (data collection, services/services.json). Indicative fields: id, title, summary, capabilities[], discipline? (enum), order.

`roles`

Open careers roles (MDX). Indicative fields: title, team, location, type, summary, datePosted, validThrough?, order, draft. Body = MDX.

`team`

People (data collection, team/team.json). Indicative fields: id, name, role, location?, bio?, avatar?, lat?/lng? (city-level, ≤1 decimal), order. Used for authorship and the team page.

Field names above are indicative; the Zod schemas in apps/web/src are authoritative. The authoring guide is kept in sync with those schemas.

4. Acceptance criteria

Global

Every page passes TypeScript strict + astro check, lint, and format checks.
Every page meets the performance and a11y budgets in the NFR doc (Lighthouse ~100, WCAG 2.2 AA) and passes axe checks in CI.
Content with invalid/missing required frontmatter fails the build (does not ship).
draft: true content is excluded from production builds, sitemap, and search.
Every page has canonical URL, title, meta description, OG/Twitter tags; relevant JSON-LD present and valid.
Images are responsive, lazy where appropriate, and carry meaningful alt text.

Work

/work lists published cases with working filters; featured cases surface appropriately.
/work/<slug> renders hero, body (MDX), outcomes, gallery, and a contact CTA.
/cases/<slug> 301-redirects to the matching /work/<slug>; redirect map is verified in CI/deploy.

Blog

/blog lists published posts (newest first) with author and date.
/blog/<slug> renders MDX with design-system components; URLs match legacy slugs.

Search

Pagefind indexes published work and posts at build; the search UI returns relevant results with no server runtime.

Contact (primary conversion)

Valid submissions reach the /api/contact route on the Worker, pass Turnstile + server-side validation, and persist to Cloudflare D1.
Invalid input yields accessible, field-level error messaging; the form is fully keyboard-operable and screen-reader labeled.
Spam/bot submissions are blocked by Turnstile without a cookie banner.
Success and failure states are clearly communicated to the user.

Careers (secondary conversion)

/careers lists open roles; each role links to an accessible application flow.
Applications persist to the data tier with the same validation/Turnstile guarantees as contact.

SEO / system

sitemap.xml lists all public, non-draft pages and is referenced by robots.txt.
llms.txt is present and describes the site/key URLs.
404 is branded and offers navigation back into the site.