Liability, Contracts, and Code Insurance

Let’s skip the performance. No launch thread, no confetti charts. Just you, me, and the part of building we both try not to look at. You know the place. After deploy, before consequences. The room where it is very quiet, where logs blink in that polite way right up until they don’t.

We tell ourselves it is just code. A weekend sprint, a neat UI, a clever reducer. Users see something else. They see a button that says pay. They see a promise. Promises have physics. They do not care how little sleep you had, or that the framework changed names again. They care who pays when the thing fails.

You can ship features quickly. You cannot ship away liability.

Fast, then real

Everything got fast. Copilots completing your thoughts, AI Agents that make your app look like it knows what it is doing. Feels good. Speed is a gift, with a shadow attached.

The shadow is boring words that become very loud on bad days. Insurance. Contracts. Security. The parts that do not care about your gradient. The parts that decide how painful the after is.

This is not legal advice. Not even advice-advice. It is a map of the hallway, so you do not pretend there is no hallway.

What contracts really are, to someone who just builds

If the word “contract” makes your eyes slide off the page, try this instead.

• A contract is a boundary. It says where your promise ends. Without one, there is no edge. If there is no edge, there is only you.
• A contract picks the room where a fight happens, and the rules inside that room. If you do not pick, someone else will, and they will pick a room you do not like.
• A contract decides remedies. What you owe when things go wrong. Money, credits, nothing, something. Decide on a calm day, or the loud day decides for you.

You may call it ToS on your site. You may call it an MSA when a bigger customer sends a PDF that weighs a gigabyte somehow. Same idea. Boundaries, room, remedy.

If you only remember one thing about contracts, make it this. Promises you cannot keep turn into liabilities you cannot carry. Speak softly about uptime. Speak carefully about data. Speak only about what you will actually do on a bad day, not what you wish you would do.

“Code insurance” in human words

Nobody calls it that, but you will. Because one day someone asks whether you have it, and you realize you do not know what “it” is. So, here is a translation layer, the kind that helps you walk into a broker call without feeling like an imposter.

• Tech E&O
  Errors and omissions for software people. You promised a service, it failed, a customer says they lost money. This is the one that responds to “your app broke our thing.” It cares about what you promised and what you delivered. It often does not pay for everything, and it loves exclusions. But it is the right bucket for the classic outage finger-point.
• Cyber liability
  Two halves. First party and third party.
  First party is your mess: forensics, incident response, legal counsel, notification to users, credit monitoring, PR, sometimes ransom negotiation. Third party is other people’s claims: users, customers, regulators. If data leaks, this is the policy that gets the first phone call.
• General liability
  Old world stuff. Someone trips in your office, something physical breaks. If you are pure SaaS, this is not the fire you are worried about, but landlords and some marketplaces still ask.
• Media and IP liability
  Covers content, copyright, trademark, defamation. Matters when your marketing, docs, blog, or even user-generated content gets you into a content fight. It can also be relevant if your product outputs text or images that a third party says looks a lot like theirs.
• Directors and Officers (D&O)
  This one is about leadership decisions. Investors or partners claim misrepresentation, breach of duty, bad governance. Feels far away, until money shows up or a deal goes sideways.
• Employment Practices (EPLI)
  Claims from employees or contractors about how they were treated. If you hire, this becomes real.
• Crime and social engineering
  Fraud, funds transfer tricks, someone gets your finance person to wire money to a very convincing fake vendor. Sounds silly until the email header looks perfect and the clock is ticking.
• Business interruption, sometimes “contingent”
  Lost revenue when a covered cyber event knocks you down. Sometimes it includes when your provider is the one that failed. Read the fine print. Sublimits are common. Waiting periods too. This is not a blanket “get paid when AWS sneezes.”

Two mechanics matter, even if your eyes glaze over reading policies.

• Many of these are claims-made, not occurrence. That means they respond when the claim is made, not when the event happened. The retroactive date on the policy is a line in time. If bad things happened before that line, you may be out of luck. Do not let that line be yesterday if you have been live for a year.
• Retention is the deductible you eat before the policy does anything. Low premium, high retention. You trade pain now for pain later. Pick your poison with eyes open.

You do not need every policy on day one. You do need to know which risk you are carrying with your own wallet. That gap is where founders go broke.

The quiet failures that turn loud

Three scenes. Composite, but real.

Open bucket, quiet Friday
A dev toggles a “temporary” public read so a contractor can pull logs. Temporary turns into weekend. A scraper finds the path, then a forum does. Names, emails, a few tokens. Nothing as bad as your imagination, but bad enough.
First calls are to a lawyer and a forensics firm. The wording in your public promises matters now. The speed of your response matters. If you have cyber, you are not alone in the room. If you do not, you are the incident team and the comms team and the checkbook.

Holiday checkout, stalled
A webhook backlog, a single-threaded worker, a queue that looked fine until traffic tripled. Your biggest customer’s checkout goes slow, then fails. Their CFO emails a number that does not look real. Lost sales, they say. Make us whole.
What you wrote about remedies matters here. If your contract says credits are the only remedy, the conversation is narrow. If it does not say much, every dollar of their projection feels like it is yours. Tech E&O can be a shield, but it is sized, and it reads the words you published the day you launched.

License time bomb
A citizen dev pulls a helpful repo that “just works.” The license is not compatible with how you sell your product. Months later, an email arrives asking for compliance or release of your source. You did not plan for either.
Media or IP coverage sometimes helps with defense, but the fix is cultural. Track your dependencies. Know which licenses mean you are giving something back you did not intend to.

None of these scenes are exotic. Nobody compromised a quantum chip. Ordinary misconfigurations, ordinary traffic, ordinary human shortcuts. That is the point.

Security, not vibes

You are not trying to be bulletproof. You are trying to be less porous today than yesterday.

• Fewer keys, shorter lifetimes, less privilege.
• Alerts that go to a human who actually wakes up.
• A path to put the system in read only when you must.
• A status page that tells the truth.
• One file, somewhere boring, that says who writes to customers on a bad day.

You know how to do this. You just rank it below shipping. You will not on the day you wish you had.

How contracts feel if you are only a builder

They feel like homework. They feel like someone trying to trap you with Latin. They feel like a pause when you only want a play button.

Here is a different frame.

• Think about scope. Describe what the service is, and what it is not. Clear edges reduce arguments.
• Think about where any fight will happen. Pick one place on earth, not everywhere.
• Think about how remedies work. Credits, refunds, nothing, something. Decide now.
• Think about data. Who owns it, who can access it, how you handle requests, how you notify in a breach.
• Think about promises you can keep. Anything else becomes a future email you will dread.

You are not writing this alone. That is the point. This is where professionals earn their keep. Your job is to be honest about what you can actually do, so they can put words around it that survive contact with the world.

Myths that get people hurt

“We are too small to sue.” Courts do not sort by ARR.
“We will clean it up after launch.” Seatbelts are not an aftermarket accessory.
“We are incorporated.” So is every company that has ever been in court.
“We said beta.” Beta is a label, not a shield.
“We only have ten users.” Ten people are still people.

Most bad days are quiet until they are not. Most logs look normal, right up to the timestamp that does not.

What survives the crash

Not much. But this tends to.

• A promise you can keep, written down.
• A boundary set by someone who lives in boundaries.
• A policy that buys you time and help when you cannot buy either.
• Fewer doors into your system, fewer people with keys.
• A drill you hate, done once, so muscle memory exists when adrenaline erases common sense.

Do not overcomplicate it. Do not make it a personality. Just do the grown up parts before the internet does them to you.

Why I am saying this out loud

Because I want you to keep building. I like the shift from gatekeepers to people who ship. I like that a student in a dorm room can make something that helps a city function better. I do not like watching those builders get flattened by the parts they never saw at big companies, the parts someone else used to absorb.

It is not a threat. It is a reminder. The world is larger than your repo. The moment after deploy is not magic. It is responsibility, with a diagram.

Talk to a real lawyer, the kind who speaks software. Talk to a real broker, the kind who explains without condescension. Decide your promises before your landing page does it for you. Know how you will respond when the lights flicker. Practice once.

Then ship. And breathe.
Not because you are safe. Nobody is.
Because you are honest about the risk, and ready when it says hello.