Checklist · Technology

Launching a Website: A Legal Compliance Checklist

15 U.S.C. § 45

Type: Checklist
Jurisdiction: National
Date: 2024-04-08
Topic: Technology

A one-stop legal compliance checklist for founders and counsel standing up a new website or web app. It stages the work in phases so the legal tasks line up against a real launch calendar rather than getting bolted on the night before go-live. Early phases cover forming the entity and securing the domain, confirming who owns the build, drafting enforceable terms of service (clickwrap versus browsewrap under Specht and Nguyen), and publishing a privacy policy that matches actual data practices. Later phases work through clearing intellectual property in content, images, and fonts, registering a DMCA Section 512 agent and adopting a repeat-infringer policy, understanding Section 230 for user-generated content, and meeting ADA Title III accessibility expectations after Robles v. Domino's. A final track addresses the FTC Act, CAN-SPAM email rules, auto-renewal "click to cancel" laws, e-commerce disclosures, and basic data-security obligations. A running Foxglove & Co. hypothetical makes each phase concrete, and a consolidated one-glance checklist closes the document.

Launching a Website: A Legal Compliance Checklist

Technology > Internet | Published 8 April 2024 - Updated 2 June 2025 | UpLaw - uplaw.us

A website is a contract, a publication, a store, and a data-collection machine all at once. The law treats it as each of those things simultaneously — and the day you press "publish" is the day every one of those obligations attaches. This checklist is the pre-flight for that moment.

Keywords: website launch, terms of service, clickwrap vs. browsewrap, privacy policy, DMCA safe harbor, Section 230, ADA accessibility, WCAG, CAN-SPAM, FTC endorsements, e-commerce disclosures, auto-renewal, user-generated content, IP clearance

How to use this checklist

Launching a website feels like a design and engineering project, so the legal work tends to get bolted on the night before go-live — or three angry emails after. That is backwards. Most of the expensive mistakes (an unenforceable arbitration clause, a privacy policy that contradicts the code, a DMCA agent nobody registered) are cheap to prevent and painful to cure. This document organizes the work into phases you can actually stage against a launch calendar, each with real check items, a short "why it matters, and the traps" explanation, and a running example.

Our worked example is Foxglove & Co., a fictional direct-to-consumer botanical-skincare startup launching its first website: a marketing storefront, a checkout, an email newsletter, and — the part that will generate most of the legal questions — customer product reviews with photos. Foxglove is small, bootstrapped, and about to make every classic mistake unless someone stops it. That someone is you.

Work the phases roughly in order, but treat the last three (accessibility, advertising/email, and e-commerce/security) as parallel tracks that must all clear before launch. If you want the broader map of this practice area, keep The Website and Internet Law Toolkit open in a second tab; this checklist is the go-live procedure, that toolkit is the whole library.

Phase 1 — Foundation: entity, domain, and who owns the build

[ ] Form (or confirm) the operating entity before the site goes live, so the website, domain, and contracts sit inside a liability shield rather than in a founder's personal name.
[ ] Register the domain name in the company's legal name, not a developer's or founder's personal account; confirm the registrar record, admin email, and auto-renew are under company control.
[ ] Run a trademark screen on the business name and domain before you print it on anything — a domain is not a trademark, and owning foxglove.co does not clear you to use "Foxglove" as a brand.
[ ] Get a written IP assignment from every developer, designer, agency, and freelancer who touched the site — code, copy, logo, photography, and the design comps.
[ ] Confirm the assignment covers work already done (many contractors start building before the contract is signed) and includes a present-tense "hereby assigns" grant plus a further-assurances clause.
[ ] Inventory third-party components (themes, plugins, stock assets, open-source libraries) and record each license.

Why it matters, and the traps. Two silent title problems sink more launches than any statute. First, the domain: register it in the company name with company billing, or a departing contractor can hold your homepage hostage. Second — and this is the big one — you do not own what your contractor builds unless a signed writing says so. Under U.S. copyright law, an independent contractor is the author and first owner of what they create; the "work made for hire" doctrine does not automatically capture commissioned code or graphics, because software and most website assets are not among the nine enumerated categories eligible for hire-by-commission. That means the agency that coded your checkout owns the copyright in that code until it assigns it to you in writing. See Determining Work Made for Hire: A Practical Checklist for the analysis and the assignment language that fixes it. On the naming side, clear the brand early with Clearing a New Trademark: A Practical Checklist, and understand why the domain registration alone buys you nothing at the trademark level in Top-Level Domains and Trademark Rights: An Overview. For the surrounding corporate hygiene — entity choice, founder equity, the whole formation stack — The Small Business Legal Toolkit and Incorporating a Startup the Right Way: A Founder's Legal Checklist are your references.

Foxglove example. Foxglove hired a freelance developer on a handshake and a Figma file. The site looks great. But the freelancer's contract is a one-line Upwork message, there is no copyright assignment, and the logo designer used a licensed font in the wordmark whose license does not permit embedding it as a logo. Before launch, Foxglove papers a proper assignment with both contractors, re-checks the font license, and moves the domain out of the developer's personal Namecheap account into a company account. Cost: an afternoon. Cost of skipping it: discovered during a Series A diligence review, when a clean chain of title suddenly has real money riding on it.

Phase 2 — Enforceable terms of service: clickwrap vs. browsewrap

[ ] Draft Terms of Service (a.k.a. Terms of Use) covering acceptable use, disclaimers of warranty, limitation of liability, governing law and venue, and — if you want it — an arbitration/class-action-waiver clause.
[ ] Present the terms as clickwrap: a checkbox or an "I agree" button the user must affirmatively click, with the terms hyperlinked and conspicuous, at account creation and/or checkout.
[ ] Avoid relying on browsewrap — a bare footer link with no affirmative assent — for anything you actually need to enforce.
[ ] Capture and log the moment of assent: timestamp, terms version, and what the user was shown, so you can prove the contract later.
[ ] Version your terms; when you materially change them, re-prompt existing users for assent rather than relying on "continued use."
[ ] Make sure any arbitration clause is presented conspicuously and mutually — courts scrutinize hidden arbitration terms hardest.

Why it matters, and the traps. Your terms are only worth what a court will enforce, and enforceability turns almost entirely on how you obtained assent, not on how good the drafting is. The foundational cases draw a bright practical line. In Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002), the Second Circuit (Sotomayor, J.) refused to enforce an arbitration clause where the license terms sat below the download button, invisible unless the user scrolled — there was no reasonable notice, so no assent, so no contract. In Nguyen v. Barnes & Noble Inc., 763 F.3d 1171 (9th Cir. 2014), the Ninth Circuit likewise declined to enforce a browsewrap arbitration provision, holding that "the onus must be on website owners to put users on notice of the terms," and that a conspicuous hyperlink alone, without any action manifesting agreement, does not bind an ordinary user. The lesson is not subtle: clickwrap wins, browsewrap loses. A checkbox that says "I have read and agree to the Terms of Service" with a working hyperlink, that the user must click to proceed, is enforced routinely; a gray footer link is not. The corollary trap is the "continued use = acceptance" theory for updates — courts are increasingly hostile to it, so re-prompt for assent on material changes.

Foxglove example. Foxglove's template put a "Terms" link only in the footer. When it later needs to enforce its no-scraping and arbitration provisions against a competitor harvesting its catalog, that footer link is a browsewrap problem. Foxglove re-architects checkout so that placing an order requires ticking "I agree to the Terms of Service and Privacy Policy," logs the assent event with a version stamp, and keeps every prior version of the terms. (For why the anti-scraping term matters and where its limits are, see Web Scraping and the Law After hiQ v. LinkedIn: Where the CFAA, Contract, and Copyright Collide.) And if a dispute ever turns on proving what a user saw and agreed to, the evidentiary discipline in Getting Website Evidence Admitted: A Practical Authentication Checklist is what turns your logs into admissible proof.

Phase 3 — Privacy policy and data practices

[ ] Map what personal data the site actually collects: form fields, account data, cookies and analytics, payment data, IP addresses, and anything third-party scripts (ads, pixels, chat widgets) collect on your behalf.
[ ] Publish a Privacy Policy that matches the code — what you collect, why, who you share it with, how long you keep it, and users' rights and choices.
[ ] Determine which privacy regimes reach you: state comprehensive laws (California/CCPA-CPRA, Virginia, Colorado, and the growing list), sector laws (HIPAA, GLBA, COPPA if under-13 users are possible), and the GDPR if you have EU visitors.
[ ] Add the specific disclosures and mechanisms your applicable laws require (e.g., a "Do Not Sell or Share My Personal Information" link and opt-out-preference-signal handling under California law).
[ ] Link the privacy policy at every collection point and in the clickwrap assent.
[ ] Stand up a process to actually honor consumer rights requests (access, deletion, correction, opt-out) within statutory deadlines.

Why it matters, and the traps. The single most common — and most dangerous — privacy mistake is a policy that describes a company you are not. A template that promises "we never share your data with third parties" while your site runs a Meta pixel and Google Analytics is not a shield; it is a written admission of a deceptive practice the FTC and state AGs can enforce under FTC Act § 5, 15 U.S.C. § 45. The policy is a factual representation, so it has to be true. The second trap is treating the policy as the whole job: publishing rights (deletion, access, opt-out) that you have no operational ability to fulfill just converts a compliance gap into a documented promise you are breaking. Build the policy from a real data map, and build the intake process before you publish the rights language. The full drafting procedure lives in Drafting a Privacy Policy: A Practical Checklist, the fulfillment mechanics in Responding to a Data Subject Access Request: A Practical Checklist, and the program-level governance in Standing Up a Privacy Compliance Program: A Practical Checklist.

Foxglove example. Foxglove's reviews feature lets customers upload photos, and its checkout collects shipping addresses and (through Stripe) payment tokens. Its off-the-shelf policy said none of that. Foxglove data-maps every field and third-party script, rewrites the policy to describe the pixel and analytics, adds a California opt-out link, and — because a photo of a person is personal data — adds a line about review-photo retention and a way to request deletion. Now the words on the page match the bytes on the wire.

Phase 4 — IP clearance: content, images, fonts, and the name

[ ] Confirm you have a license or ownership for every image, icon, illustration, video, and audio clip on the site — including "found on Google" images, which are almost never free to use.
[ ] Verify font licenses cover web embedding (a desktop font license usually does not permit @font-face webfont use, and rarely permits use in a logo).
[ ] Confirm stock-asset licenses cover your actual use (commercial use, web distribution, and the number of impressions/seats).
[ ] Check open-source component licenses for attribution and copyleft obligations before shipping.
[ ] Consider registering copyright in your original site content and code once the site is stable.
[ ] Confirm the brand name and logo are cleared for trademark use (Phase 1) and not infringing a senior mark.

Why it matters, and the traps. Website infringement claims are a cottage industry, and the two most common are photographs and fonts. Stock-photo enforcers run reverse-image searches and send demand letters for a single unlicensed thumbnail; a "we found it online" defense is worthless because copyright attaches automatically and ignorance is not a defense to liability. Fonts are the sneakier trap: type designs, font software, and font names are protected differently, and a desktop license almost never authorizes converting the font to a webfont or baking it into a logo — the exact hole Foxglove fell into in Phase 1. See The Fine Line: Copyright Protection for Style, Typefaces, and Fonts for why fonts are so counterintuitive. Once your original content is settled, registering it is cheap insurance that unlocks statutory damages and fees against copyists — the mechanics are in Copyright Registration for a Website: A Practical Checklist. For the pre-launch clearance mindset across every IP layer, The IP Clearance Toolkit: Securing Freedom to Operate Before You Launch is the deep reference.

Foxglove example. Foxglove's homepage hero image is a gorgeous botanical shot the designer "grabbed for the mockup." It is a licensed stock image whose comp watermark was cropped out. Foxglove either buys the proper license or replaces it with its own product photography, and it swaps the wordmark font for one whose license explicitly allows logo use. Small swaps now; no demand letter later.

Phase 5 — DMCA safe harbor: the Section 512 agent and repeat-infringer policy

[ ] Decide whether your site hosts user-uploaded content (Foxglove's reviews and photos qualify); if so, you are a "service provider" who can and should claim the § 512(c) safe harbor.
[ ] Designate a DMCA agent and register that agent with the U.S. Copyright Office through its online directory — and pay the fee. This is mandatory; an unregistered agent means no safe harbor.
[ ] Post the agent's contact information conspicuously on the site (a "Copyright / DMCA" page linked in the footer is standard).
[ ] Adopt, publish, and actually implement a repeat-infringer termination policy.
[ ] Build a notice-and-takedown workflow: intake valid takedown notices, remove/disable the material expeditiously, notify the uploader, and honor valid counter-notices.
[ ] Renew the agent registration every three years (the Copyright Office registration lapses if not renewed).

Why it matters, and the traps. Section 512 of the DMCA, 17 U.S.C. § 512, is a bargain: if you host content your users upload, you can be shielded from liability for their infringement — but only if you earn the safe harbor by meeting every gate. The two most-missed gates are the agent registration and the repeat-infringer policy. The agent must be registered through the Copyright Office's electronic directory, not merely named on your website; skip the federal registration and you forfeit the safe harbor entirely, no matter how promptly you take things down. And the repeat-infringer policy cannot be a paper tiger — courts have denied the safe harbor to providers who published a policy but never actually terminated repeat infringers. The full compliance program, including the "expeditiously" standard and the red-flag-knowledge disqualifier, is laid out in Staying Inside the DMCA Safe Harbor: A Compliance Checklist and, from the service-provider's structural view, The DMCA Safe Harbors: How Online Service Providers Earn Protection From User Infringement. When a notice comes in — from either side — DMCA Takedowns and Counter-Notices: Both Sides of the Notice-and-Takedown System walks the workflow.

Foxglove example. Because customers upload review photos, a customer could someday upload a competitor's copyrighted image. Foxglove registers a DMCA agent with the Copyright Office (twenty minutes, small fee), posts a DMCA page, adds a "three strikes" repeat-infringer clause to its terms, and wires review moderation to a takedown inbox. If an infringing photo ever lands in a review, Foxglove is a protected service provider instead of a co-defendant.

Phase 6 — User-generated content and Section 230

[ ] Identify every place users can post content: reviews, ratings, photos, comments, Q&A, forum posts.
[ ] Understand that 47 U.S.C. § 230 generally immunizes you from liability for what your users say — but not for content you create or materially develop yourself.
[ ] Keep a clean line between hosting/moderating user content (protected) and authoring or editing it into something misleading (not protected).
[ ] Note the carve-outs: § 230 does not apply to federal criminal law, to intellectual-property claims, or (post-FOSTA) to certain sex-trafficking claims — so it will not save you from a copyright claim (that is what the DMCA safe harbor is for).
[ ] Write content-moderation and community rules into the terms, and preserve your right to remove content — § 230(c)(2) protects good-faith moderation.
[ ] Avoid materially altering user reviews (e.g., editing a 2-star review into a 5-star endorsement), which forfeits immunity and creates FTC exposure.

Why it matters, and the traps. Section 230 is the reason a small site can host thousands of customer reviews without being sued into oblivion for each one: "No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider." It immunizes you for third-party content and, separately, for your good-faith decisions to moderate. But two limits trap the unwary. First, the IP carve-out: § 230(e)(2) expressly excludes intellectual-property claims, so a user's infringing photo is a copyright problem you solve with the DMCA safe harbor (Phase 5), not with § 230 — the interaction between the two is exactly the subject of Section 230, the IP Carve-Out, and Platform Liability for User-Generated Infringement. Second, immunity is for content you host, not content you create: if you write, materially edit, or curate reviews into a misrepresentation, you become the "information content provider" and lose the shield. For the whole legal stack around social and user-generated features, see Social Media Law: A Field Guide to the Legal Stack.

Foxglove example. Foxglove's marketing lead wants to "clean up" negative reviews and quietly delete one-star ratings from the display average. That is the fastest way to convert a § 230-immune review platform into an FTC deception case (see Phase 8) and to look like the developer of the content rather than its host. Foxglove instead adopts neutral moderation rules, applies them evenly, and displays reviews honestly.

Phase 7 — Accessibility under the ADA

[ ] Treat the site as covered by Title III of the ADA if you are a place of public accommodation or the online arm of one — most consumer-facing commercial sites should assume coverage.
[ ] Adopt WCAG 2.1 (or later) Level AA as your working technical standard; it is the de facto benchmark courts and the DOJ point to.
[ ] Run an automated accessibility scan, then a manual audit (keyboard navigation, screen-reader testing, alt text, color contrast, focus order, form labels).
[ ] Fix the high-impact issues before launch: images without alt text, unlabeled form fields, poor contrast, content that is unreachable by keyboard, and inaccessible checkout flows.
[ ] Publish an accessibility statement with a contact channel for users who hit barriers, and log and remediate complaints.
[ ] Extend the same standard to third-party widgets (chat, booking, payment) — you can be liable for inaccessible embedded components.

Why it matters, and the traps. Website-accessibility litigation is one of the highest-volume areas of consumer-facing legal risk, and the anchor case is Robles v. Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019). There, a blind customer could not order using Domino's website and app with his screen reader; the Ninth Circuit held that the ADA applies to the online offerings of a business with physical locations, and the Supreme Court declined to review it — leaving the plaintiff's theory intact. The Americans with Disabilities Act, 42 U.S.C. § 12181 et seq., does not itself publish pixel-level rules, which is precisely the trap: the absence of a formal regulation is not a safe harbor, and defendants who waited for perfect regulatory clarity have lost. Courts and the DOJ consistently treat WCAG 2.x Level AA as the practical yardstick, so build to it. The other trap is embedded third-party content: an inaccessible chat widget or payment iframe can generate a claim even though you did not write it.

Foxglove example. Foxglove's beautiful low-contrast sage-on-cream palette fails WCAG contrast checks, its product images lack alt text, and its checkout cannot be completed with a keyboard alone. A single automated scan plus an hour of screen-reader testing surfaces all of it. Foxglove bumps contrast, adds alt text to every product photo, fixes the checkout focus order, and posts an accessibility statement with an email address. These are the cheapest legal fixes on the entire list and the ones most likely to draw a demand letter if skipped.

Phase 8 — Advertising, endorsements, cookies, and CAN-SPAM email

[ ] Make sure every product and marketing claim on the site is truthful and substantiated — FTC Act § 5, 15 U.S.C. § 45, prohibits unfair or deceptive practices.
[ ] Disclose material connections in endorsements: paid influencers, affiliate links, and — critically — incentivized reviews must be clearly disclosed under the FTC's endorsement guidance.
[ ] Do not fabricate, suppress, or buy fake reviews; present reviews honestly (this ties directly to Phase 6).
[ ] Handle cookies and tracking consistently with your privacy policy and applicable law (consent banners where required).
[ ] For commercial email, comply with the CAN-SPAM Act, 15 U.S.C. § 7701 et seq.: no false or misleading headers, no deceptive subject lines, identify the message as an ad where required, include a valid physical postal address, and provide a working opt-out honored within 10 business days.
[ ] Never charge a fee or require anything beyond an email address to unsubscribe, and don't sell or transfer an address after an opt-out.

Why it matters, and the traps. The FTC treats your website copy, your reviews, and your email as one advertising surface. The endorsement rules are where honest founders stumble: if you give customers a free product or a discount in exchange for a review, that is a material connection that must be disclosed, and a review section that mixes incentivized and organic reviews without disclosure is a deception problem. Suppressing negative reviews (Phase 6) and gating warranty coverage on posting a positive review are both on the FTC's enforcement radar. On email, CAN-SPAM's requirements are mechanical but strictly enforced per-message, so bake the physical address and one-click unsubscribe into your email templates from day one — the full procedure is in CAN-SPAM Compliance for Commercial Email: A Practical Checklist. For the broader advertising-law map — claim substantiation, comparative advertising, pricing, sweepstakes — see The Advertising and Marketing Law Toolkit and the small-business primer Advertising Law for Small Businesses: A Practical FAQ.

Foxglove example. Foxglove seeds its launch with a "review and get 20% off" campaign. Those reviews are incentivized, so Foxglove adds a clear "I received a discount for this review" badge, keeps organic and incentivized reviews visibly distinct, and stops its plan to hide the two-star reviews. Its welcome-email template gets a physical mailing address in the footer and a one-click unsubscribe that actually works.

Phase 9 — E-commerce, auto-renewal, consumer disclosures, and data security

[ ] Post clear pre-purchase disclosures: total price, shipping and taxes, and all material terms before the customer commits.
[ ] For any subscription or auto-renewing plan, meet automatic-renewal law requirements: clear and conspicuous disclosure of the recurring charge and terms, affirmative consent to the recurring charge, and an easy online cancellation path ("click to cancel").
[ ] Publish a plain-language refund, return, and shipping policy, and honor it.
[ ] Handle payments through a PCI-DSS-compliant processor; avoid storing raw card data yourself.
[ ] Secure the site: HTTPS/TLS everywhere, encrypt sensitive data at rest and in transit, patch and update components, enforce access controls, and keep a data-breach response plan.
[ ] Know your breach-notification duties — all fifty states have breach-notice statutes with their own timelines and content requirements.
[ ] Confirm you are not unintentionally collecting data from children under 13 (COPPA) through your store or reviews.

Why it matters, and the traps. Two areas generate outsized enforcement here. Auto-renewal is a top priority for the FTC and state AGs: the negative-option/"click to cancel" rules require that canceling be at least as easy as signing up, and "call this number during business hours to cancel" is exactly the kind of dark pattern regulators target. Data security failures are prosecuted under FTC Act § 5 as unfair practices even without a specific security statute — the FTC's position is that failing to implement reasonable security is itself an unfair practice, and a breach turns your privacy promises into liabilities. The trap that ties this phase to Phase 3 is consistency: if your privacy policy promises "reasonable security" and you store card data in plaintext, the promise is the violation. For the program-level view of data governance and breach readiness, Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork is the reference.

Foxglove example. Foxglove adds a "Foxglove Refill Club" subscription. It discloses the recurring $29/month charge clearly at checkout, takes a separate affirmative check for the recurring charge, and builds a one-click in-account cancel button — no phone tree. It routes all payments through Stripe (so it never touches raw card numbers), forces HTTPS, and writes a one-page breach-response plan naming who calls counsel and who notifies customers if the worst happens.

Common mistakes to avoid

Relying on a footer "Terms" link (browsewrap) for anything you need to enforce. Specht and Nguyen make clickwrap assent the difference between an enforceable contract and a decoration.
Assuming you own the code because you paid for it. Without a written assignment, your contractor owns the copyright — the work-made-for-hire default does not rescue you.
Publishing a template privacy policy that doesn't match your site. A policy that omits your analytics, pixels, and review photos is a documented FTC § 5 deception, not protection.
Naming a DMCA agent on your site but never registering it with the Copyright Office. The federal registration is the gate; skip it and there is no safe harbor.
A paper repeat-infringer policy you never enforce. Courts deny the safe harbor to providers who publish a policy but never terminate anyone.
Confusing Section 230 with a copyright shield. The IP carve-out means § 230 does not touch infringement; that is the DMCA's job.
Waiting for "official ADA web regulations" before fixing accessibility. After Robles, the absence of pixel-level rules is not a defense — WCAG AA is the working standard.
Editing or suppressing reviews. It forfeits § 230 immunity and creates FTC deception exposure at the same time.
Incentivized reviews without disclosure, and marketing email without a physical address and working unsubscribe.
Auto-renewal without "click to cancel" and storing payment data you never needed to touch.
Registering the domain in a founder's or contractor's personal account. Control the registrar record from day one.

Consolidated launch checklist (one glance)

Foundation

[ ] Entity formed; domain registered in company name with company billing and auto-renew.
[ ] Written IP assignments from every developer, designer, and freelancer; third-party licenses inventoried.
[ ] Brand name/logo trademark-screened.

Contracts & privacy

[ ] Terms of Service presented as clickwrap; assent logged and versioned.
[ ] Privacy policy that matches the actual data map; applicable state/federal/GDPR disclosures added; rights-request process live.

IP & content

[ ] Every image, font, icon, and media asset licensed or owned; webfont and logo font rights confirmed.
[ ] Site content/copyright registration planned.

Platform liability

[ ] DMCA agent registered with the Copyright Office; DMCA page posted; repeat-infringer policy adopted and implemented; takedown workflow built.
[ ] Section 230 posture understood; neutral moderation rules; no editing reviews into misrepresentations.

Accessibility

[ ] WCAG 2.1 AA audit run and high-impact issues fixed; accessibility statement posted; third-party widgets checked.

Advertising & email

[ ] Claims truthful and substantiated; material connections and incentivized reviews disclosed; no fake/suppressed reviews.
[ ] Cookie/consent handling consistent with policy; CAN-SPAM email templates (physical address + working opt-out honored ≤10 business days).

E-commerce & security

[ ] Pre-purchase price/terms disclosed; auto-renewal "click to cancel" built; refund/return policy posted.
[ ] HTTPS everywhere; PCI-compliant processor; breach-response plan; state breach-notice duties known; COPPA checked.

For the equivalent go-live procedure on the mobile side, run it against Launching a Mobile App: A Practical Legal Checklist, which shares this DNA but adds app-store, SDK, and mobile-privacy layers.

Primary authority

47 U.S.C. § 230 — Protection for private blocking and screening of offensive material; immunity for interactive computer services from liability for third-party content, and for good-faith moderation. Note the § 230(e)(2) intellectual-property carve-out.
Digital Millennium Copyright Act, 17 U.S.C. § 512 — Safe harbors for online service providers, including the § 512(c) hosting safe harbor, the designated-agent registration requirement, and the repeat-infringer-policy condition.
Americans with Disabilities Act, 42 U.S.C. § 12181 et seq. — Title III public-accommodation nondiscrimination; Robles v. Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019), cert. denied, applying the ADA to a business's website and app; WCAG 2.x Level AA as the de facto technical standard.
CAN-SPAM Act, 15 U.S.C. § 7701 et seq. — Commercial-email requirements: accurate headers, non-deceptive subject lines, identification, physical postal address, and a functioning opt-out honored within 10 business days.
FTC Act § 5, 15 U.S.C. § 45 — Prohibition on unfair or deceptive acts or practices; the basis for enforcement of privacy-policy accuracy, advertising and endorsement rules, reasonable data security, and auto-renewal/negative-option practices.
Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002) — No enforceable assent where license terms were not reasonably conspicuous (the classic browsewrap failure).
Nguyen v. Barnes & Noble Inc., 763 F.3d 1171 (9th Cir. 2014) — Browsewrap terms unenforceable absent actual or constructive notice and an act manifesting assent; the onus is on the site owner.
17 U.S.C. § 101 (work made for hire) and § 201 — Authorship and initial ownership; why commissioned website code and graphics require a written assignment.

Related UpLaw resources

Related Guides & Articles

Related Checklists

Related Toolkits

This checklist is general legal information from UpLaw (uplaw.us), not legal advice, and does not create an attorney-client relationship. Statutes, rules, and fees change, and privacy, accessibility, and advertising requirements vary by jurisdiction; verify current requirements and consult qualified counsel before launching.