Contracting Practice

At a small company, a contract is usually something you sign rather than something you read. A thirty-page file arrives, someone checks the price and the end date, and the rest scrolls past. The reason is not laziness. Every clause carries a name, and if you don't know what each name is there to prevent, thirty pages look like one undifferentiated block. The document also stays closed for as long as the relationship works. It only gets opened on the day things go wrong, which means the cost of not reading it arrives months after the signing, never during it.

The damage doesn't only show up after an incident either. Skip the sentence saying the agreement renews for another year unless someone gives notice, and you find out about that sentence after paying twelve more months for a tool the team stopped using. The window for cancelling often closes sixty days before the renewal date, and most people learn that two weeks before it.

Pagedeck lived through the first version of this. During the week of its first enterprise deal, Sofia handed the contract to Grace and asked whether it was fine to sign, since the buyer had called it their standard form. Grace checked the price and the term and signed. Four months later a bad deploy left that customer unable to open their documents for six hours. The buyer's procurement lead quoted clause 12, which nobody had read, and clause 12 set no ceiling on damages. A customer paying about twelve million won a year could suddenly cost several times that.

Naming the scattered clauses as one body of practice is what changed. Once they have names, a contract stops being a block and starts being a table of contents. Knowing which clauses ought to be there tells you what is missing from the draft in front of you, and gives you something concrete to ask for. Regulation sets a floor that no customer can waive on your behalf. What sits above that floor is a set of sentences both sides can negotiate, and that negotiable layer is what this practice covers.

The terms under this name fall into two groups. One is the container that holds a promise (documents), the other is the individual sentences that go inside it (clauses).

Documents decide who the promise is made to and what it covers. There are two, and they split on whether you face one counterparty at a time or everyone at once.

1. Terms of service — one set of conditions applied to every person who uses the product. The absence of negotiation is what separates it from a signed contract. Agreement happens the moment someone clicks sign-up, and in exchange, changing the text requires notifying everyone already using the service. That is why raising a price or shrinking the storage on a free plan is a product decision and a terms revision at the same time.
2. Statement of work (SOW) — a document listing what gets delivered on this particular engagement and where the line stops. A separate agreement sets the rules of the relationship; this one attaches to it deal by deal. A missing line here moves real weeks around. If the document says nothing about migrating the 80,000 files sitting in the customer's old system, the customer assumes it's included and engineering absorbs two unplanned weeks.

Clauses decide what happens when the relationship breaks. There are seven, and they group into three questions: where the money goes, how the relationship ends, and where a fight gets settled.

1. Warranty — the sentence promising what condition the service will be in. The uptime percentage for a month, the number of hours before someone responds to a severe outage, and similar numbers live here. Most of the other clauses deal with what happens when this promise breaks, so whether these numbers are ones the team can actually hit is the starting point for the whole agreement.
2. Indemnification — the sentence saying that if the customer gets sued by an outside party because of something on your side, you carry that cost. The usual example is a third-party library or font used in your product, with the rights holder going after your customer. What sets this clause apart is that it deals with a fight between your customer and the outside world rather than between the two of you.
3. Limitation of liability — the ceiling on what you can be made to pay. Capping it at the fees received over the previous twelve months is a common shape. Without a ceiling, one incident at a customer paying twelve million won a year can put the whole company at risk. Sellers check this clause first, and buyers negotiate to push the ceiling up.
4. Termination clause — the conditions under which either side can end the agreement. It separates ending it for no particular reason after some months of notice from ending it because the other side broke a promise and failed to fix it within a set number of days. What happens to the customer's stored data afterward, in which format and by when, usually attaches here too.
5. Force majeure — the sentence excusing a broken promise when something neither side caused gets in the way, such as an earthquake or a war. In practice the argument is about how far the list extends. An outage at the cloud provider you rent servers from usually does not qualify, because choosing that provider was your decision.
6. Governing law — which country's law the document gets read under. The same sentence can be interpreted differently depending on that choice, so it's one line to avoid waving through in a cross-border deal. The court named alongside it changes the order of magnitude of what a dispute costs to pursue.
7. Dispute resolution — whether a disagreement goes to court or to arbitration, and whether both sides have to spend some weeks talking first. The other six clauses decide what is correct; this one decides who gets to say so.

The two groups relate as container and contents. The document sets up the relationship, and the clauses attach conditions to it. Fixing a reading order makes an unfamiliar contract go much faster: start with the three money clauses, then how it ends, then where a fight lands. The order matters because the money clauses only make sense together. The warranty says what you promised, the indemnification says which outside claims you absorb, and the ceiling says how large any of it can get. Read the ceiling on its own and the number looks arbitrary; read it after the warranty and you can see exactly which failure it is sized against.

You also won't weigh all seven every time, because the document in play shifts the load. A product people buy alone with a card runs almost entirely on one set of terms, and with nobody to negotiate against, no clause gets argued. Then one enterprise customer appears and all seven show up at once, because their procurement and legal reviewers send their own contract instead of accepting yours. That first enterprise deal is the moment the practice stops being optional, and the team that has never read a clause closely has to learn seven of them in the middle of a live negotiation with a deadline attached.

"There's no limitation of liability in this draft. Sign it as is and one outage could cost us several times what this customer pays in a year."

A missing clause, flagged along with the amount that blank space is worth.

"They call it a standard form, but their side has seen hundreds of redlines. Let's send it back with three changes."

The document that arrived is an opening position, not a final one.

"Engineering has to answer the uptime number, not legal. Let's look at what we actually hit last quarter and write something under that."

Check with the people who will keep the promise before the promise goes in.

Pagedeck ran the second enterprise deal in a different order. Sofia passed the draft to Grace the day it arrived, and Grace marked three places: the damages ceiling, the termination notice period, and the governing law. There was no ceiling at all, and only the customer could end the agreement at will. What Grace asked Theo was about a number rather than a clause — could the team hold 99.9 percent monthly uptime? Theo pulled the last two quarters and found 99.2 and 99.6.

So the redline Pagedeck sent back lowered the uptime commitment to 99.5 and added a ceiling set at the fees paid over the previous twelve months. The buyer accepted both and asked, in exchange, that outage notifications drop from four hours to two. Signing took two extra weeks, and what those two weeks settled removed most of what the two companies could have argued about over the next three years. Mia revised the free-plan terms that same week, since the decision to cut storage required thirty days' notice to everyone already using it.

The most common belief is that a standard contract can't be changed. It's called standard, it arrives in a format you can't edit, and the only blank is the signature line, so that reading is easy to arrive at. But the lawyer on the other side handles redlines every week. Standard means the version their team starts from so they don't rewrite it each time — it doesn't mean fixed. Sign without ever pushing back and those conditions harden. Renewals get drafted by copying the previous contract, so a clause you let through in year one is still sitting there in year three.

The other common belief is that contracts belong to legal. The language is unfamiliar, so handing it to someone who knows it feels safer. Yet most of what goes into the clauses is a promise some other team has to keep. Engineering carries the uptime and response times, support carries the scope of data migration, sales carries the discount and the exit terms. Numbers that go in unchecked become promises nobody knows about. The day those promises get read for the first time is usually the day they were missed, by which point the clause is no longer open to change. Spending an hour before signing to ask each team about each number tends to adjust the values on the spot, and the ones nobody can keep never make it into the document.