Architecture, Cloudflare and the Legal Launch Gate

Overview

v1 said "launch 30 pages". v2 says launch 12 high-value assets — because 30 thin pages is a slower, more expensive way to learn the same thing, and because every published page carries a permanent compliance obligation.

This course builds the shared infrastructure once and uses it three times, then puts a hard gate in front of publication. The gate is not bureaucracy: it is the cheapest possible moment to catch a disclosure failure, an unlicensed claim or an unowned dataset.

4.1 What is the 12-asset MVP?

What is it?

The minimum publishable set for one site: 2 pillars, 3 money pages, 2 tools, 2 original data assets and 3 support pages. Twelve things that each justify their own existence — not thirty pages that collectively justify none.

Why it matters

Page count was a v1 proxy for effort in an era when volume correlated with visibility. In a zero-click environment it correlates with maintenance cost instead. Twelve assets is small enough to build to a real standard and large enough to test the thesis from Course 0.

How to do it

1. Take the funded topics from your Course 2 matrix. Every MVP asset must map to one, and any asset that maps to a displaced topic gets rejected or converted into a tool.
2. Allocate against the v2 content ratio: 20% informational, 30% commercial, 30% tools and templates, 20% recurring dated.
3. Write a one-paragraph specification per asset: who it is for, what it must let them do, what makes it non-replicable, and its maintenance cost per year.
4. Reject any asset whose maintenance cost you cannot fund for twelve months. An abandoned tool is worse than no tool.
5. Sequence them: support pages first (they gate everything), then tools, then money pages, then pillars.

12-asset MVP — allocation
2  Pillars            deep, genuinely referenceable, updated quarterly
3  Money pages        comparison / decision assets with disclosure
2  Tools              interactive, useful without reading anything
2  Original data      your own count, tracked over time
3  Support            about+ownership, editorial policy, disclosure/contact
                      -----
                      12 assets. Not 30 pages.

Tools needed

Your Course 2 funded-topic list, the unit economics tool for maintenance cost, and the blueprint.

Lab 4.1

Specify all 12 assets for site one. For each, write the sentence "an assistant cannot replace this because…". Delete any asset where you cannot finish that sentence honestly.

Artifact

MVP asset specification (12 rows)
  Asset | Type | Maps to funded topic | Non-replicability sentence
  Annual maintenance hours | Build sequence position

Common mistakes

• Filling the ratio with informational pages because they are the easiest to write and the easiest to displace.
• Building tools before support pages, so the first crawl finds monetised content with no disclosure or ownership page.
• Specifying assets with no maintenance budget, which quietly become liabilities by month nine.

Pro astuces

• The two original data assets are the highest-leverage items in the whole MVP. They feed the newsletter, the PR campaigns in Course 10 and the citations in Course 6.
• If the non-replicability sentence needs a qualifier like "well written", it is not a real answer. Originality of data, tooling or first-hand testing is.

4.2 What is the static stack on Cloudflare?

What is it?

Pre-built HTML served from a global edge with a repository as the source of truth: static files, a git-connected build, DNS and caching in one place, and no server to patch or pay for while traffic is small.

Why it matters

Course 0's cost model is dominated by fixed costs. A static stack pushes hosting close to zero at low traffic, which extends runway — and runway is what lets the Month 3/6/9 pruning gates be decisions rather than emergencies. It also makes the performance work in Course 5 tractable.

How to do it

1. Put everything in version control first, including content. If it is not in the repository it does not exist.
2. Connect the repository to Cloudflare Pages and confirm that a push produces a deployment you can preview before it goes live.
3. Configure the apex and www behaviour explicitly and pick one canonical host. Redirect the other permanently.
4. Set caching so HTML revalidates and fingerprinted assets cache long. Verify with response headers, not assumption.
5. Write the runbook: how to deploy, how to roll back, who has access, and where DNS is administered.
6. Repeat for sites two and three from the same template so the third takes an hour, not a week.

Tools needed

A git host, a Cloudflare account, DNS access for your domains, and a browser devtools network panel to verify headers.

Lab 4.2

Deploy site one end to end: repository, build, custom domain, canonical host redirect, cache headers verified in devtools. Then deliberately break a deployment and practise the rollback before you need it.

Artifact

Deployment runbook
  Deploy procedure | Rollback procedure (tested, with date)
  Canonical host decision + redirect verified
  Cache header table (path pattern -> observed header)
  Access list: who can deploy, who administers DNS

Common mistakes

• Never testing a rollback, so the first one happens during an outage.
• Serving both apex and www without a canonical redirect, splitting signals and confusing analytics.
• Registering domains on a personal account with no recovery path — a single-point-of-failure entry for the risk register.

Pro astuces

• Build site one as if it were a template. The compounding asset from Phase 1 is not site one's traffic — it is the speed at which site four could exist.
• Keep DNS and the registrar with different providers than your host where practical. It shortens recovery when one account is locked.

4.3 What is a shared component library?

What is it?

One set of markup and CSS components — header, disclosure block, comparison table, tool shell, ad slot, author box — used by all three sites, with per-site theming limited to tokens.

Why it matters

It is the mechanism that makes "launch three sites" affordable for one operator. It also makes compliance enforceable: if the disclosure block is a component, fixing it once fixes it everywhere, and no page can accidentally omit it.

How to do it

1. Build site one normally, then extract every repeated pattern into a named component with a documented purpose.
2. Restrict per-site variation to design tokens — colour, type scale, spacing — never to structure. Structural forks defeat the whole point.
3. Make the ad slot a component with reserved dimensions so layout shift is designed out rather than fixed later (Course 5 depends on this).
4. Make disclosure and author attribution components that a page cannot render without.
5. Keep an inventory: component, purpose, which sites use it, who owns it, last reviewed.

Component inventory — minimum set
  site-header / main-nav      shared, tokens differ
  disclosure-block            MANDATORY on any monetised page
  author-box                  MANDATORY on any editorial page
  comparison-table            money pages
  tool-shell                  consistent input/result/save pattern
  ad-slot                     reserved height, no layout shift
  data-table                  original data assets
  newsletter-form             consent copy is part of the component

Tools needed

Your repository, a plain component documentation page, and the launch checklists.

Lab 4.3

Extract eight components from site one and document each. Then build a page on site two using only components — if you need new markup, the library is incomplete and you should extend it rather than fork.

Artifact

Component inventory: name, purpose, sites using it, mandatory-on rules, owner, last reviewed

Common mistakes

• Copy-pasting site one into site two, which creates three divergent codebases within a month.
• Ad slots without reserved dimensions, guaranteeing layout-shift problems that are expensive to retrofit.
• Treating disclosure as page content instead of a component, so one page eventually ships without it.

Pro astuces

• Make the compliance components the hardest ones to omit. Design so the page looks obviously broken without them.
• Document the tool shell early — a consistent input/result/save pattern is what makes your tools feel like a product family rather than three unrelated widgets.

4.4 What is a portable data layer?

What is it?

Storing your original datasets in a plain, documented, exportable format that is independent of any vendor, any CMS and any single site.

Why it matters

Your original data assets are the part of the portfolio with the longest useful life. They must outlive the site that first published them, the tool that first displayed them and any platform you are currently renting. Portability is the difference between an asset and a lock-in.

How to do it

1. Define a schema per dataset before collecting anything: field names, types, units, and what "one row" means.
2. Record provenance on every row: source, collection date, collector, method. Undated data is unusable within a year.
3. Store as plain files in the repository — JSON or CSV — so the data is diffable, reviewable and never trapped in a database you cannot export.
4. Publish an export endpoint or download for readers. It is a citation magnet and it proves the data is real.
5. Version the dataset and keep the history. "How this changed over twelve months" is the story Course 10 pitches.

Dataset row — required provenance fields
  value fields...          (the actual measurements)
  source                   where it came from (URL or method)
  collected_at             ISO date — REQUIRED, no exceptions
  collected_by             person or script name
  method                   how it was measured, one line
  superseded_by            null, or the row that replaced it

Tools needed

A text editor, your repository, and the AI-surface tracking sheet as a worked example of a longitudinal dataset.

Lab 4.4

Model one of your two original data assets as a portable schema and collect the first ten rows by hand. Then export it and reimport it into a different tool to prove the portability claim is true rather than aspirational.

Artifact

Data schema + first 10 rows with full provenance + verified export/reimport

Common mistakes

• Collecting first and designing the schema later, which produces a dataset with inconsistent units and no dates.
• Keeping the only copy inside a third-party tool with no export.
• Overwriting rows instead of superseding them, destroying the time series that made the data valuable.

Pro astuces

• The single most valuable field is collected_at. It is what makes your data citable and what makes it perishable in the good way — a reason to come back.
• Publishing the raw dataset alongside the article increases the chance of being cited by both humans and answer engines, which is exactly Course 6's objective.

4.5 What is the legal launch gate?

What is it?

A mandatory pre-publication check that every asset must pass: claims sourced, disclosures present, licensing screened, reviewer assigned where required, and counsel questions either answered or the page held.

Why it matters

Publication is the moment liability attaches. Everything is cheap to fix before it and expensive after. The gate is also what makes the Course 2 compliance pre-screen operational rather than theoretical — it is where a "yes" answer actually stops something.

How to do it

1. Make the gate a literal checklist that a page cannot be merged without. Not a culture, a step.
2. Check claims: every factual or commercial statement has a primary source, an owner and a 90-day expiry logged.
3. Check disclosure: any affiliate, sponsored or commercial relationship is disclosed clearly and conspicuously, before the relevant content, in the reader's own line of sight.
4. Check licensing and regulated-advice exposure against your Course 2 pre-screen. If the answer is unresolved, the page is held — not published with a disclaimer bolted on.
5. Check attribution: named author, credentials where relevant, reviewer where required, and a dated last-review stamp.
6. Record the gate result per asset. A held page needs a written reason and an owner, or it becomes a permanent draft nobody revisits.

Tools needed

Claim register, counsel question sheet, reviewer register, launch checklists.

Lab 4.5

Run the gate against three draft pages, including one you were confident about. Record every failure. If nothing failed, your gate is too weak — tighten the claim check and run it again.

Artifact

Launch gate record (per asset)
  Claims sourced?      Y/N + claim register row IDs
  Disclosure present?  Y/N + where it appears relative to the content
  Licensing screened?  Y/N + counsel question IDs if any
  Attribution?         Author, credentials, reviewer, last-reviewed date
  Result: PUBLISH / HOLD (+ reason + owner + review date)

Common mistakes

• Running the gate after publication as an audit. By then the liability already exists and the fix is a correction notice.
• Disclosure in the footer or behind a link, when the relationship affects content the reader is reading now.
• Publishing with "we'll ask counsel later", which never happens once traffic arrives.

Pro astuces

• Batch the counsel questions. One paid hour answering fifteen specific written questions is dramatically cheaper than five separate consultations.
• A gate that never holds anything is decoration. Track your hold rate — a healthy one is not zero.

4.6 What is ownership and disclosure architecture?

What is it?

Making it plain who is behind the sites, that the three sites share an owner, how they make money, and who wrote and reviewed each page — as structure, not as a paragraph someone might read.

Why it matters

A three-site portfolio with a shared owner that cross-links and cross-recommends is exactly the pattern that looks manipulative when it is concealed and entirely legitimate when it is disclosed. Common-ownership disclosure is also the honest answer to the governing question: people come back to a brand they can identify.

How to do it

1. Publish an about page naming the real operating entity and the people, with a contactable address — not a form alone.
2. State common ownership explicitly on every site that cross-references a sibling, and label sibling links as such.
3. Publish an advertiser disclosure page describing every revenue source, and link it from every monetised page.
4. Publish editorial policy, review methodology and a corrections policy with a real corrections log.
5. Give every editorial page a named author with verifiable credentials, a reviewer where the subject requires one, and a last-reviewed date.
6. Mirror all of it in structured data so machines can read the same ownership and authorship you show humans (Course 5 implements it).

Disclosure architecture — page set and link rules
  /about                  entity, people, contact, COMMON OWNERSHIP statement
  /authors                per-author pages with credentials
  /editorial-policy       how content is produced and updated
  /review-methodology     how tools/products are tested and scored
  /corrections            policy + dated log of actual corrections
  /advertiser-disclosure  every revenue source, linked from monetised pages

  Link rules
  - Any page with affiliate/sponsored content -> disclosure ABOVE that content
  - Any link to a sibling site -> labelled as commonly owned
  - Any editorial page -> author box with last-reviewed date

Tools needed

Reviewer register, your corrections log, and the FTC guidance linked below.

Lab 4.6

Write the common-ownership disclosure and place it on all three sites. Then ask someone unfamiliar with the project to read any monetised page and tell you how the site makes money. If they cannot, the disclosure is not conspicuous enough.

Artifact

Disclosure architecture: 6 support pages drafted, link rules implemented,
comprehension test result (what the outside reader said)

Common mistakes

• Hiding common ownership while cross-recommending between sites — the combination that turns a legitimate portfolio into a credibility problem.
• A disclosure written to satisfy a checklist rather than to be understood.
• A corrections policy with an empty log after a year of publishing, which is not a sign of accuracy.

Pro astuces

• The comprehension test is the real standard. "Would a reasonable reader understand?" is the question that matters, not "did we technically state it?".
• Publish the support pages before the first money page. They are three of your twelve MVP assets for exactly this reason.

Scenario assessment: the launch that skipped the gate

Under pressure to hit a launch date, a publisher ships 14 pages on the B2B SaaS site. Eleven are comparison pages with affiliate links; disclosure appears only in the site footer. Three pages cite pricing figures taken from an AI assistant with no primary source. Two link to the sibling finance site as a "recommended resource" with no ownership statement. Traffic arrives, an affiliate program sends a compliance notice, and a competitor publicly points out the undisclosed common ownership.

Final project: site one, live and gated

One deployed site, twelve specified assets, a component library the next two sites will reuse, and a gate that has actually stopped something.

Deliverable
1. MVP asset specification: 12 assets with non-replicability sentences and maintenance hours
2. Site one deployed on Cloudflare Pages with a tested, dated rollback
3. Component inventory of at least 8 components, with mandatory-on rules
4. One original dataset with a documented schema, 10 provenance-complete rows and a verified export
5. Launch gate record for at least 3 assets, including at least one HOLD with a written reason
6. Six support pages drafted, common-ownership disclosure live on all three sites
7. Comprehension test result from an outside reader

Pass standard: a stranger can tell within thirty seconds who runs the site and how it makes money, and your gate record shows at least one page you chose not to publish.

Course 4 checklist

• 12 MVP assets specified, each mapped to a funded topic
• Every asset has an honest non-replicability sentence
• Content ratio respected: 20 / 30 / 30 / 20
• Site one deployed from version control with preview builds
• Canonical host chosen and the other permanently redirected
• Rollback tested and dated, not just documented
• At least 8 shared components extracted and documented
• Ad slots have reserved dimensions in the component itself
• Disclosure and author boxes are mandatory components, not page content
• Dataset schema defined before collection, with collected_at on every row
• Export tested by reimporting into a different tool
• Launch gate run on 3 pages, with at least one HOLD recorded
• Counsel questions batched and logged rather than deferred
• Common-ownership disclosure live on all three sites
• Outside reader passed the "how does this site make money" test

AI-agent prompt for Course 4

Act as a technical architect and pre-publication auditor for a three-site publishing portfolio under common ownership.

I will paste: my funded-topic list, my niche scores, my draft page list, and my monetisation methods per site.

Do this:
1. Allocate a 12-asset MVP for each site: 2 pillars, 3 money pages, 2 tools, 2 original data assets, 3 support pages. Map every asset to a funded topic and reject any that maps to a displaced one.
2. For each asset write the sentence "an assistant cannot replace this because...". Flag every asset where that sentence needs a quality qualifier rather than originality, tooling or first-hand testing.
3. Verify the allocation against the content ratio 20 informational / 30 commercial / 30 tools and templates / 20 recurring dated. Report the variance.
4. Propose a shared component inventory and mark which components must be MANDATORY on which page types.
5. Design a portable schema for each original dataset, including provenance fields, and state what "one row" means.
6. Build a legal launch gate checklist for my specific monetisation methods, with a PUBLISH/HOLD decision line per asset.
7. List the disclosure architecture pages I need and the exact link rules between them.

Rules:
- Do not state hosting limits, platform pricing, build settings or free-tier boundaries as facts. Output each as a claim row: claim, why it matters, primary source to check, owner, 90-day expiry.
- Do not give legal advice or state what any law requires. Output legal issues as specific written questions for counsel, grouped so they can be answered in one session.
- Assume disclosure must be clear and conspicuous and placed before the content it affects; flag any layout where it would not be.
- If fewer than 2 assets per site are genuinely original data or tooling, say the MVP will not survive zero-click and propose replacements.
Output as tables.

Primary sources

• FTC endorsement, influencer and review guidance — the primary source for disclosure placement and clarity.
• Creating helpful, reliable, people-first content

Platform documentation changes constantly. Verify hosting, DNS and build details against the provider's live documentation and log what you rely on with a 90-day expiry.