Ship Terms of Service before accepting real Pro payments

[schmug]

Context

Privacy Policy is live at /legal/privacy (#169, #172). Terms of Service was deliberately left out per #169 ("remove TOS placeholder pending LLC"). With Stripe Checkout, Portal, webhooks, promo codes, and the /pricing page all live, the only thing keeping us from charging real customers is TOS.

This is the single biggest gating item for monetization launch.

Scope

• Decide entity posture:
  • Form an LLC and have TOS reflect the entity, or
  • Ship a sole-proprietor TOS in your real legal name (faster path, valid in most US states)
• Draft /legal/terms covering at minimum:
  • Acceptable use (no scanning domains you don't own/control? — or explicitly allow third-party scans since DNS is public)
  • Service availability disclaimer (no SLA on the free tier; best-effort on Pro)
  • Subscription terms: $19/mo, monthly billing, cancel-anytime via Stripe Portal, 30-day refund window (mirrors /pricing FAQ)
  • Liability cap (subscription fees paid in last 12 months)
  • Governing law / venue
  • Account termination conditions
  • Data handling pointer to /legal/privacy
• Add renderTermsPage() in src/views/legal.ts next to renderPrivacyPage()
• Wire route in src/index.ts and add to sitemap
• Add footer link next to "Privacy" in src/views/html.ts:176 and :661
• Surface in /pricing FAQ ("By subscribing you agree to the Terms")
• Add a TOS-acceptance checkbox or "by clicking Subscribe you agree" notice on the Subscribe button at /dashboard/billing/subscribe

Out of scope

• DPA / GDPR addendum (defer until first EU paying customer asks)
• AUP as a separate document (fold into TOS for v1)

Why this matters

Without a TOS we have no contract with paying customers, no liability cap, no defined venue, and no enforceable subscription terms. Stripe disputes and chargebacks become hard to defend.

[schmug]

Routine issue-cleanup pass triage note.

Classifying this as Bucket C — needs human decision first before a PR can be opened.

The blocking question is the entity posture decision:

A) Form an LLC and have TOS reflect the entity (slower, protects the business entity name, stronger liability shield)
B) Ship a sole-proprietor TOS in your real legal name (faster, valid in most US states, can convert to LLC later)

The technical implementation (renderTermsPage, route, footer link, Stripe consent notice) is straightforward once the TOS text is drafted — roughly 80–120 lines of TypeScript. The content itself is what's gating.

What needs to happen before a PR:

• Pick entity posture (A or B above)
• Draft the TOS text (or confirm you want a template/placeholder with a TODO)

Once that decision is made, the code changes can ship in a single PR.

---

Generated by Claude Code

[schmug]

Split: code scaffolding vs. legal content

The technical work here (route, view, links, footer) is straightforward and can be done in a PR now. The legal content is operator work that needs a decision first.

Questions before implementing:

1. Entity posture: LLC or sole-proprietor? This determines the party name and governs the template. If LLC isn't formed yet, is "John Doe, an individual" acceptable for v1?

2. Acceptable-use scope: Does dmarcheck explicitly permit scanning third-party domains (since DNS is public) or restrict to domains the user owns/controls? The current UI/copy doesn't restrict this — the TOS should codify whichever stance you want.

3. Governing law / venue: Which state? (Typically where you reside / the entity is formed.)

4. Refund window: The issue mentions 30-day — is that the actual policy you want in writing?

What I can do right now without the above answers:

Add renderTermsPage() stub in src/views/legal.ts, wire the /legal/terms route in src/index.ts, add footer links in html.ts:176 and :661, add the Checkout notice at /dashboard/billing/subscribe, and add to sitemap — leaving the policy body as clearly-labeled placeholder text you fill in before go-live. That unblocks the wiring so the TOS is one copy-paste away from shipping.

Reply with the 4 answers above (or "do the stub now") and I'll open a PR.

---

Generated by Claude Code

[schmug]

Triage: Bucket C — legal/entity decision gates implementation

The Terms of Service content depends on an entity posture decision that must be made by the owner before any draft can be written:

Decision needed:

1. Sole proprietor TOS (faster, legally valid in most US states): drafted in your real legal name, no entity formation required. Can ship this week.
2. LLC TOS: requires forming the LLC first (weeks to months depending on state). Cleaner liability cap.

Once the entity decision is made, the implementation is straightforward:

• renderTermsPage() in src/views/legal.ts (mirrors renderPrivacyPage())
• Route in src/index.ts at /legal/terms
• Footer link in src/views/html.ts (two locations)
• Sitemap addition
• /pricing FAQ "by subscribing you agree" line
• Subscribe page acceptance notice at /dashboard/billing/subscribe

Key content requirements (entity-agnostic):

• Acceptable use: third-party DNS scans are explicitly permitted (DNS is public)
• Service availability: no SLA on free; best-effort on Pro
• Subscription terms: $19/mo, monthly billing, cancel-anytime via Stripe Portal, 30-day refund window
• Liability cap: subscription fees paid in last 12 months
• Governing law / venue
• Data handling pointer to /legal/privacy

Blocked on: owner confirming sole-proprietor vs. LLC posture. Once decided, this becomes a Bucket A code PR (no design questions remaining).

---

Generated by Claude Code

[schmug]

Spec draft — Terms of Service (bucket C)

Blocker: The issue lists two entity postures as a decision point. This is an owner-only decision that gates all implementation.

Entity decision options

Option A — Sole proprietor TOS (ship in days)

• Use your real legal name (e.g., "Cory Schmug, an individual")
• Valid in all US states for B2C SaaS
• No formation fees or state registration delays
• Can convert to LLC later with a TOS amendment
• Risk: personal liability not limited to entity assets

Option B — Form LLC first, then TOS (ship in weeks)

• Wyoming or Delaware single-member LLC (~$50–100/yr)
• Cleaner liability cap
• Adds 1–4 weeks for state registration + EIN
• TOS references the entity name

Proposed default: Option A (sole proprietor). The liability cap in the TOS itself (limited to subscription fees paid in last 12 months) is the operative protection for a $19/mo SaaS at this scale, not the entity form. The LLC adds negligible practical protection relative to that cap. Ship the TOS under your real name now; convert to LLC name in a one-line amendment later.

Code implementation (ready to execute once entity decision is made)

Once the entity posture is confirmed, the implementation is straightforward and fits bucket A:

• src/views/legal.ts: add renderTermsPage() (mirrors existing renderPrivacyPage())
• src/index.ts: wire /legal/terms route, add to sitemap
• src/views/html.ts: add footer link at lines ~176 and ~661
• /pricing page: add "By subscribing you agree to the Terms" copy
• /dashboard/billing/subscribe: add "by clicking Subscribe you agree to the Terms" notice

Owner action needed to unblock: Confirm entity posture (Option A or B). Draft TOS content itself is owner-authored (legal content can't be auto-generated). Once you have the content, the code wiring can ship in a single PR.

---

Generated by Claude Code

[schmug]

Triaged as bucket C — the code scaffolding is straightforward, but the TOS content requires owner decisions before anything can ship.

Two blocking decisions needed:

1. Entity posture: Sole proprietor (fastest — use legal name, no LLC overhead) or LLC (more liability protection, but formation takes weeks and requires an address)? The TOS template differs depending on which you choose.

2. Acceptable use on scanning third-party domains: DNS is public, so scanning any domain is technically legal — but should the TOS explicitly permit or restrict scanning domains the user doesn't own/control? Current /check has no restriction. A permissive policy ("DNS is public data; scans are informational") is simpler and consistent with existing behavior.

Once decided, the code is a single PR:

• renderTermsPage() in src/views/legal.ts (next to renderPrivacyPage())
• Route in src/index.ts
• Footer link in src/views/html.ts lines 176 + 661
• Sitemap entry
• TOS-acceptance notice on the Subscribe button

The TOS text itself should be drafted/reviewed by you before the PR — paste it as a comment here and the implementation can ship within a day.

---

Generated by Claude Code

[schmug]

Spec question: the code scaffolding is straightforward, but the TOS text itself must come from you.

The technical work (adding renderTermsPage() in src/views/legal.ts, wiring the route in src/index.ts, footer links, sitemap, /pricing FAQ reference, TOS-acceptance notice on subscribe) is well-defined and I can implement it in one PR. The blocker is the actual legal text.

The issue lists the required sections: acceptable use, service availability disclaimer, subscription terms ($19/mo, cancel-anytime, 30-day refund), liability cap, governing law/venue, account termination, data handling pointer to /legal/privacy.

Two questions before I can ship this:

1. Entity posture: LLC or sole proprietor? The TOS must reference one or the other. If LLC, do you have a name yet?
2. Legal text: Should I draft a placeholder TOS covering all the required sections (clearly marked [DRAFT — REVIEW BEFORE GOING LIVE]), or do you want to supply the text?

If you're OK with a draft-placeholder approach, I can ship the full implementation with a clearly-marked draft TOS so the route is live and the code is done — you review and edit the text before enabling real payments. Let me know and I'll open the PR.

---

Generated by Claude Code