Digital Brand Guide — Product Requirements Document

⚠ Historical document. This PRD predates the MCP product strategy. It conceives the brand guide as a standalone web product per client. The product has since evolved into a multi-tenant MCP-as-a-service platform (Slack bot, Claude Code skill, Codex, planned design-tool skill) with each client's brand-guide site serving as a content layer. The current canonical PRD lives at ../brand-guide-mcp/PRD.md. This doc is preserved as the original conception of the product.

Status: Draft v1 (superseded by ../brand-guide-mcp/PRD.md) Author: Grain & Mortar Last updated: 2026-03-10

1. Overview

A web-based digital brand guide: searchable, responsive, and built to replace the PDF brand guide. It gives clients and their teams a living reference they can actually use — find a hex value, download a logo, look up a voice guideline — without opening a file they emailed themselves six months ago.

Deployment: Vercel + custom client domain Stack: Next.js (App Router) + Tailwind CSS Content model: MDX (prose) + JSON/YAML (structured data) — designed for future Sanity migration Client model: Separate repo per client. First build is for one client. After that, the repo becomes a configurable template.

2. Problem

Static PDFs die. They get emailed around, go out of date immediately, and nobody can find anything in them. Brand teams make off-brand decisions not because they don't care — it's because they couldn't find the right file or didn't know the rule existed.

A living, searchable brand guide solves this. It's always current, always accessible, and gives people the exact answer they need in under 10 seconds.

3. Goals

4. Non-Goals (v1)

5. Users

Primary: Client's internal team — marketing, design, product, agencies, vendors — anyone who needs to use or apply the brand.

Secondary: G&M team managing and updating the guide on behalf of the client.

Users are not developers. The guide must be approachable and fast for non-technical people.

6. Content Taxonomy

This is the canonical structure for what belongs in a brand guide vs what doesn't. Clients need clear buckets so they know what to add, what to update, and what belongs elsewhere.

What lives in the Brand Guide

The brand guide answers: what our brand is, how it looks, and how it sounds. It is rules-first, not code-first.

Section Contents
Brand Foundation Story, mission/vision/values, personality traits, audience overview, brand promise
Visual Identity → Logo Primary, secondary, wordmark, icon-only variants; clear space rules; sizing minimums; do/don't; file downloads
Visual Identity → Color Primary, secondary, neutral palettes; HEX/RGB/CMYK/Pantone; usage rules; contrast guidance; color scale if applicable
Visual Identity → Typography Typefaces, weights, usage hierarchy, specimen examples, licensing source link
Visual Identity → Iconography Icon set display, sizing rules, usage context, download
Visual Identity → Photography & Imagery Style direction, mood, do/don't, example images
Voice & Tone Brand voice traits, tone spectrum by context, writing guidelines, example copy, do/don't
Assets & Downloads Logo files (SVG, PNG, PDF), brand kit zip, templates (social, presentations)

Sections are modular. A small client may skip Brand Foundation and Photography. A larger client may add Illustration, Motion, or Co-branding rules later.

What does NOT live here

Item Belongs In
Code components (buttons, inputs, cards) Design System
CSS/design tokens in code form Design System
Storybook / interactive component docs Design System
API documentation Developer docs
Marketing copy or campaign assets Client's internal files

The rule: if you need a browser and a code editor to consume it, it's a design system concern. If you need it to make a creative decision, it's a brand guide concern.

7. Feature Requirements

Search is a core feature, not a nice-to-have.

Future: Algolia or Typesense upgrade if index size or analytics become necessary.

7.2 Navigation

7.3 Theme

7.4 Color Section

7.5 Typography Section

7.6 Logo Section

7.7 Iconography Section

7.8 Photography & Imagery Section

7.9 Voice & Tone Section

7.10 Assets & Downloads

7.11 Access Control

7.12 Accessibility

8. UX Direction

Reference: Geist/docs-style structure with a polished, elevated visual treatment. Not a dev docs site. Not a marketing site. Somewhere between the two.

Not editorial. Not storytelling-heavy. Purposeful and well-crafted.

9. Technical Architecture

Layer Decision
Framework Next.js (App Router)
Styling Tailwind CSS
Content: prose MDX (local files in v1)
Content: structured data JSON or YAML (colors, fonts, assets, icons)
Search Static index (Flexsearch or Fuse.js), generated at build time
Hosting Vercel
Auth Next.js middleware — Basic Auth via env vars
Asset storage In-repo (public/ directory) for v1
CI/CD Vercel auto-deploy on push to main

CMS readiness: Content is structured in a way that maps cleanly to Sanity document types. When the time comes, MDX files → Sanity documents, JSON files → Sanity datasets. The component layer does not need to change.

10. Content Management (v1)

G&M manages all content updates via PR. No client login, no CMS.

Workflow: 1. Client requests a change (email, Basecamp, etc.) 2. G&M updates the relevant MDX or JSON file 3. PR merged to main → Vercel auto-deploys 4. Change is live

This is intentionally simple. It works until either (a) the client needs to self-edit, or (b) G&M has enough clients that the maintenance volume justifies CMS tooling.

11. Future Considerations (v2+)

These are out of scope for v1 but should not require architectural changes to implement:

12. Open Questions

Question Owner Notes
Who is the first client? Eric Determines actual content requirements and timeline
Does the first client need CMYK/Pantone values? G&M → Client Determines color data model complexity
Does the first client have a custom icon set, or are they using a library (FA, Lucide, etc.)? G&M → Client If library, iconography section may just be guidance, not a download section
Font licensing: are any typefaces restricted from web use? G&M → Client Determines whether font files can be hosted or only linked
What's the password strategy? One password shared with the whole team, or restrict more tightly? Eric Middleware Basic Auth is simple but shared; explore Vercel Password Protection add-on if needed
Should the guide be publicly accessible or always gated? G&M → Client Some clients want it open; others want it behind auth