Sites and Pages
A Site is the Pages, navigation, and Brand of a Startup, held as records and compiled from its definition, so every Page says only what is true.
A Site is everything a Startup serves on the web: its Pages, navigation, and Brand, on one or more Domains. Every part is a record, so the Site changes the moment its data does.
A Site is records, not files
Take permitfeed.com, a Startup that sells building permit records as a Dataset API. Its Site holds a home Page, pricing, docs, and the legal Pages, and none of them is an HTML file. Each is a Page record that names a Template, the Components it places, and the Content that fills them.
A request for permitfeed.com/ resolves the Domain to the Startup, reads the Page, and renders it. The prices on that Page are not copied text. They are the Price of each Offer, read at render, so changing a Price changes every Page that shows it.
The same rule holds for every claim: a claim with no record does not render. Social proof follows it too. Customer counts and quotes render from payments, usage, and Evidence, and with none they hide.
No Site shows social proof before it is Live.
Compiled from the definition
A new Startup does not start from a blank Site. SiteBuilder compiles the first draft from the founding Hypothesis: the customer story for each ICP, the Problem it names, and the Offers that answer it. Every block records where it came from:
page: /
component: Hero
props:
headline: Every permit filed in 400 counties,Lineage makes a pivot legible. When the Startup revises its Problem slot to version 5, SiteBuilder lists every block compiled from version 4 and proposes the rewrite as one Change. The owner reviews a diff, not a new Site.
After the first compile, Pages are records that Agents and people edit through Changes. Nothing regenerates a Page on request, and a recompile proposes a Change; it never overwrites an edit.
Pages have kinds
Every Site serves a home Page, /pricing, /terms, /privacy, and /security, plus the machine registers covered in the publishing chapter. The legal Pages render from Templates chosen by the kind of Startup, so a marketplace and a Dataset API get different terms. Beyond these, each Page has a path and a kind, and the kind decides its shape:
| Kind | What it is for | Opens with |
|---|---|---|
landing | Turn a Visitor into a Customer | A hero with the primary call to action |
pricing | Show every Offer and its Price | The Offers, side by side |
comparison | Answer "this or that" searches | A table against the alternatives |
article | Answer one question for search and answer engines | The answer, in the first paragraph |
docs | Explain how to use a Product | A one-line definition, then code |
agent | Route an Agent to an operation | Structured data, with minimal chrome |
terms, privacy, security | State the legal and security terms | The terms themselves |
A Page about one record, such as a county in a permits catalog, can instead stand for every member of a Collection. One Page record then serves one address per member.
The page spine
Landing, pricing, comparison, and article Pages share one spine, in this order:
- A header with the Brand and a call to action that stays visible at every scroll depth.
- A hero: headline, subhead, and the primary call to action.
- The problem and the approach, side by side.
- Who it is for.
- What the buyer gets: the outcome or the output, stated as a contract.
- Pricing, read from the Offers.
- Questions and answers.
- A closing call to action.
- A footer with the legal links.
The last three never move. The questions answer the final objections, such as data handling and refunds, and the closing call to action catches the convinced buyer. Trust lives in those answers, not in a band of badges.
On a phone screen 360 pixels wide and 640 tall, the headline, subhead, and primary call to action appear without scrolling. The renderer checks this on every Page before it serves.
Copy only this Startup could publish
Generic copy fails a buyer twice: it says nothing, and it reads like every other Site. So every Page passes five checks before it publishes:
- Interchangeability. Swap in a competitor's name. If the Page still reads true, it fails.
- Look. Swap in a sibling's Brand. If the Page still reads as the sibling's, it fails.
- The buyer's world. The Page names a real artifact of the buyer's work: the permit number, the claim form, the chart note. Placeholders such as "your workflow" are defects.
- Numbers. Every number is computed from a record or left out. No Price is "illustrative".
- No internals. Field names and enum values never render as copy.
Two Startups built from the same Startup Template differ in every visible block where their definitions differ. Guards run these checks on each Change, and a failure names the block and the rule.
Who builds a Site
Two Roles own a Site. The Designer keeps the design system and checks every Page for accessibility. The Content Lead writes the Pages that search engines and answer engines cite.
An Agent, a Human, or both hold either Role. Every edit arrives as a Change with its author recorded.
Next
- Design system: how Components, Themes, and Templates render a Page.
- Brand: the identity every Page reads.