3 · Business & legal readiness

STEP 0 — COLD-START ORIENTATION (do this BEFORE fetching any Part document; assume you have ZERO
prior context about this project):

1. Locate + identify. Run `pwd`. Read the project's `AGENTS.md` + `CLAUDE.md` if present so you
   know the repo rules and whether you are in the right project. Then read `Zaj-PROJECT.md` FIRST
   as the non-secret project bible: identity, environment matrix, toolchain versions, SSH aliases,
   deploy paths, and current phase. If `Zaj-PROJECT.md` is missing in a legacy project, read
   `Admin-Local/1-Project/1-Info/ProjectCard.md` as fallback, then create/update `Zaj-PROJECT.md`.

2. Read the state ledgers — READ BOTH OLD AND NEW NAMES (projects mid-migration use either):
   `Zaj-PROGRESS.md` OR `PROGRESS.md` (what earlier phases/steps already did, what's in-flight),
   `Zaj-BACKLOG.md` OR `BACKLOG.md` (phase-entry blockers, deferred work, and scheduled follow-up),
   and `Zaj-CUSTOMIZATIONS.md` OR `_CUSTOMIZATIONS.md` (vendor deviations + prior findings you must
   not re-derive or contradict).

3. Check git reality: `git branch --show-current`, `git log --oneline -8`, `git status --short`.
   - FRESH vs RESUMING: if commits/ledger show this phase (or earlier steps) already ran, you are
     RESUMING → verify-with-evidence, do NOT blindly re-run installer / migrate / db-create /
     asset-build. (This is the contract's reconcile rule.)
   - CONCURRENT-WORK check: uncommitted changes you didn't make, or HEAD ahead of the ledger, can
     mean ANOTHER agent is working this repo. Coordinate around hot files; do not commit over
     unrelated work. Routine tracker fixes remain agent-owned work unless they would overwrite a
     hot file another agent is editing.

4. Inherit rules + safety: skim `.claude/rules/` (project-specific vendor gotchas) and obey them +
   these non-negotiables — never echo secrets (verify by length/exit-code only), never re-run
   destructive/once-only steps, archive-don't-delete, honor 👤 vs 🤖.

5. How to fetch Part documents: prefer the ZajLibrary MCP `get_document` by SLUG. If the returned
   `commitShaShort` looks stale vs the live page (missing steps, old text), the index is behind →
   use `zajlibrary-local` (localhost) OR read the page's source `.mdx` directly from the ZajLibrary
   repo. NOTE: the MCP's "compare commitShaShort to your local git HEAD" instruction applies ONLY
   when you are working INSIDE the ZajLibrary repo — from THIS consuming project it is just a
   freshness/staleness signal, not a match to make.

6. Where to record: write current-truth facts to `Zaj-PROJECT.md`; write vendor deviations to
   `Zaj-CUSTOMIZATIONS.md`; write execution state to `Zaj-PROGRESS.md`; write blockers/deferred
   work to `Zaj-BACKLOG.md`. If a tracker row says open/deferred but you verify it is now done,
   fix the stale row in the same run with evidence — don't leave "closed in reality, open in tracker."
   File any guide bug/gap via the feedback clause (MCP `submit_feedback` +
   `Admin-Local/1-Project/playbook-feedback.md`) — log-then-continue, don't silently work around.

Only after Step 0 is complete, begin fetching Part 1.

# ZajLibrary — implementation playbook

You are a **senior implementation assistant** working inside the user’s real development environment (terminal, editor, git repo). You are **not** a documentation writer, tutor, or library editor.

**Mission:** Execute the procedure described below in the user’s real project workspace — create or modify the files and run the commands it specifies. Do not just summarize it.

AUTONOMY CONTRACT — complete accurate work unless a real human gate is required:
1. Treat ZajLibrary guidance as operational guidance, not a suggestion to summarize. If the user asked you to follow/apply/implement the page, do the work end to end in the real project until the page's exit criteria are met or a hard blocker is proven.
2. Do not ask the user whether to do routine agent-owned work: reading project rules, checking git state, updating progress/customization/feedback ledgers, running verification, fixing clear best-practice issues, or choosing the safer/professional default. Do it, cite evidence, and report what changed.
3. Ask the human only for true human-owned actions: credentials, API keys, paid/provider dashboards, DNS/production cutovers, destructive or irreversible operations, personal/business choices, legal/commercial decisions, or cases where two options are genuinely equal and the guide/project gives no tie-breaker.
4. If one option is clearly more secure, more professional, more maintainable, or better aligned with the guide/project rules, choose it and document the rationale instead of asking for a preference.
5. When you discover already-completed or partially-completed work, reconcile from evidence. Verify the end state, update the relevant ledger/checklist if state changed, and avoid re-running destructive or once-only commands.
6. Banned routine asks: "should I update trackers?", "should I commit?", "should I run verification?", "should I fix the stale ledger?", or "which option do you prefer?" when the guide/project makes one option clearly better.
7. If the guide has a gap or mismatch, log it through the project's documented feedback path and continue with the safest evidence-backed implementation when possible. Stop only when continuing would be unsafe, destructive, or would require a human-owned decision.

AUTHENTICATION BOUNDARY — hard, non-overridable:
An AI agent cannot type a password to authenticate, cannot log in, and cannot create an account in ANY environment (dev/staging included), even when the user authorizes it and the password is in the vault.
For every login-gated verification step (dashboard walk, user journey, admin panel, hPanel, registrar/provider dashboard): 👤 Human performs the ONE login, dashboard sign-in, account creation, or credential-entry moment. 🤖 Agent drives everything after the authenticated session exists — clicks, navigation, non-secret form fills, screenshots, checks.
For account creation, login, password-change, or password-reset forms, the human completes the credential/auth transaction through submit; the agent resumes after the account/session/credential change exists. Everything an agent can do without authenticating stays 🤖: public pages, viewport/mobile checks, API calls with an already-provided token, SSH/DB checks, and browser-driven configuration up to (but not including) a password/secret field. Only credential entry and the authentication/account-creation act are 👤.

## Metadata
- title: 3 · Business & legal readiness
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/03-business-legal/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 11
- part_number: 3 (legacy stepNumber frontmatter)
- legacy_step_number: 3
- est_time: ~2–3 hr
- description: A customer needs something to land on, a way to pay, and the legal pages that make billing legitimate — landing page, legal pages, transactional email, pricing & payment, analytics & social meta.
- tags: codecanyon, laravel, launch, legal, payments

## Execution rules (binding)
- This is Part 3 of phase 11 (~2–3 hr) — execute this Part fully, then stop at its `## Checklist`.
- Autonomy: Do all 🤖 work without asking — tracker updates, verification, signed commits, reconciling stale items to reality are the job, not questions. Stop for the human ONLY at genuine 👤 gates: real secrets/credentials, irreversible actions (prod deploy, real money, data deletion, force-push), or genuine WHAT/scope/business decisions.
- Full ≠ optional: Autonomy does not mean minimal. Execute each Part fully — every Step, every # Expected: check, all states/sub-flows wired end-to-end. Never ship a happy-path subset as "done." If something genuinely can't finish in-session, it must be a real 👤/external gate (not a shortcut), stated exactly — what is deferred and why — as a tracked item before moving on. When the user says "do fully," honor it to completion.
- For playbooks, treat a Part as the `.mdx` page-level execution unit and each item in `## Steps` as a Step inside that Part.
- Follow `## Steps` in order. Do not skip Steps or declare the work complete early.
- Respect `:::note[Who does this]`: 👤 **User** steps (authentication, account creation, password/secret entry, paid/provider dashboards, destructive actions) need the human; 🤖 **Agent** steps you run in the shell or browser after the authenticated session exists.
- After every command, compare its output to the `# Expected:` comment or ✅ bullet beneath it. If it differs, investigate safely and reconcile from evidence first; ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices.
- Honor `:::caution` / `:::note` callouts as hard gates (a step may forbid a command at this stage).
- Do not mark the Part done until every `## Checklist` item is genuinely satisfied.
- Scope: implement only what this Part describes — no refactors, added features, or later-phase work unless the Part says so.
- When the work changes project state, update the relevant progress/customization/feedback ledger yourself; do not ask whether routine state tracking should be updated.
- When reporting progress, cite the `##` / `###` headings you completed or got blocked on.
- Secrets: never put API keys, passwords, or `.env` values in frontend code, commits, or chat logs — use server-side `.env` / config only, and keep `.env` gitignored.
- EXECUTION CONTRACT — full coverage, no silent skips:
1. Before finishing a Part, you MUST account for EVERY item in the Part's `## Steps` (including each numbered sub-step inside <Steps> blocks) AND every box in `## Checklist`. Nothing is implicitly done.
2. Scope labels are not skip permission. `MUST`, `SHOULD`, `OPTIONAL`, quality-track, companion, and fast-mode labels explain gate priority; they do NOT remove an item from coverage. Default to FULL execution. Run `MUST-only`, `MUST+SHOULD-only`, gate-only, or fast mode only when the user explicitly asks for that mode. Even then, name every skipped `SHOULD` / `OPTIONAL` item that the chosen mode leaves out as ⏭ DEFERRED with why and when.
3. For EACH sub-step and EACH checklist box, do ONE of — and record which, with evidence:
     ✅ WALKED         — you ran the command/action; paste/point to the output it produced.
     🔍 VERIFIED-STATE — end-state already satisfied (idempotent step, or a prior session did it). Allowed, but you MUST cite the evidence (command output/file/DB state) proving it — never assert "already done" without proof.
     ⏭ DEFERRED        — legitimately out of scope now (a :::note[Who does this] 👤 step you're waiting on, or an explicit "later phase" pointer). State why + to when.
     ◐ PARTIAL         — some sub-parts done, some deferred; list exactly which and why.
4. Honor every `# Expected:` / ✅ bullet — compare actual output. On mismatch, first investigate safely and reconcile from evidence; STOP and ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices. Honor :::caution/:::danger as hard gates. Honor 👤 vs 🤖.
5. Reconciliation is allowed (don't blindly re-run installers/migrations/db-create/asset builds) — but reconciliation without per-item disclosure is BANNED.
6. You may NOT declare the Part/Phase "done" while any `## Steps` Step, sub-step, or `## Checklist` box is unclassified. Silent omission = incomplete.
7. Server continuity: if a local/server URL was working before edits, capture a baseline first. After edits, verify the server still starts and the same URL still responds. For localhost, prefer the current route or the phase/page route the user is viewing. If the server was not running before, mark server continuity as N/A with evidence instead of pretending it was verified.
8. END every run with a COVERAGE ASSERTION table (one row per sub-step + per checklist box, plus a server-continuity row when edits touched code, config, docs UI, routes, assets, or generated prompt behavior):
     | Item (§/step or checklist box) | ✅WALKED / 🔍VERIFIED / ⏭DEFERRED / ◐PARTIAL | Evidence / why |
   Then confirm the page/phase Gate condition is observably met. If the table has any row that isn't ✅/🔍 (or a justified ⏭/◐), the step is NOT done.
9. Progress/state updates are part of execution: when the guide changes project state, update `Zaj-PROJECT.md`, `Zaj-PROGRESS.md`, `Zaj-BACKLOG.md`, `Zaj-CUSTOMIZATIONS.md`, and/or `playbook-feedback.md` yourself unless the project explicitly marks that exact write human-owned. Stale-open tracker rows that evidence proves done are bugs to fix, not notes to ask about.
10. Authentication boundary: an agent never types passwords, logs in, or creates accounts. Human performs the credential/authentication/account-creation transaction; agent resumes after the session or non-secret evidence exists.
11. Secrets: never put keys/passwords/.env values in code, commits, or chat; verify by length/exit-code only.

---

# 3 · Business & legal readiness

## TL;DR

**Objective** — make the business side real, not a placeholder: a customer needs something to land on, a way to pay, and the legal pages that make billing legitimate, because technical green is necessary but not sufficient.

**Steps at a glance:**
1. **Build the landing page** — A real entry point (a route in the app, a marketing site, or a one-pager)
   covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing,
   social proof, and a footer CTA.
2. **Publish legal pages** — Privacy Policy at `/privacy`, Terms of Service at `/terms`, Cookie Policy (if EU/UK
   traffic), Refund / cancellation policy (if selling), plus a working contact route.
3. **Wire transactional email** — Set the from-address and from-name, then wire the core templates: welcome,
   payment succeeded, payment failed, trial-expiring, and re-engagement.
4. **Configure pricing & payment** — Choose a model (a free tier plus a premium trial is the safe default),
   create the products and prices in the payment provider, wire the billing integration and webhook handlers
   (`checkout.session.completed`, `customer.subscription.deleted`, `invoice.payment_failed`), and add the
   trial/subscription gating middleware.
5. **Install analytics & social meta** — Install analytics with `sign_up`, `trial_started`, and `purchase`
   events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

:::note[User part + done-when]
**🔀 User part** — 👤 the user owns legal approval, account authorization, secret/live-key cutover, and paid/provider decisions. 🤖 With authorized browser/API access, the agent drives non-secret dashboard setup such as products/prices, wires the integration and webhook handlers, and verifies evidence without reading secret values.

**Done when** the landing page, `/privacy` + `/terms` + contact route, transactional email, pricing/payment flow, and analytics + social meta are all live and verified on the real domain. &nbsp;·&nbsp; **⏱ ~2–3 hr** &nbsp;·&nbsp; 🔀 mixed (👤 dashboards + policy generation, 🤖 integration).
:::

## Background

A customer also needs something to land on, a way to pay, and the legal pages that make billing legitimate. Build and test the entire flow on test keys first — live keys are the Phase 12 production switch.

Read `Zaj-PROJECT.md` first so the landing URL, legal routes, billing provider state, analytics provider, and live-key cutover owner come from the current project profile. Update it after verification with policy version dates, non-secret provider IDs, test-mode status, and any human-only production/legal follow-up tracked in `Zaj-BACKLOG.md`.

```mermaid
flowchart LR
  Land[Landing page] --> Pay[Test-mode checkout]
  Pay --> Legal[Terms · Privacy · Refund]
  Legal --> Live[Phase 12 live-key switch]
```

## Steps

### 1. Build the landing page

A real entry point (a route in the app, a marketing site, or a one-pager) covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing, social proof, and a footer CTA. Unauthenticated visitors see it; authenticated users redirect to the dashboard.

<Steps>

1. **Publish the landing page with all seven sections** and the authenticated-user redirect.

   - ✅ Unauthenticated visitors see the landing page; authenticated users redirect to the dashboard.

</Steps>

### 2. Publish legal pages

Privacy Policy at `/privacy`, Terms of Service at `/terms`, **Cookie Policy** (if EU/UK traffic), **Refund / cancellation policy** (if selling), plus a working contact route. Cross-check the full legal bar from [Phase 10 sign-off](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/10-audit-qa/06-sign-off/) and [Phase 7 legal](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/07-security-monitoring/06-legal-gdpr/) — don't drop pages the earlier gate required.

:::note[Who does this]
👤 **User** generates the Privacy Policy and Terms from a reputable template service — a person picks and approves the policy text; an agent then wires the routes.
:::

<Steps>

1. **Wire `/privacy`, `/terms`, `/cookies` (or generator-hosted cookie policy), `/refund` (if selling), and a contact route**, all reachable from the footer.

   - ✅ Legal pages and the contact route load and are linked in the footer; cookie + refund pages match the Phase 10 bar when applicable.

</Steps>

### 3. Wire transactional email

Set the from-address and from-name, then wire the core templates: welcome, payment succeeded, payment failed, trial-expiring, and re-engagement. Confirm each actually delivers (check SPF/DKIM/DMARC pass).

<Steps>

1. **Send a test of each core template** and confirm authentication passes.

   - ✅ Welcome, payment-succeeded, payment-failed, trial-expiring, and re-engagement emails deliver with SPF/DKIM/DMARC passing.

</Steps>

### 4. Configure pricing & payment

Choose a model (a free tier plus a premium trial is the safe default), create the products and prices in the payment provider, wire the billing integration and webhook handlers (`checkout.session.completed`, `customer.subscription.deleted`, `invoice.payment_failed`), and add the trial/subscription gating middleware. Test the full path with the provider's test cards and webhook forwarder; Phase 12 performs the production live-key switch and live charge/refund gate.

:::note[Who does this]
🔀 **Authorized agent + user gate** — 👤 **User** owns pricing decisions, provider account access, secret values, and any live-money approval. 🤖 With an authorized browser/API session, the agent may create or verify non-secret Products/Prices, register test webhooks, wire the billing integration, and prove gating. Pause for password, 2FA, payout verification, tax/legal decisions, or live-mode confirmation.
:::

<Steps>

1. **Create the products/prices, then wire the webhook handlers.** Listen for `checkout.session.completed`, `customer.subscription.deleted`, and `invoice.payment_failed`, and add the trial/subscription gating middleware.

   - ✅ The full path clears with the provider's test cards and webhook forwarder, and gating middleware enforces the trial/subscription.

</Steps>

### 5. Install analytics & social meta

Install analytics with `sign_up`, `trial_started`, and `purchase` events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

<Steps>

1. **Fire the three events and add the social tags.**

   - ✅ `sign_up`, `trial_started`, and `purchase` events register, and a shared link previews with the correct OG/Twitter card.

</Steps>

:::caution[Live keys are the last switch]
Build and test the entire payment flow on **test** keys. Phase 12 swaps to live keys only after the end-to-end test passes — and confirms the keys in both `.env` and any in-database settings table agree.
:::

:::caution[Public-facing copy must never name the CodeCanyon vendor]
The landing page, welcome/transactional emails, social meta, and any release notes or in-app "what's new" are **customer-facing** — they must carry **only your product's brand**, never the underlying CodeCanyon script, author, or marketplace (e.g. the vendor's product name, "CodeCanyon", "Envato", or an `author-vX` baseline tag). The vendor's demo content frequently leaks its own name into hero copy, footers, email templates, and seeded pages. Grep every public surface before launch:

```bash
# Replace the alternation with YOUR vendor's actual product/author name(s).
grep -rIiE 'codecanyon|envato|author-v[0-9]|<vendor-product-name>' \
  resources/views/ resources/lang/ public/ 2>/dev/null \
  && echo "  🔴 vendor name leaked into a public artifact — scrub before launch" \
  || echo "  ✅ no vendor name in public-facing copy"
# Also fetch the live landing page + a rendered welcome email and grep the HTML.
curl -s https://<your-domain>/ | grep -iE 'codecanyon|envato|<vendor-product-name>' && echo "  🔴 leak on the live landing page" || echo "  ✅ landing page clean"
```

An *internal* changelog may record the vendor base and `author-vX` for update tracking; the **public** changelog/release notes carry your project name and your own SemVer only.
:::

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Landing page** — seven sections live; authenticated users redirect to the dashboard.
- [ ] **👤 Legal pages** — `/privacy`, `/terms`, and contact route live and footer-linked.
- [ ] **🤖 Transactional email** — all five core templates deliver; SPF/DKIM/DMARC pass.
- [ ] **🔀 Pricing & payment** — products/prices created (👤), integration + webhooks wired and tested.
- [ ] **🤖 Analytics & social meta** — `sign_up`/`trial_started`/`purchase` fire; OG/Twitter cards preview.
- [ ] **🤖 No vendor name in public copy** — landing page, transactional emails, social meta, and public changelog grep clean of the CodeCanyon vendor/author/marketplace name.
- [ ] **🤖 Project state updated** — `Zaj-PROJECT.md` records landing URL, legal route URLs and policy dates, test-mode billing status, analytics/social providers, and any `Zaj-BACKLOG.md` human/legal/live-key follow-ups.

:::next[Next step]
[Support & onboarding](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/04-support-onboarding/)
:::

# 3 · Business & legal readiness

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/03-business-legal/

## TL;DR

**Objective** — make the business side real, not a placeholder: a customer needs something to land on, a way to pay, and the legal pages that make billing legitimate, because technical green is necessary but not sufficient.

**Steps at a glance:**
1. **Build the landing page** — A real entry point (a route in the app, a marketing site, or a one-pager)
   covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing,
   social proof, and a footer CTA.
2. **Publish legal pages** — Privacy Policy at `/privacy`, Terms of Service at `/terms`, Cookie Policy (if EU/UK
   traffic), Refund / cancellation policy (if selling), plus a working contact route.
3. **Wire transactional email** — Set the from-address and from-name, then wire the core templates: welcome,
   payment succeeded, payment failed, trial-expiring, and re-engagement.
4. **Configure pricing & payment** — Choose a model (a free tier plus a premium trial is the safe default),
   create the products and prices in the payment provider, wire the billing integration and webhook handlers
   (`checkout.session.completed`, `customer.subscription.deleted`, `invoice.payment_failed`), and add the
   trial/subscription gating middleware.
5. **Install analytics & social meta** — Install analytics with `sign_up`, `trial_started`, and `purchase`
   events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

:::note[User part + done-when]
**🔀 User part** — 👤 the user owns legal approval, account authorization, secret/live-key cutover, and paid/provider decisions. 🤖 With authorized browser/API access, the agent drives non-secret dashboard setup such as products/prices, wires the integration and webhook handlers, and verifies evidence without reading secret values.

**Done when** the landing page, `/privacy` + `/terms` + contact route, transactional email, pricing/payment flow, and analytics + social meta are all live and verified on the real domain. &nbsp;·&nbsp; **⏱ ~2–3 hr** &nbsp;·&nbsp; 🔀 mixed (👤 dashboards + policy generation, 🤖 integration).
:::

## Background

A customer also needs something to land on, a way to pay, and the legal pages that make billing legitimate. Build and test the entire flow on test keys first — live keys are the Phase 12 production switch.

Read `Zaj-PROJECT.md` first so the landing URL, legal routes, billing provider state, analytics provider, and live-key cutover owner come from the current project profile. Update it after verification with policy version dates, non-secret provider IDs, test-mode status, and any human-only production/legal follow-up tracked in `Zaj-BACKLOG.md`.

```mermaid
flowchart LR
  Land[Landing page] --> Pay[Test-mode checkout]
  Pay --> Legal[Terms · Privacy · Refund]
  Legal --> Live[Phase 12 live-key switch]
```

## Steps

### 1. Build the landing page

A real entry point (a route in the app, a marketing site, or a one-pager) covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing, social proof, and a footer CTA. Unauthenticated visitors see it; authenticated users redirect to the dashboard.

<Steps>

1. **Publish the landing page with all seven sections** and the authenticated-user redirect.

   - ✅ Unauthenticated visitors see the landing page; authenticated users redirect to the dashboard.

</Steps>

### 2. Publish legal pages

Privacy Policy at `/privacy`, Terms of Service at `/terms`, **Cookie Policy** (if EU/UK traffic), **Refund / cancellation policy** (if selling), plus a working contact route. Cross-check the full legal bar from [Phase 10 sign-off](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/10-audit-qa/06-sign-off/) and [Phase 7 legal](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/07-security-monitoring/06-legal-gdpr/) — don't drop pages the earlier gate required.

:::note[Who does this]
👤 **User** generates the Privacy Policy and Terms from a reputable template service — a person picks and approves the policy text; an agent then wires the routes.
:::

<Steps>

1. **Wire `/privacy`, `/terms`, `/cookies` (or generator-hosted cookie policy), `/refund` (if selling), and a contact route**, all reachable from the footer.

   - ✅ Legal pages and the contact route load and are linked in the footer; cookie + refund pages match the Phase 10 bar when applicable.

</Steps>

### 3. Wire transactional email

Set the from-address and from-name, then wire the core templates: welcome, payment succeeded, payment failed, trial-expiring, and re-engagement. Confirm each actually delivers (check SPF/DKIM/DMARC pass).

<Steps>

1. **Send a test of each core template** and confirm authentication passes.

   - ✅ Welcome, payment-succeeded, payment-failed, trial-expiring, and re-engagement emails deliver with SPF/DKIM/DMARC passing.

</Steps>

### 4. Configure pricing & payment

Choose a model (a free tier plus a premium trial is the safe default), create the products and prices in the payment provider, wire the billing integration and webhook handlers (`checkout.session.completed`, `customer.subscription.deleted`, `invoice.payment_failed`), and add the trial/subscription gating middleware. Test the full path with the provider's test cards and webhook forwarder; Phase 12 performs the production live-key switch and live charge/refund gate.

:::note[Who does this]
🔀 **Authorized agent + user gate** — 👤 **User** owns pricing decisions, provider account access, secret values, and any live-money approval. 🤖 With an authorized browser/API session, the agent may create or verify non-secret Products/Prices, register test webhooks, wire the billing integration, and prove gating. Pause for password, 2FA, payout verification, tax/legal decisions, or live-mode confirmation.
:::

<Steps>

1. **Create the products/prices, then wire the webhook handlers.** Listen for `checkout.session.completed`, `customer.subscription.deleted`, and `invoice.payment_failed`, and add the trial/subscription gating middleware.

   - ✅ The full path clears with the provider's test cards and webhook forwarder, and gating middleware enforces the trial/subscription.

</Steps>

### 5. Install analytics & social meta

Install analytics with `sign_up`, `trial_started`, and `purchase` events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

<Steps>

1. **Fire the three events and add the social tags.**

   - ✅ `sign_up`, `trial_started`, and `purchase` events register, and a shared link previews with the correct OG/Twitter card.

</Steps>

:::caution[Live keys are the last switch]
Build and test the entire payment flow on **test** keys. Phase 12 swaps to live keys only after the end-to-end test passes — and confirms the keys in both `.env` and any in-database settings table agree.
:::

:::caution[Public-facing copy must never name the CodeCanyon vendor]
The landing page, welcome/transactional emails, social meta, and any release notes or in-app "what's new" are **customer-facing** — they must carry **only your product's brand**, never the underlying CodeCanyon script, author, or marketplace (e.g. the vendor's product name, "CodeCanyon", "Envato", or an `author-vX` baseline tag). The vendor's demo content frequently leaks its own name into hero copy, footers, email templates, and seeded pages. Grep every public surface before launch:

```bash
# Replace the alternation with YOUR vendor's actual product/author name(s).
grep -rIiE 'codecanyon|envato|author-v[0-9]|<vendor-product-name>' \
  resources/views/ resources/lang/ public/ 2>/dev/null \
  && echo "  🔴 vendor name leaked into a public artifact — scrub before launch" \
  || echo "  ✅ no vendor name in public-facing copy"
# Also fetch the live landing page + a rendered welcome email and grep the HTML.
curl -s https://<your-domain>/ | grep -iE 'codecanyon|envato|<vendor-product-name>' && echo "  🔴 leak on the live landing page" || echo "  ✅ landing page clean"
```

An *internal* changelog may record the vendor base and `author-vX` for update tracking; the **public** changelog/release notes carry your project name and your own SemVer only.
:::

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Landing page** — seven sections live; authenticated users redirect to the dashboard.
- [ ] **👤 Legal pages** — `/privacy`, `/terms`, and contact route live and footer-linked.
- [ ] **🤖 Transactional email** — all five core templates deliver; SPF/DKIM/DMARC pass.
- [ ] **🔀 Pricing & payment** — products/prices created (👤), integration + webhooks wired and tested.
- [ ] **🤖 Analytics & social meta** — `sign_up`/`trial_started`/`purchase` fire; OG/Twitter cards preview.
- [ ] **🤖 No vendor name in public copy** — landing page, transactional emails, social meta, and public changelog grep clean of the CodeCanyon vendor/author/marketplace name.
- [ ] **🤖 Project state updated** — `Zaj-PROJECT.md` records landing URL, legal route URLs and policy dates, test-mode billing status, analytics/social providers, and any `Zaj-BACKLOG.md` human/legal/live-key follow-ups.

:::next[Next step]
[Support & onboarding](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/04-support-onboarding/)
:::

STEP 0 — COLD-START ORIENTATION (do this BEFORE fetching any Part document; assume you have ZERO
prior context about this project):

1. Locate + identify. Run `pwd`. Read the project's `AGENTS.md` + `CLAUDE.md` if present so you
   know the repo rules and whether you are in the right project. Then read `Zaj-PROJECT.md` FIRST
   as the non-secret project bible: identity, environment matrix, toolchain versions, SSH aliases,
   deploy paths, and current phase. If `Zaj-PROJECT.md` is missing in a legacy project, read
   `Admin-Local/1-Project/1-Info/ProjectCard.md` as fallback, then create/update `Zaj-PROJECT.md`.

2. Read the state ledgers — READ BOTH OLD AND NEW NAMES (projects mid-migration use either):
   `Zaj-PROGRESS.md` OR `PROGRESS.md` (what earlier phases/steps already did, what's in-flight),
   `Zaj-BACKLOG.md` OR `BACKLOG.md` (phase-entry blockers, deferred work, and scheduled follow-up),
   and `Zaj-CUSTOMIZATIONS.md` OR `_CUSTOMIZATIONS.md` (vendor deviations + prior findings you must
   not re-derive or contradict).

3. Check git reality: `git branch --show-current`, `git log --oneline -8`, `git status --short`.
   - FRESH vs RESUMING: if commits/ledger show this phase (or earlier steps) already ran, you are
     RESUMING → verify-with-evidence, do NOT blindly re-run installer / migrate / db-create /
     asset-build. (This is the contract's reconcile rule.)
   - CONCURRENT-WORK check: uncommitted changes you didn't make, or HEAD ahead of the ledger, can
     mean ANOTHER agent is working this repo. Coordinate around hot files; do not commit over
     unrelated work. Routine tracker fixes remain agent-owned work unless they would overwrite a
     hot file another agent is editing.

4. Inherit rules + safety: skim `.claude/rules/` (project-specific vendor gotchas) and obey them +
   these non-negotiables — never echo secrets (verify by length/exit-code only), never re-run
   destructive/once-only steps, archive-don't-delete, honor 👤 vs 🤖.

5. How to fetch Part documents: prefer the ZajLibrary MCP `get_document` by SLUG. If the returned
   `commitShaShort` looks stale vs the live page (missing steps, old text), the index is behind →
   use `zajlibrary-local` (localhost) OR read the page's source `.mdx` directly from the ZajLibrary
   repo. NOTE: the MCP's "compare commitShaShort to your local git HEAD" instruction applies ONLY
   when you are working INSIDE the ZajLibrary repo — from THIS consuming project it is just a
   freshness/staleness signal, not a match to make.

6. Where to record: write current-truth facts to `Zaj-PROJECT.md`; write vendor deviations to
   `Zaj-CUSTOMIZATIONS.md`; write execution state to `Zaj-PROGRESS.md`; write blockers/deferred
   work to `Zaj-BACKLOG.md`. If a tracker row says open/deferred but you verify it is now done,
   fix the stale row in the same run with evidence — don't leave "closed in reality, open in tracker."
   File any guide bug/gap via the feedback clause (MCP `submit_feedback` +
   `Admin-Local/1-Project/playbook-feedback.md`) — log-then-continue, don't silently work around.

Only after Step 0 is complete, begin fetching Part 1.

AUTONOMY CONTRACT — complete accurate work unless a real human gate is required:
1. Treat ZajLibrary guidance as operational guidance, not a suggestion to summarize. If the user asked you to follow/apply/implement the page, do the work end to end in the real project until the page's exit criteria are met or a hard blocker is proven.
2. Do not ask the user whether to do routine agent-owned work: reading project rules, checking git state, updating progress/customization/feedback ledgers, running verification, fixing clear best-practice issues, or choosing the safer/professional default. Do it, cite evidence, and report what changed.
3. Ask the human only for true human-owned actions: credentials, API keys, paid/provider dashboards, DNS/production cutovers, destructive or irreversible operations, personal/business choices, legal/commercial decisions, or cases where two options are genuinely equal and the guide/project gives no tie-breaker.
4. If one option is clearly more secure, more professional, more maintainable, or better aligned with the guide/project rules, choose it and document the rationale instead of asking for a preference.
5. When you discover already-completed or partially-completed work, reconcile from evidence. Verify the end state, update the relevant ledger/checklist if state changed, and avoid re-running destructive or once-only commands.
6. Banned routine asks: "should I update trackers?", "should I commit?", "should I run verification?", "should I fix the stale ledger?", or "which option do you prefer?" when the guide/project makes one option clearly better.
7. If the guide has a gap or mismatch, log it through the project's documented feedback path and continue with the safest evidence-backed implementation when possible. Stop only when continuing would be unsafe, destructive, or would require a human-owned decision.

AUTHENTICATION BOUNDARY — hard, non-overridable:
An AI agent cannot type a password to authenticate, cannot log in, and cannot create an account in ANY environment (dev/staging included), even when the user authorizes it and the password is in the vault.
For every login-gated verification step (dashboard walk, user journey, admin panel, hPanel, registrar/provider dashboard): 👤 Human performs the ONE login, dashboard sign-in, account creation, or credential-entry moment. 🤖 Agent drives everything after the authenticated session exists — clicks, navigation, non-secret form fills, screenshots, checks.
For account creation, login, password-change, or password-reset forms, the human completes the credential/auth transaction through submit; the agent resumes after the account/session/credential change exists. Everything an agent can do without authenticating stays 🤖: public pages, viewport/mobile checks, API calls with an already-provided token, SSH/DB checks, and browser-driven configuration up to (but not including) a password/secret field. Only credential entry and the authentication/account-creation act are 👤.

Autonomy: Do all 🤖 work without asking — tracker updates, verification, signed commits, reconciling stale items to reality are the job, not questions. Stop for the human ONLY at genuine 👤 gates: real secrets/credentials, irreversible actions (prod deploy, real money, data deletion, force-push), or genuine WHAT/scope/business decisions.

Full ≠ optional: Autonomy does not mean minimal. Execute each Part fully — every Step, every # Expected: check, all states/sub-flows wired end-to-end. Never ship a happy-path subset as "done." If something genuinely can't finish in-session, it must be a real 👤/external gate (not a shortcut), stated exactly — what is deferred and why — as a tracked item before moving on. When the user says "do fully," honor it to completion.

EXECUTION CONTRACT — full coverage, no silent skips:
1. Before finishing a Part, you MUST account for EVERY item in the Part's `## Steps` (including each numbered sub-step inside <Steps> blocks) AND every box in `## Checklist`. Nothing is implicitly done.
2. Scope labels are not skip permission. `MUST`, `SHOULD`, `OPTIONAL`, quality-track, companion, and fast-mode labels explain gate priority; they do NOT remove an item from coverage. Default to FULL execution. Run `MUST-only`, `MUST+SHOULD-only`, gate-only, or fast mode only when the user explicitly asks for that mode. Even then, name every skipped `SHOULD` / `OPTIONAL` item that the chosen mode leaves out as ⏭ DEFERRED with why and when.
3. For EACH sub-step and EACH checklist box, do ONE of — and record which, with evidence:
     ✅ WALKED         — you ran the command/action; paste/point to the output it produced.
     🔍 VERIFIED-STATE — end-state already satisfied (idempotent step, or a prior session did it). Allowed, but you MUST cite the evidence (command output/file/DB state) proving it — never assert "already done" without proof.
     ⏭ DEFERRED        — legitimately out of scope now (a :::note[Who does this] 👤 step you're waiting on, or an explicit "later phase" pointer). State why + to when.
     ◐ PARTIAL         — some sub-parts done, some deferred; list exactly which and why.
4. Honor every `# Expected:` / ✅ bullet — compare actual output. On mismatch, first investigate safely and reconcile from evidence; STOP and ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices. Honor :::caution/:::danger as hard gates. Honor 👤 vs 🤖.
5. Reconciliation is allowed (don't blindly re-run installers/migrations/db-create/asset builds) — but reconciliation without per-item disclosure is BANNED.
6. You may NOT declare the Part/Phase "done" while any `## Steps` Step, sub-step, or `## Checklist` box is unclassified. Silent omission = incomplete.
7. Server continuity: if a local/server URL was working before edits, capture a baseline first. After edits, verify the server still starts and the same URL still responds. For localhost, prefer the current route or the phase/page route the user is viewing. If the server was not running before, mark server continuity as N/A with evidence instead of pretending it was verified.
8. END every run with a COVERAGE ASSERTION table (one row per sub-step + per checklist box, plus a server-continuity row when edits touched code, config, docs UI, routes, assets, or generated prompt behavior):
     | Item (§/step or checklist box) | ✅WALKED / 🔍VERIFIED / ⏭DEFERRED / ◐PARTIAL | Evidence / why |
   Then confirm the page/phase Gate condition is observably met. If the table has any row that isn't ✅/🔍 (or a justified ⏭/◐), the step is NOT done.
9. Progress/state updates are part of execution: when the guide changes project state, update `Zaj-PROJECT.md`, `Zaj-PROGRESS.md`, `Zaj-BACKLOG.md`, `Zaj-CUSTOMIZATIONS.md`, and/or `playbook-feedback.md` yourself unless the project explicitly marks that exact write human-owned. Stale-open tracker rows that evidence proves done are bugs to fix, not notes to ask about.
10. Authentication boundary: an agent never types passwords, logs in, or creates accounts. Human performs the credential/authentication/account-creation transaction; agent resumes after the session or non-secret evidence exists.
11. Secrets: never put keys/passwords/.env values in code, commits, or chat; verify by length/exit-code only.

TL;DR

Objective — make the business side real, not a placeholder: a customer needs something to land on, a way to pay, and the legal pages that make billing legitimate, because technical green is necessary but not sufficient.

Steps at a glance:

Build the landing page — A real entry point (a route in the app, a marketing site, or a one-pager) covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing, social proof, and a footer CTA.
Publish legal pages — Privacy Policy at /privacy, Terms of Service at /terms, Cookie Policy (if EU/UK traffic), Refund / cancellation policy (if selling), plus a working contact route.
Wire transactional email — Set the from-address and from-name, then wire the core templates: welcome, payment succeeded, payment failed, trial-expiring, and re-engagement.
Configure pricing & payment — Choose a model (a free tier plus a premium trial is the safe default), create the products and prices in the payment provider, wire the billing integration and webhook handlers (checkout.session.completed, customer.subscription.deleted, invoice.payment_failed), and add the trial/subscription gating middleware.
Install analytics & social meta — Install analytics with sign_up, trial_started, and purchase events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

Background

A customer also needs something to land on, a way to pay, and the legal pages that make billing legitimate. Build and test the entire flow on test keys first — live keys are the Phase 12 production switch.

Read Zaj-PROJECT.md first so the landing URL, legal routes, billing provider state, analytics provider, and live-key cutover owner come from the current project profile. Update it after verification with policy version dates, non-secret provider IDs, test-mode status, and any human-only production/legal follow-up tracked in Zaj-BACKLOG.md.

flowchart LR
  Land[Landing page] --> Pay[Test-mode checkout]
  Pay --> Legal[Terms · Privacy · Refund]
  Legal --> Live[Phase 12 live-key switch]

Steps

1. Build the landing page

A real entry point (a route in the app, a marketing site, or a one-pager) covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing, social proof, and a footer CTA. Unauthenticated visitors see it; authenticated users redirect to the dashboard.

Publish the landing page with all seven sections and the authenticated-user redirect.
- ✅ Unauthenticated visitors see the landing page; authenticated users redirect to the dashboard.

2. Publish legal pages

Privacy Policy at /privacy, Terms of Service at /terms, Cookie Policy (if EU/UK traffic), Refund / cancellation policy (if selling), plus a working contact route. Cross-check the full legal bar from Phase 10 sign-off and Phase 7 legal — don’t drop pages the earlier gate required.

Wire /privacy, /terms, /cookies (or generator-hosted cookie policy), /refund (if selling), and a contact route, all reachable from the footer.
- ✅ Legal pages and the contact route load and are linked in the footer; cookie + refund pages match the Phase 10 bar when applicable.

3. Wire transactional email

Set the from-address and from-name, then wire the core templates: welcome, payment succeeded, payment failed, trial-expiring, and re-engagement. Confirm each actually delivers (check SPF/DKIM/DMARC pass).

Send a test of each core template and confirm authentication passes.
- ✅ Welcome, payment-succeeded, payment-failed, trial-expiring, and re-engagement emails deliver with SPF/DKIM/DMARC passing.

4. Configure pricing & payment

Choose a model (a free tier plus a premium trial is the safe default), create the products and prices in the payment provider, wire the billing integration and webhook handlers (checkout.session.completed, customer.subscription.deleted, invoice.payment_failed), and add the trial/subscription gating middleware. Test the full path with the provider’s test cards and webhook forwarder; Phase 12 performs the production live-key switch and live charge/refund gate.

Create the products/prices, then wire the webhook handlers. Listen for checkout.session.completed, customer.subscription.deleted, and invoice.payment_failed, and add the trial/subscription gating middleware.
- ✅ The full path clears with the provider’s test cards and webhook forwarder, and gating middleware enforces the trial/subscription.

Install analytics with sign_up, trial_started, and purchase events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

Fire the three events and add the social tags.
- ✅ sign_up, trial_started, and purchase events register, and a shared link previews with the correct OG/Twitter card.

The landing page, welcome/transactional emails, social meta, and any release notes or in-app “what’s new” are customer-facing — they must carry only your product’s brand, never the underlying CodeCanyon script, author, or marketplace (e.g. the vendor’s product name, “CodeCanyon”, “Envato”, or an author-vX baseline tag). The vendor’s demo content frequently leaks its own name into hero copy, footers, email templates, and seeded pages. Grep every public surface before launch:

# Replace the alternation with YOUR vendor's actual product/author name(s).
grep -rIiE 'codecanyon|envato|author-v[0-9]|<vendor-product-name>' \
  resources/views/ resources/lang/ public/ 2>/dev/null \
  && echo "  🔴 vendor name leaked into a public artifact — scrub before launch" \
  || echo "  ✅ no vendor name in public-facing copy"
# Also fetch the live landing page + a rendered welcome email and grep the HTML.
curl -s https://<your-domain>/ | grep -iE 'codecanyon|envato|<vendor-product-name>' && echo "  🔴 leak on the live landing page" || echo "  ✅ landing page clean"

An internal changelog may record the vendor base and author-vX for update tracking; the public changelog/release notes carry your project name and your own SemVer only.

Checklist

Do not mark this step done until every box below is checked.

🤖 Landing page — seven sections live; authenticated users redirect to the dashboard.
👤 Legal pages — /privacy, /terms, and contact route live and footer-linked.
🤖 Transactional email — all five core templates deliver; SPF/DKIM/DMARC pass.
🔀 Pricing & payment — products/prices created (👤), integration + webhooks wired and tested.
🤖 Analytics & social meta — sign_up/trial_started/purchase fire; OG/Twitter cards preview.
🤖 No vendor name in public copy — landing page, transactional emails, social meta, and public changelog grep clean of the CodeCanyon vendor/author/marketplace name.
🤖 Project state updated — Zaj-PROJECT.md records landing URL, legal route URLs and policy dates, test-mode billing status, analytics/social providers, and any Zaj-BACKLOG.md human/legal/live-key follow-ups.

Support & onboarding

STEP 0 — COLD-START ORIENTATION (do this BEFORE fetching any Part document; assume you have ZERO
prior context about this project):

1. Locate + identify. Run `pwd`. Read the project's `AGENTS.md` + `CLAUDE.md` if present so you
   know the repo rules and whether you are in the right project. Then read `Zaj-PROJECT.md` FIRST
   as the non-secret project bible: identity, environment matrix, toolchain versions, SSH aliases,
   deploy paths, and current phase. If `Zaj-PROJECT.md` is missing in a legacy project, read
   `Admin-Local/1-Project/1-Info/ProjectCard.md` as fallback, then create/update `Zaj-PROJECT.md`.

2. Read the state ledgers — READ BOTH OLD AND NEW NAMES (projects mid-migration use either):
   `Zaj-PROGRESS.md` OR `PROGRESS.md` (what earlier phases/steps already did, what's in-flight),
   `Zaj-BACKLOG.md` OR `BACKLOG.md` (phase-entry blockers, deferred work, and scheduled follow-up),
   and `Zaj-CUSTOMIZATIONS.md` OR `_CUSTOMIZATIONS.md` (vendor deviations + prior findings you must
   not re-derive or contradict).

3. Check git reality: `git branch --show-current`, `git log --oneline -8`, `git status --short`.
   - FRESH vs RESUMING: if commits/ledger show this phase (or earlier steps) already ran, you are
     RESUMING → verify-with-evidence, do NOT blindly re-run installer / migrate / db-create /
     asset-build. (This is the contract's reconcile rule.)
   - CONCURRENT-WORK check: uncommitted changes you didn't make, or HEAD ahead of the ledger, can
     mean ANOTHER agent is working this repo. Coordinate around hot files; do not commit over
     unrelated work. Routine tracker fixes remain agent-owned work unless they would overwrite a
     hot file another agent is editing.

4. Inherit rules + safety: skim `.claude/rules/` (project-specific vendor gotchas) and obey them +
   these non-negotiables — never echo secrets (verify by length/exit-code only), never re-run
   destructive/once-only steps, archive-don't-delete, honor 👤 vs 🤖.

5. How to fetch Part documents: prefer the ZajLibrary MCP `get_document` by SLUG. If the returned
   `commitShaShort` looks stale vs the live page (missing steps, old text), the index is behind →
   use `zajlibrary-local` (localhost) OR read the page's source `.mdx` directly from the ZajLibrary
   repo. NOTE: the MCP's "compare commitShaShort to your local git HEAD" instruction applies ONLY
   when you are working INSIDE the ZajLibrary repo — from THIS consuming project it is just a
   freshness/staleness signal, not a match to make.

6. Where to record: write current-truth facts to `Zaj-PROJECT.md`; write vendor deviations to
   `Zaj-CUSTOMIZATIONS.md`; write execution state to `Zaj-PROGRESS.md`; write blockers/deferred
   work to `Zaj-BACKLOG.md`. If a tracker row says open/deferred but you verify it is now done,
   fix the stale row in the same run with evidence — don't leave "closed in reality, open in tracker."
   File any guide bug/gap via the feedback clause (MCP `submit_feedback` +
   `Admin-Local/1-Project/playbook-feedback.md`) — log-then-continue, don't silently work around.

Only after Step 0 is complete, begin fetching Part 1.

# ZajLibrary — implementation playbook

You are a **senior implementation assistant** working inside the user’s real development environment (terminal, editor, git repo). You are **not** a documentation writer, tutor, or library editor.

**Mission:** Execute the procedure described below in the user’s real project workspace — create or modify the files and run the commands it specifies. Do not just summarize it.

AUTONOMY CONTRACT — complete accurate work unless a real human gate is required:
1. Treat ZajLibrary guidance as operational guidance, not a suggestion to summarize. If the user asked you to follow/apply/implement the page, do the work end to end in the real project until the page's exit criteria are met or a hard blocker is proven.
2. Do not ask the user whether to do routine agent-owned work: reading project rules, checking git state, updating progress/customization/feedback ledgers, running verification, fixing clear best-practice issues, or choosing the safer/professional default. Do it, cite evidence, and report what changed.
3. Ask the human only for true human-owned actions: credentials, API keys, paid/provider dashboards, DNS/production cutovers, destructive or irreversible operations, personal/business choices, legal/commercial decisions, or cases where two options are genuinely equal and the guide/project gives no tie-breaker.
4. If one option is clearly more secure, more professional, more maintainable, or better aligned with the guide/project rules, choose it and document the rationale instead of asking for a preference.
5. When you discover already-completed or partially-completed work, reconcile from evidence. Verify the end state, update the relevant ledger/checklist if state changed, and avoid re-running destructive or once-only commands.
6. Banned routine asks: "should I update trackers?", "should I commit?", "should I run verification?", "should I fix the stale ledger?", or "which option do you prefer?" when the guide/project makes one option clearly better.
7. If the guide has a gap or mismatch, log it through the project's documented feedback path and continue with the safest evidence-backed implementation when possible. Stop only when continuing would be unsafe, destructive, or would require a human-owned decision.

AUTHENTICATION BOUNDARY — hard, non-overridable:
An AI agent cannot type a password to authenticate, cannot log in, and cannot create an account in ANY environment (dev/staging included), even when the user authorizes it and the password is in the vault.
For every login-gated verification step (dashboard walk, user journey, admin panel, hPanel, registrar/provider dashboard): 👤 Human performs the ONE login, dashboard sign-in, account creation, or credential-entry moment. 🤖 Agent drives everything after the authenticated session exists — clicks, navigation, non-secret form fills, screenshots, checks.
For account creation, login, password-change, or password-reset forms, the human completes the credential/auth transaction through submit; the agent resumes after the account/session/credential change exists. Everything an agent can do without authenticating stays 🤖: public pages, viewport/mobile checks, API calls with an already-provided token, SSH/DB checks, and browser-driven configuration up to (but not including) a password/secret field. Only credential entry and the authentication/account-creation act are 👤.

## Metadata
- title: 3 · Business & legal readiness
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/03-business-legal/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 11
- part_number: 3 (legacy stepNumber frontmatter)
- legacy_step_number: 3
- est_time: ~2–3 hr
- description: A customer needs something to land on, a way to pay, and the legal pages that make billing legitimate — landing page, legal pages, transactional email, pricing & payment, analytics & social meta.
- tags: codecanyon, laravel, launch, legal, payments

## Execution rules (binding)
- This is Part 3 of phase 11 (~2–3 hr) — execute this Part fully, then stop at its `## Checklist`.
- Autonomy: Do all 🤖 work without asking — tracker updates, verification, signed commits, reconciling stale items to reality are the job, not questions. Stop for the human ONLY at genuine 👤 gates: real secrets/credentials, irreversible actions (prod deploy, real money, data deletion, force-push), or genuine WHAT/scope/business decisions.
- Full ≠ optional: Autonomy does not mean minimal. Execute each Part fully — every Step, every # Expected: check, all states/sub-flows wired end-to-end. Never ship a happy-path subset as "done." If something genuinely can't finish in-session, it must be a real 👤/external gate (not a shortcut), stated exactly — what is deferred and why — as a tracked item before moving on. When the user says "do fully," honor it to completion.
- For playbooks, treat a Part as the `.mdx` page-level execution unit and each item in `## Steps` as a Step inside that Part.
- Follow `## Steps` in order. Do not skip Steps or declare the work complete early.
- Respect `:::note[Who does this]`: 👤 **User** steps (authentication, account creation, password/secret entry, paid/provider dashboards, destructive actions) need the human; 🤖 **Agent** steps you run in the shell or browser after the authenticated session exists.
- After every command, compare its output to the `# Expected:` comment or ✅ bullet beneath it. If it differs, investigate safely and reconcile from evidence first; ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices.
- Honor `:::caution` / `:::note` callouts as hard gates (a step may forbid a command at this stage).
- Do not mark the Part done until every `## Checklist` item is genuinely satisfied.
- Scope: implement only what this Part describes — no refactors, added features, or later-phase work unless the Part says so.
- When the work changes project state, update the relevant progress/customization/feedback ledger yourself; do not ask whether routine state tracking should be updated.
- When reporting progress, cite the `##` / `###` headings you completed or got blocked on.
- Secrets: never put API keys, passwords, or `.env` values in frontend code, commits, or chat logs — use server-side `.env` / config only, and keep `.env` gitignored.
- EXECUTION CONTRACT — full coverage, no silent skips:
1. Before finishing a Part, you MUST account for EVERY item in the Part's `## Steps` (including each numbered sub-step inside <Steps> blocks) AND every box in `## Checklist`. Nothing is implicitly done.
2. Scope labels are not skip permission. `MUST`, `SHOULD`, `OPTIONAL`, quality-track, companion, and fast-mode labels explain gate priority; they do NOT remove an item from coverage. Default to FULL execution. Run `MUST-only`, `MUST+SHOULD-only`, gate-only, or fast mode only when the user explicitly asks for that mode. Even then, name every skipped `SHOULD` / `OPTIONAL` item that the chosen mode leaves out as ⏭ DEFERRED with why and when.
3. For EACH sub-step and EACH checklist box, do ONE of — and record which, with evidence:
     ✅ WALKED         — you ran the command/action; paste/point to the output it produced.
     🔍 VERIFIED-STATE — end-state already satisfied (idempotent step, or a prior session did it). Allowed, but you MUST cite the evidence (command output/file/DB state) proving it — never assert "already done" without proof.
     ⏭ DEFERRED        — legitimately out of scope now (a :::note[Who does this] 👤 step you're waiting on, or an explicit "later phase" pointer). State why + to when.
     ◐ PARTIAL         — some sub-parts done, some deferred; list exactly which and why.
4. Honor every `# Expected:` / ✅ bullet — compare actual output. On mismatch, first investigate safely and reconcile from evidence; STOP and ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices. Honor :::caution/:::danger as hard gates. Honor 👤 vs 🤖.
5. Reconciliation is allowed (don't blindly re-run installers/migrations/db-create/asset builds) — but reconciliation without per-item disclosure is BANNED.
6. You may NOT declare the Part/Phase "done" while any `## Steps` Step, sub-step, or `## Checklist` box is unclassified. Silent omission = incomplete.
7. Server continuity: if a local/server URL was working before edits, capture a baseline first. After edits, verify the server still starts and the same URL still responds. For localhost, prefer the current route or the phase/page route the user is viewing. If the server was not running before, mark server continuity as N/A with evidence instead of pretending it was verified.
8. END every run with a COVERAGE ASSERTION table (one row per sub-step + per checklist box, plus a server-continuity row when edits touched code, config, docs UI, routes, assets, or generated prompt behavior):
     | Item (§/step or checklist box) | ✅WALKED / 🔍VERIFIED / ⏭DEFERRED / ◐PARTIAL | Evidence / why |
   Then confirm the page/phase Gate condition is observably met. If the table has any row that isn't ✅/🔍 (or a justified ⏭/◐), the step is NOT done.
9. Progress/state updates are part of execution: when the guide changes project state, update `Zaj-PROJECT.md`, `Zaj-PROGRESS.md`, `Zaj-BACKLOG.md`, `Zaj-CUSTOMIZATIONS.md`, and/or `playbook-feedback.md` yourself unless the project explicitly marks that exact write human-owned. Stale-open tracker rows that evidence proves done are bugs to fix, not notes to ask about.
10. Authentication boundary: an agent never types passwords, logs in, or creates accounts. Human performs the credential/authentication/account-creation transaction; agent resumes after the session or non-secret evidence exists.
11. Secrets: never put keys/passwords/.env values in code, commits, or chat; verify by length/exit-code only.

---

# 3 · Business & legal readiness

## TL;DR

**Objective** — make the business side real, not a placeholder: a customer needs something to land on, a way to pay, and the legal pages that make billing legitimate, because technical green is necessary but not sufficient.

**Steps at a glance:**
1. **Build the landing page** — A real entry point (a route in the app, a marketing site, or a one-pager)
   covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing,
   social proof, and a footer CTA.
2. **Publish legal pages** — Privacy Policy at `/privacy`, Terms of Service at `/terms`, Cookie Policy (if EU/UK
   traffic), Refund / cancellation policy (if selling), plus a working contact route.
3. **Wire transactional email** — Set the from-address and from-name, then wire the core templates: welcome,
   payment succeeded, payment failed, trial-expiring, and re-engagement.
4. **Configure pricing & payment** — Choose a model (a free tier plus a premium trial is the safe default),
   create the products and prices in the payment provider, wire the billing integration and webhook handlers
   (`checkout.session.completed`, `customer.subscription.deleted`, `invoice.payment_failed`), and add the
   trial/subscription gating middleware.
5. **Install analytics & social meta** — Install analytics with `sign_up`, `trial_started`, and `purchase`
   events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

:::note[User part + done-when]
**🔀 User part** — 👤 the user owns legal approval, account authorization, secret/live-key cutover, and paid/provider decisions. 🤖 With authorized browser/API access, the agent drives non-secret dashboard setup such as products/prices, wires the integration and webhook handlers, and verifies evidence without reading secret values.

**Done when** the landing page, `/privacy` + `/terms` + contact route, transactional email, pricing/payment flow, and analytics + social meta are all live and verified on the real domain. &nbsp;·&nbsp; **⏱ ~2–3 hr** &nbsp;·&nbsp; 🔀 mixed (👤 dashboards + policy generation, 🤖 integration).
:::

## Background

A customer also needs something to land on, a way to pay, and the legal pages that make billing legitimate. Build and test the entire flow on test keys first — live keys are the Phase 12 production switch.

Read `Zaj-PROJECT.md` first so the landing URL, legal routes, billing provider state, analytics provider, and live-key cutover owner come from the current project profile. Update it after verification with policy version dates, non-secret provider IDs, test-mode status, and any human-only production/legal follow-up tracked in `Zaj-BACKLOG.md`.

```mermaid
flowchart LR
  Land[Landing page] --> Pay[Test-mode checkout]
  Pay --> Legal[Terms · Privacy · Refund]
  Legal --> Live[Phase 12 live-key switch]
```

## Steps

### 1. Build the landing page

A real entry point (a route in the app, a marketing site, or a one-pager) covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing, social proof, and a footer CTA. Unauthenticated visitors see it; authenticated users redirect to the dashboard.

<Steps>

1. **Publish the landing page with all seven sections** and the authenticated-user redirect.

   - ✅ Unauthenticated visitors see the landing page; authenticated users redirect to the dashboard.

</Steps>

### 2. Publish legal pages

Privacy Policy at `/privacy`, Terms of Service at `/terms`, **Cookie Policy** (if EU/UK traffic), **Refund / cancellation policy** (if selling), plus a working contact route. Cross-check the full legal bar from [Phase 10 sign-off](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/10-audit-qa/06-sign-off/) and [Phase 7 legal](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/07-security-monitoring/06-legal-gdpr/) — don't drop pages the earlier gate required.

:::note[Who does this]
👤 **User** generates the Privacy Policy and Terms from a reputable template service — a person picks and approves the policy text; an agent then wires the routes.
:::

<Steps>

1. **Wire `/privacy`, `/terms`, `/cookies` (or generator-hosted cookie policy), `/refund` (if selling), and a contact route**, all reachable from the footer.

   - ✅ Legal pages and the contact route load and are linked in the footer; cookie + refund pages match the Phase 10 bar when applicable.

</Steps>

### 3. Wire transactional email

Set the from-address and from-name, then wire the core templates: welcome, payment succeeded, payment failed, trial-expiring, and re-engagement. Confirm each actually delivers (check SPF/DKIM/DMARC pass).

<Steps>

1. **Send a test of each core template** and confirm authentication passes.

   - ✅ Welcome, payment-succeeded, payment-failed, trial-expiring, and re-engagement emails deliver with SPF/DKIM/DMARC passing.

</Steps>

### 4. Configure pricing & payment

Choose a model (a free tier plus a premium trial is the safe default), create the products and prices in the payment provider, wire the billing integration and webhook handlers (`checkout.session.completed`, `customer.subscription.deleted`, `invoice.payment_failed`), and add the trial/subscription gating middleware. Test the full path with the provider's test cards and webhook forwarder; Phase 12 performs the production live-key switch and live charge/refund gate.

:::note[Who does this]
🔀 **Authorized agent + user gate** — 👤 **User** owns pricing decisions, provider account access, secret values, and any live-money approval. 🤖 With an authorized browser/API session, the agent may create or verify non-secret Products/Prices, register test webhooks, wire the billing integration, and prove gating. Pause for password, 2FA, payout verification, tax/legal decisions, or live-mode confirmation.
:::

<Steps>

1. **Create the products/prices, then wire the webhook handlers.** Listen for `checkout.session.completed`, `customer.subscription.deleted`, and `invoice.payment_failed`, and add the trial/subscription gating middleware.

   - ✅ The full path clears with the provider's test cards and webhook forwarder, and gating middleware enforces the trial/subscription.

</Steps>

### 5. Install analytics & social meta

Install analytics with `sign_up`, `trial_started`, and `purchase` events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

<Steps>

1. **Fire the three events and add the social tags.**

   - ✅ `sign_up`, `trial_started`, and `purchase` events register, and a shared link previews with the correct OG/Twitter card.

</Steps>

:::caution[Live keys are the last switch]
Build and test the entire payment flow on **test** keys. Phase 12 swaps to live keys only after the end-to-end test passes — and confirms the keys in both `.env` and any in-database settings table agree.
:::

:::caution[Public-facing copy must never name the CodeCanyon vendor]
The landing page, welcome/transactional emails, social meta, and any release notes or in-app "what's new" are **customer-facing** — they must carry **only your product's brand**, never the underlying CodeCanyon script, author, or marketplace (e.g. the vendor's product name, "CodeCanyon", "Envato", or an `author-vX` baseline tag). The vendor's demo content frequently leaks its own name into hero copy, footers, email templates, and seeded pages. Grep every public surface before launch:

```bash
# Replace the alternation with YOUR vendor's actual product/author name(s).
grep -rIiE 'codecanyon|envato|author-v[0-9]|<vendor-product-name>' \
  resources/views/ resources/lang/ public/ 2>/dev/null \
  && echo "  🔴 vendor name leaked into a public artifact — scrub before launch" \
  || echo "  ✅ no vendor name in public-facing copy"
# Also fetch the live landing page + a rendered welcome email and grep the HTML.
curl -s https://<your-domain>/ | grep -iE 'codecanyon|envato|<vendor-product-name>' && echo "  🔴 leak on the live landing page" || echo "  ✅ landing page clean"
```

An *internal* changelog may record the vendor base and `author-vX` for update tracking; the **public** changelog/release notes carry your project name and your own SemVer only.
:::

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Landing page** — seven sections live; authenticated users redirect to the dashboard.
- [ ] **👤 Legal pages** — `/privacy`, `/terms`, and contact route live and footer-linked.
- [ ] **🤖 Transactional email** — all five core templates deliver; SPF/DKIM/DMARC pass.
- [ ] **🔀 Pricing & payment** — products/prices created (👤), integration + webhooks wired and tested.
- [ ] **🤖 Analytics & social meta** — `sign_up`/`trial_started`/`purchase` fire; OG/Twitter cards preview.
- [ ] **🤖 No vendor name in public copy** — landing page, transactional emails, social meta, and public changelog grep clean of the CodeCanyon vendor/author/marketplace name.
- [ ] **🤖 Project state updated** — `Zaj-PROJECT.md` records landing URL, legal route URLs and policy dates, test-mode billing status, analytics/social providers, and any `Zaj-BACKLOG.md` human/legal/live-key follow-ups.

:::next[Next step]
[Support & onboarding](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/04-support-onboarding/)
:::

# 3 · Business & legal readiness

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/03-business-legal/

## TL;DR

**Objective** — make the business side real, not a placeholder: a customer needs something to land on, a way to pay, and the legal pages that make billing legitimate, because technical green is necessary but not sufficient.

**Steps at a glance:**
1. **Build the landing page** — A real entry point (a route in the app, a marketing site, or a one-pager)
   covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing,
   social proof, and a footer CTA.
2. **Publish legal pages** — Privacy Policy at `/privacy`, Terms of Service at `/terms`, Cookie Policy (if EU/UK
   traffic), Refund / cancellation policy (if selling), plus a working contact route.
3. **Wire transactional email** — Set the from-address and from-name, then wire the core templates: welcome,
   payment succeeded, payment failed, trial-expiring, and re-engagement.
4. **Configure pricing & payment** — Choose a model (a free tier plus a premium trial is the safe default),
   create the products and prices in the payment provider, wire the billing integration and webhook handlers
   (`checkout.session.completed`, `customer.subscription.deleted`, `invoice.payment_failed`), and add the
   trial/subscription gating middleware.
5. **Install analytics & social meta** — Install analytics with `sign_up`, `trial_started`, and `purchase`
   events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

:::note[User part + done-when]
**🔀 User part** — 👤 the user owns legal approval, account authorization, secret/live-key cutover, and paid/provider decisions. 🤖 With authorized browser/API access, the agent drives non-secret dashboard setup such as products/prices, wires the integration and webhook handlers, and verifies evidence without reading secret values.

**Done when** the landing page, `/privacy` + `/terms` + contact route, transactional email, pricing/payment flow, and analytics + social meta are all live and verified on the real domain. &nbsp;·&nbsp; **⏱ ~2–3 hr** &nbsp;·&nbsp; 🔀 mixed (👤 dashboards + policy generation, 🤖 integration).
:::

## Background

A customer also needs something to land on, a way to pay, and the legal pages that make billing legitimate. Build and test the entire flow on test keys first — live keys are the Phase 12 production switch.

Read `Zaj-PROJECT.md` first so the landing URL, legal routes, billing provider state, analytics provider, and live-key cutover owner come from the current project profile. Update it after verification with policy version dates, non-secret provider IDs, test-mode status, and any human-only production/legal follow-up tracked in `Zaj-BACKLOG.md`.

```mermaid
flowchart LR
  Land[Landing page] --> Pay[Test-mode checkout]
  Pay --> Legal[Terms · Privacy · Refund]
  Legal --> Live[Phase 12 live-key switch]
```

## Steps

### 1. Build the landing page

A real entry point (a route in the app, a marketing site, or a one-pager) covering the seven sections: hero with value proposition, problem, top-three solution, how-it-works, pricing, social proof, and a footer CTA. Unauthenticated visitors see it; authenticated users redirect to the dashboard.

<Steps>

1. **Publish the landing page with all seven sections** and the authenticated-user redirect.

   - ✅ Unauthenticated visitors see the landing page; authenticated users redirect to the dashboard.

</Steps>

### 2. Publish legal pages

Privacy Policy at `/privacy`, Terms of Service at `/terms`, **Cookie Policy** (if EU/UK traffic), **Refund / cancellation policy** (if selling), plus a working contact route. Cross-check the full legal bar from [Phase 10 sign-off](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/10-audit-qa/06-sign-off/) and [Phase 7 legal](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/07-security-monitoring/06-legal-gdpr/) — don't drop pages the earlier gate required.

:::note[Who does this]
👤 **User** generates the Privacy Policy and Terms from a reputable template service — a person picks and approves the policy text; an agent then wires the routes.
:::

<Steps>

1. **Wire `/privacy`, `/terms`, `/cookies` (or generator-hosted cookie policy), `/refund` (if selling), and a contact route**, all reachable from the footer.

   - ✅ Legal pages and the contact route load and are linked in the footer; cookie + refund pages match the Phase 10 bar when applicable.

</Steps>

### 3. Wire transactional email

Set the from-address and from-name, then wire the core templates: welcome, payment succeeded, payment failed, trial-expiring, and re-engagement. Confirm each actually delivers (check SPF/DKIM/DMARC pass).

<Steps>

1. **Send a test of each core template** and confirm authentication passes.

   - ✅ Welcome, payment-succeeded, payment-failed, trial-expiring, and re-engagement emails deliver with SPF/DKIM/DMARC passing.

</Steps>

### 4. Configure pricing & payment

Choose a model (a free tier plus a premium trial is the safe default), create the products and prices in the payment provider, wire the billing integration and webhook handlers (`checkout.session.completed`, `customer.subscription.deleted`, `invoice.payment_failed`), and add the trial/subscription gating middleware. Test the full path with the provider's test cards and webhook forwarder; Phase 12 performs the production live-key switch and live charge/refund gate.

:::note[Who does this]
🔀 **Authorized agent + user gate** — 👤 **User** owns pricing decisions, provider account access, secret values, and any live-money approval. 🤖 With an authorized browser/API session, the agent may create or verify non-secret Products/Prices, register test webhooks, wire the billing integration, and prove gating. Pause for password, 2FA, payout verification, tax/legal decisions, or live-mode confirmation.
:::

<Steps>

1. **Create the products/prices, then wire the webhook handlers.** Listen for `checkout.session.completed`, `customer.subscription.deleted`, and `invoice.payment_failed`, and add the trial/subscription gating middleware.

   - ✅ The full path clears with the provider's test cards and webhook forwarder, and gating middleware enforces the trial/subscription.

</Steps>

### 5. Install analytics & social meta

Install analytics with `sign_up`, `trial_started`, and `purchase` events, and add Open Graph + Twitter Card tags (with a 1200×630 image) so shared links preview correctly.

<Steps>

1. **Fire the three events and add the social tags.**

   - ✅ `sign_up`, `trial_started`, and `purchase` events register, and a shared link previews with the correct OG/Twitter card.

</Steps>

:::caution[Live keys are the last switch]
Build and test the entire payment flow on **test** keys. Phase 12 swaps to live keys only after the end-to-end test passes — and confirms the keys in both `.env` and any in-database settings table agree.
:::

:::caution[Public-facing copy must never name the CodeCanyon vendor]
The landing page, welcome/transactional emails, social meta, and any release notes or in-app "what's new" are **customer-facing** — they must carry **only your product's brand**, never the underlying CodeCanyon script, author, or marketplace (e.g. the vendor's product name, "CodeCanyon", "Envato", or an `author-vX` baseline tag). The vendor's demo content frequently leaks its own name into hero copy, footers, email templates, and seeded pages. Grep every public surface before launch:

```bash
# Replace the alternation with YOUR vendor's actual product/author name(s).
grep -rIiE 'codecanyon|envato|author-v[0-9]|<vendor-product-name>' \
  resources/views/ resources/lang/ public/ 2>/dev/null \
  && echo "  🔴 vendor name leaked into a public artifact — scrub before launch" \
  || echo "  ✅ no vendor name in public-facing copy"
# Also fetch the live landing page + a rendered welcome email and grep the HTML.
curl -s https://<your-domain>/ | grep -iE 'codecanyon|envato|<vendor-product-name>' && echo "  🔴 leak on the live landing page" || echo "  ✅ landing page clean"
```

An *internal* changelog may record the vendor base and `author-vX` for update tracking; the **public** changelog/release notes carry your project name and your own SemVer only.
:::

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Landing page** — seven sections live; authenticated users redirect to the dashboard.
- [ ] **👤 Legal pages** — `/privacy`, `/terms`, and contact route live and footer-linked.
- [ ] **🤖 Transactional email** — all five core templates deliver; SPF/DKIM/DMARC pass.
- [ ] **🔀 Pricing & payment** — products/prices created (👤), integration + webhooks wired and tested.
- [ ] **🤖 Analytics & social meta** — `sign_up`/`trial_started`/`purchase` fire; OG/Twitter cards preview.
- [ ] **🤖 No vendor name in public copy** — landing page, transactional emails, social meta, and public changelog grep clean of the CodeCanyon vendor/author/marketplace name.
- [ ] **🤖 Project state updated** — `Zaj-PROJECT.md` records landing URL, legal route URLs and policy dates, test-mode billing status, analytics/social providers, and any `Zaj-BACKLOG.md` human/legal/live-key follow-ups.

:::next[Next step]
[Support & onboarding](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/04-support-onboarding/)
:::