North Star Template v1.1

Hero · cold open

logo-band

Instruction Their logo on the dark shell, top band, nothing else in the band. Use the variant that survives a dark background. If the only logo you have is a light-background lockup, extract or request a version that works here rather than shipping a muddy one.

Check it at 390px wide, not just on your monitor.
The client's brand colours appear ONLY in their logo and the palette swatch. Never as page styling.
The byline is "Prepared by SwarmSystem", here and in the footer. Never "Day by Day Digital". Standing rule, operator, 2026-08-03. SwarmSystem is the name the client bought and the name on every deliverable. Day by Day Digital is the company behind it and belongs only where the legal entity actually matters: terms, privacy, and copyright lines.

Client logo goes here

boot-check

Instruction Four or five rows that flip to DONE with REAL count-ups as the page opens. These are the first thing the client sees and they are a claim of competence, so every number must be one you actually counted.

Good rows: files received, products or pages counted, images held, towns targeted.
Never a number you estimated. Never a number you cannot show the source of.
Under reduced motion these render already DONE with final values.

Boot-check rows go here

headline-quote

Instruction Their single strongest verbatim quote from the call, as the page headline. Not a summary of it. Not a cleaned-up version. The sentence they actually said.

Pick the one that names what they want the business to feel like, not the one about budget.
Follow it with one plain line: we heard you, here is everything we are building from.

Strongest verbatim quote goes here

dated-promise

Instruction One line naming a real date. This is the promise the design reveal has to keep, so pick a date you will hit.

Name the day, not a duration. A named Friday beats "in about a week".
This date becomes rung 2's deadline. Do not set it casually.

Dated promise line goes here

Act I · listening

What you told us

billboard-quote

Instruction Their second-strongest quote, set large as a billboard. Test it: does it still work at 80px type? If it needs context to land, it is a card, not a billboard.

Billboard quote goes here

quote-cards

Instruction The remaining verbatim quotes as cards. Every card carries the quote AND one line saying what we do with it. A quote with no consequence is decoration.

Every quote comes from ONE real transcript. Never invent a second call link.
Never quote from memory. If you are not certain it is verbatim, drop it.
Attribute each one: name, onboarding call, date.

Quote cards go here

call-link

Instruction One card linking the call recording, with its date and running time. This is what makes every quote on the page checkable in one click, which is the whole point.

Inline play glyph as SVG. No third-party assets.
target="_blank" rel="noopener".
Verify it returns 200 before you ship. A dead recording link discredits every quote above it.

Call recording link card goes here

quote-count

Instruction The count, computed not typed: how many of their sentences this build works from. Compute it at build time from the rendered cards so it can never drift from what is above it.

Computed quote count goes here

Act II · possession

What we have

brand-kit

Instruction What of their brand has actually landed, counted. Files, lockups, the guide, the fonts named in it. Then the open brand items in plain words.

If the guide is a PDF, say how many pages and what is in it. If assets had to be extracted from it, say so.
Name the fonts the guide specifies AND the fonts the live site actually uses. When they disagree, that gap is a finding worth showing.

Brand kit summary goes here

palette

Instruction Their palette as swatches, kit-true colours ONLY. Read the hex values off the brand guide, do not eyedrop them off a screenshot.

Colours the guide does not contain do not belong in this block. They go in color-rules below, under the proposed heading, never mixed in with the exact ones.
This component and color-rules are the ONLY places their brand colours appear on this page.

Palette swatches go here

type-system

Instruction The full type system, with specimens a client can read rather than a list of font names. Most brand guides name the logo fonts and stop, which leaves the question they actually care about unanswered: what will the words on my site look like.

Say plainly whether the logo fonts can carry body copy. Usually they cannot. Display faces are drawn to be seen big; set a paragraph in one and people stop reading. Naming this is the whole reason the block exists.
Propose exactly two faces. One for headlines that looks related to the logo without copying it, and one that does the reading work. The brief is complement, not match.
Check what their current site actually uses, live, and name it. When a client says they hate their current site, the type is usually part of why, and they often cannot name it themselves. Never propose a face their current site already uses.
Specimens must render in the real proposed faces, loaded on the page. A specimen that silently falls back to a system font is a lie told in the client's own brand. Verify with document.fonts.check() AND a computed-style probe on each specimen, never by eye.
Show at minimum: headline, subtitle, body paragraph, small print, button label. Give the size and weight for each, at desktop and at phone.
Write the specimen copy from THEIR real facts, not lorem ipsum. A client reads their own warranty in their own new type and understands the proposal instantly.
The client's faces stay inside the specimen panel. The rest of the page stays on the SwarmSystem brand.

Type reasoning, then the rendered specimen panel, then the size and weight table

color-rules

Instruction Every colour, in two clearly separated groups, each with a usage line. This is the half of a brand guide that decides whether the build looks like them or like us.

Group one: from their guide, exact. Group two: proposed by us, labelled as proposed on the page itself. Never let a proposed colour read as though it came out of their guide.
When they named a colour on a call that the guide does not contain, propose a real hex rather than asking them for one. "Send us your codes" is an ask that sits unanswered for weeks. "Approve these or send yours" is a two-minute decision. This rule exists because the send-us-your-codes version was tried and went unanswered.
Every colour gets one plain line saying where it goes AND where it must not. A colour with no usage rule gets used everywhere and stops meaning anything.
Carry any colour they ruled out on the call. If they said no black backgrounds, the dark neutral in this block is the answer to that, and say so.

Two labelled colour groups, then one usage line per colour

access-checklist

Instruction Every account and asset, with a state dot, and each row naming in plain words what it unlocks. Not a list of logins, a list of what becomes possible.

States are the plain four: WAITING, WORKING, DONE, LIVE.
Word the asks generically. No email addresses on the page.
Standing rule: never assert a client failed to deliver something on the strength of an empty search result. Search indexes lag. Read the container directly, or ask. Getting this wrong sends a client a page accusing them of not doing something they already did.
Anything genuinely unconfirmed stays off the page in both directions. Do not assert it is missing and do not assert it is held.

Access checklist goes here

inventory-or-audit

Instruction The proof-of-possession act. It branches on what the client actually owns.

Product or rental client: their inventory pictured and counted, in strips ordered by THEIR revenue priorities as stated on the call. Count chip per category. Lazy-loaded images with product-name alt text.
Service client: an honest count of their existing website instead. Pages and posts from the sitemaps, service URLs, city pages. Include the defects you found while counting with full clickable URLs: misspelled slugs, duplicate pages, doubled contact or thank-you pages. Also list the pages they named on the call that do not exist.
Naming their real broken things, specifically enough to click, buys more trust than any claim about our capability. It also proves we looked, which is the job of this page.

Inventory strips or site audit goes here

possession-counts

Instruction The act's closing numbers, computed at build time from the rendered blocks above. Never a hardcoded total.

Computed possession counts go here

Act III · understanding

Who and where

audience-cards

Instruction Who buys from them, in plain words the client would use with their own crew. Two or three cards.

Never the words SEO, conversions, or funnel anywhere a client can read them.
Say booked jobs, not conversions. Say missed calls, not lost leads. Say where you show up when someone searches, not rankings.
Fifth-grade rule: if a tradesperson on a job site cannot read it in three seconds, rewrite it.

Audience cards go here

psychographics

Instruction Answer these from your own transcript. They are elicitation prompts on purpose: there is no example answer here to bleed into your client's page, and a borrowed psychographic is worse than none.

What did they say costs them money when it goes wrong?
What did they say they are tired of?
What did they name as the moment a customer picks up the phone?
What did they say they do not trust, or have been burned by before?
What does their buyer already believe before they arrive at the site?
What would make their buyer close the tab?

If the transcript does not answer one of these, leave it out. Do not fill it with a plausible guess.

Psychographic answers go here

sitemap

Instruction The full proposed sitemap as a grouped route list, with a per-group count and one computed total.

Group it the way the site will actually be built: core, services, areas, trust, utility.
The total is computed from the rendered list, never typed.
This list is the contract for the rollout stage. No page gets built later that is not on it.

Grouped sitemap goes here

menu-visual

Instruction The main menu as a semantic nested list, styled with CSS grid. Zero JavaScript, zero external libraries. Every top-level item carries THREE why-lines: one for the human, one for the machine, one for the contract.

Why it converts names what the visitor is trying to do at that moment.
Why a machine can read it names how an agent or an assistant parses that branch to answer a question about this business.
What it actually is names the scope. Every branch carries data-scope and a visible tag, traced to the signed proposal: build, split, plan, or later. The receipt fails the page if a single branch is untagged.
Keep it a real <ul> of <li>. The nesting IS the information architecture, and it is what a machine reads when styling is stripped away.
Plain-language labels beat clever ones on every measure. Name the thing the visitor came for.

Read the signed proposal before you draw this menu, not after. A menu is the most promise-dense object on the page: a client reads a branch as a page they are getting. Juan & Only shipped a draft whose menu offered five pages his build had never bought, including three the repricing had explicitly removed. Nothing else on the page contradicted it, because nothing else on the page knew what he had signed. If a branch is not in the build, it still belongs on the map, tagged and said out loud. Dropping it silently is worse: the client named it on a call and will notice it missing.

The scaffold below is structure only. Replace every label with theirs.

Menu item one In this build
- Child route
- Child route
Why it convertsWhat is the visitor trying to do here?Why a machine can read itWhat question does this branch answer about the business?What it actually isWhich line of the signed proposal pays for this branch?
Menu item two Part on the plan
- Child route
- Child route
Why it convertsWhat is the visitor trying to do here?Why a machine can read itWhat question does this branch answer about the business?What it actually isWhich line of the signed proposal pays for this branch?
Menu item three Not in this build
- Child route
- Child route
Why it convertsWhat is the visitor trying to do here?Why a machine can read itWhat question does this branch answer about the business?What it actually isWhich line of the signed proposal pays for this branch?

cro-patterns

Instruction Every pattern you claim carries two sources. One external published study explaining why it works, with its year. One internal receipt proving we did it on a real build, with its path or URL. A pattern that cannot get both is cut, not softened.

Single-source claims do not ship. Two of our own receipts is still one source.
Name the publication year on the page so a reader can judge recency themselves.
Registry to pull from: docs/output/website-build-playbook/cro-evidence-registry.md, which carries 13 sources across 7 groups, all checked live.

Pattern	Tier 1 · published source + year	Tier 2 · our receipt
Pattern one	Source, URL, year	Build, path or URL
Pattern two	Source, URL, year	Build, path or URL
Pattern three	Source, URL, year	Build, path or URL

ai-seo-link

Instruction Link the AI readiness playbook and say in one plain sentence what it does for them: it is how the site gets built so that assistants and search engines can read the business correctly from the first line of markup, rather than being retrofitted afterwards.

Live at seo-ai-playbook-preview.netlify.app. Verify it returns 200 before you ship.
Say what it means in plain words. Do not paste the technical scope onto a client page.

AI readiness playbook link goes here

reference-examples

Instruction The reference sites they named on the call. Never sites you picked for them. Each one is a new-tab card carrying the site name, a link, and one line on what specifically they liked about it in their own words.

Two is the floor, and it is enforced. This block does not count as filled below two entries, and the counter under it says so out loud. One example is a preference. Three or more is a mood board, which is noise. Two is a vector: it has direction and magnitude, which is what a design brief actually needs.
Mark each entry with data-entry so the count below stays computed rather than typed.
Quote them. A paraphrase loses the thing that makes it usable.
Say which direction each one feeds. If a reference feeds nothing, it is decoration, so cut it.
Some reference sites block automated fetching and still open fine in a browser. Open every one by hand before you cite it. Do not promise the client a screenshot pass you cannot run.

0 of 2 minimum entries present

Reference example cards go here, each marked data-entry

design-negatives

Instruction What it must not look like, in their words. This half of the brief is the half that gets skipped, and it is the half that prevents a rebuild.

Only what they actually said. A negative you inferred is a guess wearing a quote mark.
Include the negatives they aimed at their own reference sites. A client who names a site and then names what is wrong with it has handed you the gap between the two examples.
Carry every one of these into both directions. A direction that violates a stated negative is dead before it is read.
If they stated no negatives, write that plainly here and go back and ask. An empty negatives block is a signal, not a finished block.

Stated negatives go here

direction-a

Instruction The primary direction, text only. No mockups, no screenshots, no colour studies. This page is not a design preview.

Name it from THEIR language on the call, never an invented style label.
Anchor it to a reference site THEY named, as a new-tab card, and say what specifically they liked about it.
Carry every constraint they stated as a negative.

How many directions you promise is set by the signed proposal, not by this template. Read the design line item before you write either block. A build priced for one direction and a page promising two is the same defect as a menu offering unbought pages, except it also breaks a number the client already agreed to.

The primary direction goes here

direction-b

Instruction If the proposal pays for two directions: direction B, same rules. It must be a genuinely different bet, not a colour variant of A. If you cannot say in one sentence what choosing B costs them that A does not, they are the same direction twice.

If the proposal pays for one: this block carries the reason there is one, in the client's own interest and in plain words. Name the trade that bought the price, name what did NOT come out of it (the review rounds are usually the answer), and say what happens if the single direction misses. A client who sees one direction with no explanation assumes something was taken from them. A client who reads the trade in writing sees a decision they made.

Direction B, or the reason there is only one, goes here

Act IV · plan

The road

scope-recap

Instruction The signed proposal, recapped on one screen. Two columns, both required (the floor below is enforced): what the build they approved covers, and what was held back with what it is worth. A recap showing only what was bought is half a truth, and the half it hides is the half that makes the client feel taken from.

Open the proposal and read it before writing this. Not the memory of it, not the deal notes. The file the client received. Prices get renegotiated and scope moves with them, and the version in your head is usually the version before the last call.
Carry the total, the payment split, the page count, and the number of review rounds. These are the four numbers a client checks a build against.
Say the page count twice and mean two different things: addresses audited and pages in the new build. They are rarely equal, and a client who sees one number in the proposal and a different one here stops trusting both documents.
Held-back work keeps its price. "Free" means nothing without a number next to it.
Link to the live proposal so the recap is checkable in one click, exactly like every other claim on the page.
Anything anywhere on this page that the proposal does not pay for is either tagged as out of scope or deleted. This block is the reference the rest of the page is checked against, so build it before the sweep, not after.

Placed in Act IV because it frames the road. The client reads what they bought, then reads the dates that deliver it.

0 of 2 minimum columns present

Two columns go here, each marked data-entry: what the approved build covers, and what was held back with its price

timeline

Instruction Named dates with a countdown chip on the next one. Every row is a day of the week and a date, not a duration.

The first row is the dated promise from the hero. They must match.
Set dates you will hit. This page's whole job is buying design time honestly.

Dated timeline goes here

conditionals

Instruction What is conditional, stated honestly, with what it depends on. If a launch date depends on assets you do not have, that belongs here in plain words rather than as a footnote.

Conditional items go here

asks

Instruction Three asks maximum. Each one a concrete two-minute action.

Fewer asks get answered. A list of eight gets none.
Every ask also rides the email, so the send unblocks the build.
Never ask for something they already sent. Check first.

Up to three asks go here

nothing-to-approve

Instruction The closing line: nothing to approve today. Say it plainly and mean it. This page is not a review cycle. It removes a decision rather than adding one, and that is why it buys the time it buys.

Nothing-to-approve line goes here

Before you deploy

The gates

All hard. No exceptions.

Claim audit. Walk every sentence on the page. One click or one count. If it is neither, rewrite it or cut it.

Previous-client scrub. Grep the file for every prior client name, town, and brand colour. Zero hits.

Token scrub. Zero unfilled placeholders. Zero em dashes and zero —. Fix by hand, never bulk-sed.

Plain language. Zero instances of the three banned words in anything a client reads.

Brand. SwarmSystem tokens only. Their colours live in the palette component and their logo, nowhere else. State words are the plain four.

Render. True 390 device metrics first, then 1440. Zero console errors at both. No horizontal scroll at either.

Motion. Reduced motion loses nothing: every state resolved, every number final.

Links. Every external link carries rel="noopener" and returns 200.

Operator gate. Justin signs off the email. His send is the trigger. Nothing on this ladder reaches a client without it.

A blank template that ships is worth more than a filled one that does not pass these.

TEMPLATE SELF CHECK: 0 OF 0 BLOCKS FILLED · 0 TOKENS · 0 EM DASHES · 0 CONSOLE ERRORS · PASSED

The block count and the fill count are computed on load. A blank template reads zero filled, which is correct. As you fill slots the meter climbs.