Digital Brand Guide PRD Discovery Questions

Goals and non-goals I’m inferring from your notes

You’re aiming for a scalable, searchable, responsive digital brand guide (tiny coffee shop → enterprise brand ecosystem with sub-brands) that’s repo-first, can later be CMS-backed (e.g., Sanity), and deploys cleanly on entity["company","Vercel","cloud platform company"] with custom domains. Search needs to remain reliable as content grows, including automatic re-indexing when content is updated, and the guide should support light/dark mode plus “as ADA-compliant as possible” (so practically: target WCAG 2.2 AA unless you say otherwise). citeturn6search0turn6search1

You’re explicitly not building code components; that’s a separate “design system” product.

Patterns worth stealing from Geist

From the Geist site itself, a few patterns map directly to what you described:

Geist is essentially a docs-style portal with a global search (including a visible keyboard shortcut) and a theme switcher (system/light/dark). citeturn2view0
It also uses a left sidebar IA that can scale from “Foundations” to a huge component list without collapsing into chaos. citeturn2view0
On the Colors page, they lean into “utility” UX: instructions like “right click to copy raw values,” plus tokenized/color-scale organization. citeturn3view0

Also worth noting: the Geist typeface is open-source (font repo exists), but the Geist UI component library you may have seen around is a community project and not affiliated with Vercel. citeturn0search1turn0search9

Content model and information architecture questions

These decide whether you’re building a “pretty PDF replacement” or a “living reference tool” (and they’ll massively shape the PRD).

What content categories are required for v1 (not “eventually”), and which are explicitly out-of-scope? - Beyond logo/colors/type, do you want voice & tone, photography style, icon rules, pattern/texture usage, social templates, co-branding rules, brand architecture / sub-brand relationships, etc.? (Dropbox and Mailchimp both go beyond pure visuals; if you want that style, scope grows fast.) citeturn4search8turn4search2turn4search5

For “large brand libraries,” do you expect the guide to act like a mini DAM? - Do users need download-all bundles (logos/icons/fonts/templates) vs only individual downloads? - Do you need versions (“current logo” vs “legacy”), deprecated assets, and a changelog?

How do you want to represent sub-brands? - One guide with a sub-brand switcher? - Separate “brand spaces” under one tenant? - Or separate deployments per sub-brand?

Colors: how deep does this go? - Just HEX/RGB + usage notes, or also CMYK/Pantone, “do/don’t,” contrast guidance, and maybe color scales? - Should “search for a color” include hex lookups like #0F172A and return the exact swatch card?

Typography: what’s the expectation around licensing and distribution? - Are you expected to host font files (and protect them), or just document “use this font from X”? - Will clients ever upload fonts (which becomes storage + permissions + legal risk)?

Assets: what formats and sizes are “standard”? - SVG/PNG/PDF for logos, plus social-ready exports? - Any need for Figma links or embedded previews?

Since “searchable” is one of your core requirements, this is where you either win or ship a sad magnifying glass icon that nobody uses.

Search behavior: what does “takes him right to the colors page or section” mean in practice? - Should search return pages only, or deep links to headings/anchors, or even to specific objects (a single color, a specific logo file)? - Should results be grouped by type (Colors / Typography / Logos / Assets / Guidelines)?

Do you want a docs-style command palette search (like Geist’s “hit a key, type, jump”), or a classic search page + results list? citeturn2view0

Index granularity: what content needs to be indexed? - Page titles + headings only? - Body content too (longer indexing, noisier results)? - Structured entities (colors, fonts, assets) as first-class searchable records?

Navigation scale: what’s the maximum depth you want to support? - Two levels (Sections → Pages) or true tree (Section → Subsection → Page → anchors)? - For very large guides, do you want “expand/collapse all” + “current section highlight” + “scroll spy”?

Mobile nav: what’s the expected interaction? - Off-canvas drawer? - Nested accordion? - Separate “browse” vs “search” entry points?

Utility interactions: should it be optimized for “copy/paste correctness”? - For colors: copy HEX / RGB / HSL; maybe right-click or a one-click copy button (Geist leans this way). citeturn3view0 - For typography: copy font-family stack, weights, usage notes?

Editing workflow, CMS readiness, and re-indexing questions

You said “no CMS out of the gate” but you do want to plan for it. That’s mostly about choosing a content shape that won’t paint you into a corner.

Who is the editor in v1? - Only your internal team via PRs? - Internal + client editors (which almost forces CMS sooner)?

When you say “plan for Sanity,” what’s the expected timeline/trigger? - “After first client ships” - “Only if client requests edits” - “We want it ready but disabled”

What’s your preferred starter content format for v1? - MDX is usually the sweet spot for “docs-like” with structure and embeds; Next.js supports local and remote MDX. citeturn6search3 - Or do you want pure JSON/YAML for structured sections (colors/assets), plus markdown for prose?

Re-indexing: what counts as “automatic” for you? - “Any content change triggers rebuild; rebuild regenerates the search index” (simple, reliable) - Or true incremental indexing (CMS webhook updates search index record-by-record). (Doable; more moving parts. Algolia + Sanity webhook patterns exist specifically for this.) citeturn1search3turn1search5turn0search34

Where should search live? - Fully local (build a static index shipped with the site)? - External search service (Algolia/Typesense/Meilisearch)? - If external: do you need analytics (popular searches / “no results” reporting)?

Deployment, access control, backups, and ownership questions

This is the stuff that decides whether client handoff is painless or a yarn-ball escape room.

Gating: do you want “single password” at the platform layer or in-app? - Platform layer: Vercel has Password Protection (lock screen + cookie), but it’s Enterprise or a Pro add-on. citeturn0search2turn0search16turn0search6
- In-app: You can do Basic Auth via middleware (Vercel provides an example). citeturn0search10
Which approach matches your typical client/project plan level?

Password management expectations: - One password per guide? Per environment (preview vs prod)? - Do you need “rotate password” auditably and quickly without redeploy?

Hosting assets: do you want assets in-repo, or in object storage? - entity["company","Vercel","cloud platform company"] Blob supports public/private object storage patterns (useful if you don’t want giant repos or you need access controls at the file level). citeturn5search17

Backups: what exactly must be backed up weekly? - Content (repo) is already versioned if you’re in Git. - But assets in object storage, CMS datasets, env vars, and domain config are separate concerns. - If you truly want scheduled backups, Vercel Cron Jobs are a first-party way to run scheduled tasks (with plan-specific limitations; for example Hobby has restrictions). citeturn5search0turn5search15

If you end up with a DB: what do you consider an acceptable recovery posture? - If you use entity["company","Neon","serverless postgres company"] (common with Vercel Marketplace setups), point-in-time restore/backup retention depends on plan. citeturn5search9
- Also: Vercel’s own storage repo notes their prior Postgres/KV packages are sunset, so you’ll likely be relying on Marketplace providers anyway. citeturn5search24

Client “take it and self-host it” requirement: - Does that mean static export should be possible (so they can host anywhere)? - Or just “run the same Next.js app on their own server”?

Multi-client strategy questions

You floated two models: separate guides per client vs a parent platform that deploys client guides.

Which model is the intended default for the next 6–12 months? - Separate projects per client: simplest security/isolation; heavier ops overhead; easy to hand off. - Single multi-tenant app: shared codebase; trickier isolation; needs tenant routing, content partitioning, and likely an admin UI.

If you want multi-tenant, are you envisioning subdomain-based tenancy (e.g., brand.client.com or client.brandguides.com)? - Vercel publishes a “Platforms Starter Kit” that’s explicitly a multi-tenant Next.js example with custom subdomains, middleware routing, and a basic admin interface. Is that roughly the vibe you mean by “parent system”? citeturn10view0

Data isolation: when you say “all likely need their own database,” is that a hard requirement? - Separate DB per client (maximum isolation, easiest client handoff) - One DB with tenant separation (cheaper, simpler infra, more risk if you screw up tenancy boundaries) - Separate CMS datasets/projects per client (if Sanity becomes the source of truth)

Handoff mechanics: what does “disconnect it without untangling a ball of yarn” mean operationally? - “Export tenant content + spin up new repo + map domain” - “Clone template repo and import dataset” - “One-click ‘eject’ that generates a standalone project”

Examples to react to

Rather than me guessing your preferred UX, tell me which you’d rather emulate:

Geist (Vercel): docs-style portal with global search + theme switcher + scalable sidebar IA.
What do you like/dislike about this interaction model for a brand guide (not a design system)? citeturn2view0turn3view0

Dropbox brand guidelines: very “living site” feel, lots of sections beyond pure tokens.
Do you want your brand guide to be this editorial/storytelling-heavy, or more utilitarian? citeturn4search8turn4search12turn4search26

Mailchimp brand assets / content style guide: splits “brand assets” from “how we communicate,” with clear guidance.
Do you want voice/tone to live in the same portal as visual identity, or be separate? citeturn4search2turn4search5turn4search9

Asana brand page: more of a straightforward “download + do/don’t” brand asset rules page.
Is “simple and strict” acceptable for smaller clients, or do you still want the richer portal UX even for tiny brands? citeturn4search0