The stack, and why
Palate builds on an opinionated stack. Here is every choice, the real reason for it, and the honest trade-off. No marketing, just the decisions a skeptical developer would want to interrogate.
Install it. Ask. Watch it build.
Before any of the choices below, here is the shape of it end to end: from one install to a site in production, in plain language. You ask in a line like Build a site for {client}, {domain}., and it goes.
01
Install once
Add the marketplace, install the plugin, connect Palate. About two minutes, and you only do it the one time.
02
Ask in plain English
Say what you want, the way you would say it to a person: "Build a site for {client}, {domain}." No config, no setup wizard.
03
It studies the library first
The survey agent fans out across the MCP and pulls the right donor references, with their real tokens, motion and do/don't rules. It reads before it writes.
04
It explores directions
It generates a few genuinely different takes, not one, on a shareable preview, so you pick rather than guess.
05
It composes the real thing
A production Astro site (Sanity CMS, SEO, forms, your brand package), grounded in those references instead of the generic average.
06
It cannot fake the depth
Enforcement hooks block it from finishing until it has actually used the library, so grounded in real craft is enforced, not promised.
07
Preview, pick, promote
Review the shareable link, choose your direction, and ship to production.
The stack, as a map.
Each piece, the role it plays, and the honest trade-off. Open any tile for the reasoning a skeptical developer would want to interrogate.
Astro Astro 6 The framework. HTML and CSS by default, JavaScript only where a piece is actually interactive. Open the reasoning
Why
For a marketing site that is mostly type, layout and imagery, that is the right shape: the page is fast because most of it is not an app. React comes in as an islands integration for the few bits that need it, not as the whole runtime. Every build is SSR from the first file, so a published edit goes live on the next page load with no redeploy.
The trade-off
A heavily interactive product, a live web app, belongs on a framework built for that, not Astro. And SSR adds a host runtime dependency and a small per-request render cost; a true brochure site can opt into a static build, but we confirm that is genuinely wanted first.
The questions behind it
Why Astro?
Astro ships HTML and CSS by default and only sends JavaScript where a piece is actually interactive. For a marketing site that is mostly type, layout and imagery, that is the right shape: the page is fast because most of it is not an app. React comes in as an islands integration for the few bits that need it, not as the whole runtime. The trade-off is that a heavily interactive product, a live web app, belongs on a framework built for that, not Astro.
Why server-render instead of a pure static build?
Every build is SSR from the first file. The reason is content freshness: an edit to published copy goes live on the next page load, with no redeploy, no rebuild webhook, no deploy hook to wire. The trade-off is a host runtime dependency (a serverless function rather than pure files on a CDN) and a small per-request render cost. A true brochure site with no editing needs can opt into a static build, but that is the rare case and we confirm it is genuinely wanted before taking it.
Why many pages, not a single-page app?
The posture is multi-page and server-rendered, with interactivity added island by island. The search UI is a static index, the variant picker is a native details element with zero JavaScript, and the rest ships as plain HTML. Less JavaScript means faster first paint and fewer ways for the page to break. The cost is that genuinely app-like state (a live dashboard) belongs in a framework built for it, not on a content-led marketing site.
Tailwind + @palate/brand Tailwind 4 The styling. A thin config that imports the brand preset; tokens come from one versioned package. Open the reasoning
Why
The project Tailwind config is a thin shim: it imports the brand preset and little else. Colour, type, spacing, radius and motion live in one package, exported in four formats from a single token file: JSON for the spec, CSS variables, typed TypeScript, and a Tailwind preset. One source means the formats cannot drift, and a re-skin is a one-line change. The package is pinned to an exact version, never to latest.
The trade-off
The build is coupled to the brand contract: the preset has to exist and export cleanly, or styling has nothing to read from. A brand change is a deliberate version bump rather than a surprise.
tokens.json
JSON specCSS variablesTyped TypeScriptTailwind preset
The questions behind it
Why Tailwind, configured to do almost nothing?
The project Tailwind config is a thin shim: it imports the brand preset and little else. Design tokens come from the brand package, not from styles invented per page. That keeps every section consistent and makes a re-skin a one-line change. The trade-off is that the build is coupled to the brand contract: the preset has to exist and export cleanly, or styling has nothing to read from.
Why ship the brand as a versioned package?
Colour, type, spacing, radius and motion live in one package with one source of truth, exported in four formats from a single token file: JSON for the spec, CSS variables, typed TypeScript, and a Tailwind preset. One source means the formats cannot drift, and one logical package can feed many tools at once. The package is pinned to an exact version, never to latest, so a build is reproducible and a brand change is a deliberate bump rather than a surprise.
Why self-host the fonts?
Every typeface is served from the site itself, woff2 first, with font-display set to swap so text is never invisible while a font loads. Self-hosting means no third-party connection on every page load, which is faster and more private, and it does not break when someone else's font CDN has a bad day. The trade-off is that we manage the licences and the file variants ourselves. The one exception is a foundry kit that cannot be redistributed, which is loaded from its kit with the licence noted.
Sanity The content. Structured, editor-managed copy wired in from the first file, with live draft preview. Open the reasoning
Why
Whoever runs the site gets structured content they can change without touching code. Because the site is server-rendered, drafts preview live before they go public, and an editor's published change is live on the next page load. The template also carries the real copy in a code-level fallback, so the preview is the production codebase at an earlier moment, reading the same content. Nothing gets rewritten on the way to production.
The trade-off
Wiring a CMS in later forces a static-to-server rewrite, so it ships from the start on purpose. A true brochure site with no editing needs can opt out into a static build, but that is the rare case and we confirm it is wanted first.
The questions behind it
Why Sanity for content?
A build ships with Sanity wired in from the first file, so whoever runs the site gets structured, editor-managed content they can change without touching code. Because the site is server-rendered, drafts preview live before they go public. It is wired in from the start on purpose: draft preview only works with a server rendering unpublished content, and bolting a CMS on later forces a static-to-server rewrite. A true brochure site with no editing needs can opt out into a static build, but that is the rare case and we confirm it is wanted first.
How do drafts and editing work without a separate staging site?
The template also carries the real copy in a code-level fallback, so the preview runs on that copy and production is seeded from the same copy. Nothing gets rewritten on the way to production: the preview is the production codebase at an earlier moment, reading the same content. An editor's published change is live on the next page load, with no redeploy and no rebuild to wire.
Vercel The host, by default. Every push gets a shareable preview URL with point-and-click comments. Open the reasoning
Why
The win for client work is the review loop: a non-technical client can mark up the page in the browser without touching code or running anything locally. The Astro template is Vercel-native (the serverless adapter, the config and CI all ship ready), so deploys and rollbacks are one command. Previews are throwaway by design, set to no-index and excluded from analytics, so a draft never gets indexed or pollutes the numbers.
The trade-off
Metered bandwidth and the odd serverless cold start, fine for this workload. Cloudflare Workers is the maintained backup for a high-traffic, cost-sensitive site (see the comparison below).
Vercel --host cloudflare Bandwidth Metered Unlimited Edge locations ~30 300+ Cold starts Occasional None Preview comments One-click None Deploy shape Single command Build, then deploy
The questions behind it
Why Vercel by default?
A build deploys to Vercel by default. The win for client work is the review loop: every push gets a shareable preview URL with point-and-click Toolbar comments, so a non-technical client can mark up the page in the browser without touching code or running anything locally. The Astro template is Vercel-native (the serverless adapter, the config and CI all ship ready), so deploys and rollbacks are one command with no host adaptation. The trade-off is metered bandwidth and the odd serverless cold start, fine for this workload.
Why is the default a shareable preview URL, not a local server?
The first thing a build produces is a real preview deployment: a live link a client can open with no login and comment on directly. Showing work on a real URL beats describing it. A local preview is the fallback for offline dev. The cost is that previews live on the host, but they are throwaway by design, set to no-index and excluded from analytics so a draft never gets indexed or pollutes the numbers.
What if I don't want Vercel?
Vercel is the default, and the build always asks which host at the plan checkpoint. Cloudflare Workers is the maintained backup, chosen with a single flag (--host cloudflare) or when the brief calls for it. You would reach for it on a high-traffic, cost-sensitive site: unlimited bandwidth, 300-plus edge locations against Vercel's thirty or so, and no cold starts. The trade-off is a separate build-then-deploy step and the loss of Vercel's one-click preview comments. Both paths build the same Astro site, so it is a host choice, not a code change.
GitHub Actions The repo and CI. A real repository you own, with checks and previews on every push. Open the reasoning
Why
A real GitHub repository you own, with CI/CD wired in. Every push runs the checks (typecheck, build, and a Lighthouse pass with high baselines for performance, SEO, best practices and accessibility) and previews automatically on the host. The build runs in CI, never on the edge host itself. You can take the repo and keep building.
The trade-off
Nothing important is hidden in a tool you cannot open, which is the point. The CI baselines are deliberately high, so a push that regresses performance or accessibility is caught before it ships.
The questions behind it
Do I get a real repo, or a black box?
A real GitHub repository you own, with CI/CD wired in. Every push runs the checks (typecheck, build, and a Lighthouse pass with high baselines for performance, SEO, best practices and accessibility) and previews automatically on the host. The build runs in CI, never on the edge host itself. You can take the repo and keep building; nothing important is hidden in a tool you cannot open.
The part you can't fake.
This is the part that makes a Palate build look unlike default AI output. The point of the product is the craft, so the build is wired to use it and is measured on whether it did.
Why ground every build in the reference library? Palate MCP Reproduce the craft layer faithfully, protect the identity layer absolutely.
Before writing any source, a build surveys the reference library over MCP: match the brief, search by facet, read references in depth, look at real inner-page screenshots. The doctrine is to reproduce the craft layer (grid, spacing rhythm, type scale, motion, signature moves) faithfully, since no one owns that, while protecting the identity layer (a brand's exact palette, wordmark, fonts, photos, copy) absolutely. Variety comes from choosing different references per build, not from averaging three into a blur, because averaging lands every build back on the same generic skeleton.
Reproduce faithfully
The craft layer: grid, spacing rhythm, type scale, motion, signature moves. No one owns that.
Protect absolutely
The identity layer: a brand's exact palette, wordmark, fonts, photos and copy. Never lifted.
How do you stop the agent from claiming depth it did not do? Hooks log real tool telemetry to a manifest; a gate reads the manifest, not the narration.
Lifecycle hooks record real tool telemetry to a manifest: which references were surveyed, which inner pages were viewed, which rich taste layers were actually read, which files were written. A depth gate then reads that manifest, not the agent's narration, and checks for genuine engagement: enough references surveyed, at least one deep read, at least one rich taste layer (the do/don't, the signature moves, the component prompts), a couple of inner pages, a spread of tools. The gates fail open on purpose, so a session whose MCP is not connected is never trapped, and enforcement is a nudge unless strict mode is turned on.
01 · logged
The manifest
Hooks record references surveyed, inner pages viewed, taste layers read, files written.
02 · checked
The depth gate
Reads the manifest, not the narration: enough surveyed, a deep read, a rich layer, a spread of tools.
03 · outcome
Fail open, nudge
A disconnected MCP is never trapped; enforcement is a nudge unless strict mode is on.
How do the AI tells get caught before they ship? A mechanical linter blocks the deterministic tells; an interpretive pass judges whether the layout is earned.
Two passes run before handover and again before production. A mechanical linter parses an anti-patterns file and blocks the deterministic tells: em dashes, banned display fonts, purple-to-pink gradients, the tired vocabulary (leverage, seamless, game-changer and friends), and a set of code smells. Then an interpretive pass reads the composition against its reference and asks whether the layout is earned, not just whether it matched a pattern. The honest limit is that regex is a floor, so a humanising pass goes over the copy for the things no fixed list can catch.
Why offer many variants up front? Eight to ten genuinely different directions, so the client points instead of everyone guessing.
A new site starts by generating eight to ten genuinely different home-page directions as real routes, surfaced by a small picker, so the client points at what they want instead of everyone guessing. No two variants may share a hero pattern, a section order or a density, and build memory actively pushes successive builds apart so they do not converge. The picked sections compose into the canonical page in the same project: the variants are the project at an earlier shape, not a separate fork. Generating that many is expensive up front; the payoff is no wrong-direction rebuild.
How is SEO and AI-crawler readiness handled? Per-page SEO in the layout, a sitemap, an AI-crawler allow-list and an llms.txt summary.
Per-page SEO is baked into the layout: titles and descriptions, canonical URLs, social cards, structured data, and a no-index flag on throwaway previews. There is a sitemap, and the robots file deliberately welcomes the AI crawlers (GPTBot, ClaudeBot, PerplexityBot) because this is public marketing content we want cited, plus an llms.txt summary written for them. CI holds a high SEO baseline. The allow-list is a posture choice that suits marketing copy, and would be wrong for gated content.
What about motion, do you use GSAP? GSAPLenisCSS Motion is chosen per build from the references and the brief, not one stack forced onto everything.
Motion is chosen per build from the references and the brief, not a fixed default. Because every site in the library has a scroll-capture and a motion analysis, the skill maps a reference's actual motion into your build, reaching for GSAP or Lenis when the brief calls for rich, scroll-driven work, and staying CSS-native when restraint is right. The template ships motion-ready either way, so it is the right motion for what you are building, not one animation stack forced onto everything.
Philosophy
Can I swap a piece? At the edges, yes. The spine (SSR, brand-as-tokens, library grounding, the gates) stays.
Mostly yes, at the edges. The host has a maintained Cloudflare path, fonts and the brand can be vendored instead of packaged, analytics has an alternative, a brochure site can go static, and a build editing an existing app skips the bits it does not need. What we do not swap casually is the spine: server-rendering, the brand-as-tokens contract, grounding in the library, and the gates. Those are load-bearing, and pulling one out tends to pull the value out with it.
Is this locked in? Deliberately. The lock-in is what makes the build repeatable.
Deliberately, and that is the point. The lock-in is what makes the build repeatable: the preview is the production codebase, grounded in the reference library, skinned from a versioned brand package, and verified by gates before anyone sees it. Substitute layers at random and you lose the property that any build comes out at the same standard. The flexibility is real but it lives in named flags and documented alternatives, not in improvising the stack each time.
Why so opinionated? Taste is a system, not a coat of paint. This page is that argument, in the open.
Because taste is a system, not a coat of paint, and a system you re-decide every project is not a system. Every choice here trades some flexibility for a pipeline that produces work of a known quality, defensibly, and at speed. Each decision was made against real top-tier references and written down with its reason and its trade-off, so it can be argued with rather than taken on faith. This page is that argument, in the open.
8 to 10
genuinely different home-page directions, up front
No two share a hero, an order or a density. You point at one rather than guess.
Set up your machine.
Two tiers: the minimum to connect and build, and the rest for shipping a full production site. The skill runs a preflight check that verifies all of it and tells you exactly what is missing, with the fix.
-
An MCP client
Claude Code, Cursor, Windsurf, VS Code, or Claude Desktop.
-
Connect Palate
One line in your terminal, a browser sign-in, no token. Other tools use a token from your dashboard.
-
Install the plugin
In Claude Code, two slash commands.
-
jq
The depth gate reads it. On Linux: apt-get install jq.
-
Node 22+ and npm
The build runs on Node 22 or newer; npm comes with it.
-
GitHub CLI, signed in
Install gh, then sign in. The build creates your repository and wires CI.
-
Vercel CLI, signed in
The default host. For the Cloudflare backup instead: wrangler plus a Cloudflare API token and account id.
-
A Sanity token
A Sanity account and a management token (SANITY_AUTH_TOKEN) for the CMS.
-
A Resend key (optional)
RESEND_API_KEY for form email. Forms are wired either way; the send needs the key.
-
Brand package access (optional)
A GitHub Packages token if you publish or consume the brand as a private package, or pass --vendor-brand to skip the registry entirely.
Or let Claude Code do it.
One paste, and it sets up everything it can itself, then hands you the exact browser sign-in and slash commands it cannot run for you.
Or let Claude Code do it
Set up Palate for me. Run everything you can yourself; for anything that needs me (a browser sign-in or a /slash command), give me the exact command and wait.
1. Check my machine and install anything missing: jq, the GitHub CLI (gh), and the Vercel CLI (npm i -g vercel). Confirm Node is 22 or newer.
2. Connect the Palate MCP:
claude mcp add --scope user --transport http palate https://mcp.palatemcp.com/api/mcp
Then tell me to run /mcp and sign in to authorise it.
3. Tell me to install the plugin (these are slash commands I run, not you):
/plugin marketplace add jake-jiffi/palate-marketplace
/plugin install palate-website-builder@palate
4. For a full build, check I am signed in to gh (gh auth login) and Vercel (vercel login), and list the tokens I still need: a Sanity management token, and optionally a Resend API key for forms.
5. Once I confirm the sign-in, verify it works by calling the refs_list_verticals tool.
Then hand me one line I can use to build my first site.Paste it into Claude Code. It installs what it can, then walks you through the browser sign-in and the two plugin commands it cannot run for you.
That is the how and the why. When you want the how-to, the docs are next.
Read the docs