Don't get yourself in trouble, legal, risk & compliance for builders

This is the lesson that nobody else teaches, and that most beginners never get told about until they have already triggered one of the things in it. We are not going to make you a lawyer. We are going to give you the practitioner's-eye view, which is enough to keep you out of the most common kinds of trouble.

If you are building something for yourself, in private, with no users, you can skim this lesson. If you are about to put anything in front of real humans (free or paid), this is the lesson you cannot skip.

The "would I say this offline" test

Before we get to documents, here is a single test you can apply to almost any decision in your build that has a legal flavor.

Imagine the action your software is about to take, but performed by a human in the offline world. Would the human get away with it?

• Sending unsolicited marketing emails to a million people. Offline equivalent: knocking on a million doors uninvited. Most jurisdictions regulate this heavily.
• Storing biometric data without consent. Offline equivalent: photographing strangers' fingerprints. Even more regulated.
• Charging cards without showing the price first. Offline equivalent: handing the customer the bill after they ate. Most jurisdictions require pre-disclosure.
• Sharing a user's data with a partner without telling them. Offline equivalent: telling someone's secrets to a third party they did not consent to.

The test is not a substitute for actual legal advice. It is a good first filter, and it gets most of the worst decisions before they happen.

The four documents every public-facing build needs

Almost every product that touches the public has four documents somewhere. You can write the first version of each in an afternoon, with AI help, and then have a lawyer review them later if the product gets serious.

Terms of Service. The contract between you and the user. What they can do, what you can do, what happens if either of you breaks the deal. Standard sections include account rules, payment terms, dispute resolution.

Privacy Policy. What data you collect, why, how long you keep it, who you share it with. This is the one most regulated by law (GDPR in Europe, CCPA in California, others elsewhere). Be specific and honest. Boilerplate that lies about what you actually do is worse than no policy.

Disclaimer. What your product is not responsible for. Especially important for anything involving health, finance, legal, or other areas where users might mistake your output for professional advice.

Contact. How a user reaches you when something is wrong (account issues, data requests, legal questions). This is sometimes the only thing standing between a small problem and a public escalation.

For your Day 15 idea, write down which of the four you would need before shipping. For most builds, the answer is all four.

AI-specific disclosure

If your build uses AI in a user-facing way (Day 17 Roles 2, 3, or 4), three additional disclosures matter.

Tell users when they are interacting with AI. Most jurisdictions now require this for chatbots, and the regulation is getting stricter every year. The disclosure does not have to be loud, it just has to exist.

Don't claim AI output is professional advice. "This summary is generated by AI and may contain errors" is a useful boilerplate.

Be specific about which model you use and what happens to user input. If you send user data to OpenAI or Anthropic, your users should know. If their data is used to train future models, your users should definitely know, and most providers now let you opt out of that.

The IP rules nobody mentions

Two short ones.

You do not own AI-generated content the same way you own human-created content, in many jurisdictions. Pure AI output is increasingly not copyrightable. If copyright matters to your build (you are making a stock-image site, for example), this is a real consideration.

Don't use AI to reproduce other people's protected content. "Make me an image in the style of [living artist]" is a problem in some jurisdictions and a publicity nightmare in all of them. "Summarize this paywalled article" is a problem in most jurisdictions. The AI does not know it is doing something legally questionable, you have to.

Privacy obligations that kick in the moment you collect data

The minute you store anything about an identifiable person, several obligations attach.

• The right to know. Users can ask what you have on them. You must be able to answer.
• The right to delete. Users can ask you to erase their data. You must be able to.
• Breach notification. If your database gets compromised, you have to tell affected users (and, in some jurisdictions, regulators) within a specific window, usually 72 hours.
• Data residency. Some jurisdictions require certain data to stay in certain countries. Hosting providers (Day 12) usually let you pick a region for this reason.

None of these require you to be a lawyer. All of them require you to know they exist and to design your build so they are achievable.

The one-page legal sanity checklist

Before you ship anything public, answer these in writing.

• I have a Terms of Service, a Privacy Policy, a Disclaimer (if relevant), and a Contact path.
• If I use AI in a user-facing role, I tell users.
• I have a way to honor a "delete my data" request.
• I know which jurisdiction's privacy law applies to my users.
• I have a plan for what I do if my database gets breached.

If any of these is "no," delay shipping until it is "yes." Day 21 will come back to this.

Forward references

Day 21 closes the course, including the moment where you commit to running both the Day 19 and the Day 20 checklists on your build before you push it live.

Day 20 wrap

The thing you can now say plainly. Public-facing builds have legal obligations that kick in the moment users show up, including four documents, AI-specific disclosures, IP awareness, and privacy rules. Most are addressable in an afternoon, with AI help.

The thing you can now do. Apply the "would I say this offline" test to anything your build is about to do, and use the one-page legal sanity checklist before shipping.

The guardrail to remember. The thing that gets builders sued is rarely the build itself. It is the surprise communication ("we never said we would store this"), and most of that is preventable with one good Privacy Policy.

See you on Day 21, the closer.