Verified against ChatGPT · 2026-08-12
Outline a Terms of Service structure scoped to what your product actually does before a lawyer fills it in
Produces a section-by-section Terms of Service outline built around your product's actual features and business model, with each section's purpose explained, so a lawyer starts from a scoped structure instead of a blank page or a mismatched template.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Build a Terms of Service outline for the product described below. I need an outline — section headings with a description of what each section needs to cover for this specific product — not full legal language, since that needs to come from a lawyer. PRODUCT DESCRIPTION A marketplace app connecting freelance photographers with clients, including in-app messaging and payments. BUSINESS MODEL Takes a 15% commission on completed bookings; free to browse and message. USER-GENERATED CONTENT OR ACCOUNTS? Users create profiles, upload portfolio images, and message each other directly. KNOWN RISK AREAS Payment disputes between clients and photographers, and potential copyright issues with uploaded portfolio images. OUTLINE-BUILDING RULES Start from what this specific product does, not a generic SaaS ToS checklist — if there's no user-generated content, don't include a content-moderation section just because most ToS documents have one; if there is, give it real weight since that's where a lot of actual dispute risk sits. For each section you include, write a short paragraph (not legal text) explaining what this section needs to address for this product specifically and why it matters here, so whoever drafts the real language later understands the purpose, not just the heading. Order sections by how central they are to this specific product's risk profile, not by whatever order a generic template uses — if payment disputes are the most likely real-world issue, that section shouldn't be buried near the bottom. Flag the sections that most need direct legal input rather than treating all sections as equally templatable — arbitration clauses, liability limitations, and any section touching a regulated activity should be marked as "needs counsel to draft this section specifically," not just reviewed after the fact. WHAT NOT TO DO Do not draft actual binding legal language for arbitration, liability limitation, or governing law clauses — describe what these sections need to accomplish and flag them for a lawyer to write, since getting this specific language wrong has outsized consequences. Do not assert that any particular clause is "standard" or "enforceable" — describe function, not legal effect. OUTPUT FORMAT 1. Ordered outline: Section heading | Purpose paragraph | Needs-counsel flag (yes/no). 2. A short summary of which 2-3 sections carry the most real risk for this specific product and why. 3. A closing note stating this is a scoping outline to prepare for a lawyer's drafting work, not usable Terms of Service language, and the actual document must be drafted or reviewed by a qualified lawyer before publishing or requiring users to accept it.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Most ToS templates are ordered and weighted by convention rather than by what actually matters for a given product, and a model asked to "outline a ToS" without product-specific grounding will reproduce that same generic ordering — requiring the product description, business model, and content/account details up front forces the outline to be scoped to this product's actual risk surface, so a marketplace with direct user messaging and payment disputes gets those sections built out and ordered near the top, while a product with none of that skips sections that would otherwise be generic filler nobody needed. Writing a purpose paragraph instead of legal language for each section is the deliberate boundary that keeps this a scoping tool rather than an unauthorized attempt at drafting binding text — a lawyer working from "here's what this section needs to accomplish and why it matters for this product" starts from genuine leverage, while a lawyer handed AI-generated arbitration or liability language has to fully re-derive it anyway, so skipping straight to fake legal language for the highest-stakes clauses would waste effort and create false confidence. Explicitly flagging which sections need direct counsel input rather than treating everything as equally templatable reflects a real asymmetry in ToS risk: liability limitation and arbitration clauses have outsized legal consequences if worded even slightly wrong and courts scrutinize them heavily, while other sections are comparatively low-stakes boilerplate — treating them identically would either waste legal review time on the boilerplate or, worse, let the highest-risk sections get treated as templatable when they're exactly the ones that need the most careful, jurisdiction-specific drafting.
What you get back
1. Payment and Commission Disputes — Purpose: since the business takes a 15% commission on bookings, this section must define how disputes between client and photographer over completed work are handled and where the commission stands if a refund occurs — Needs counsel: yes. 2. User Content and IP Ownership — Purpose: portfolio images are user-uploaded; this section needs to clarify who owns uploaded content and how copyright disputes between users are handled — Needs counsel: yes. Top risk summary: payment disputes and uploaded-content IP ownership carry the most real-world risk for this product. This is a scoping outline, not usable ToS language — a qualified lawyer must draft or review the actual document before publishing.
Verified against
ChatGPT GPT-5.1 · 2026-08-12
Changelog
- 2026-08-12 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
