The contract that auto-renewed at a worse rate

The contract didn’t lapse. Nobody forgot to cancel. The renewal fired exactly on schedule, exactly as written, and on the morning it fired, the price was higher than the one you signed. Not by a mistake. By a clause. Buried in paragraph eleven was a line that said: on renewal, the rate increases by a fixed percentage, every year, automatically, unless you object in writing thirty days before a date you weren’t tracking.

You did everything right. You still paid more. That is the failure nobody designs for, because everyone is watching the wrong thing.

The danger was never the cancel that failed. It was the clause that quietly re-priced against you. This post is about why date-watching misses it, and what it takes to catch the increase the moment it’s scheduled instead of the month after it lands.

Everyone watches the date. The date was never the threat.

Ask anyone how they keep contracts under control and you’ll hear the same answer. They put the renewal date on a calendar. Thirty days out, a reminder fires. They decide: renew or cancel. Tidy.

That model has a hidden assumption, and the assumption is wrong. It assumes the only two outcomes that matter are keep and kill, that a contract is a light switch, on or off, and your job is to flip it in time. So the whole apparatus points at the date. Did it renew? Did the cancel take? Is it still running?

But there’s a third outcome the switch model can’t see, and it’s the expensive one: the contract renews, and renews worse. Same vendor, same service, same logo on the invoice, a different rate. The light is still on. It just costs more to keep on. A date-watcher checks whether the thing happened. It never checks what the thing now costs.

The bottleneck never disappears. It just moves to the clause nobody read.

So the date arrives, the renewal goes through, the reminder marks itself done, renewed, all good, and the increase rides in underneath, invisible, because the only question anyone asked was whether the contract survived, not what it became.

The naive watch: a date and a yes/no

Let’s show the dumb version first, because most teams are living in it and don’t know it’s the dumb version.

You build a renewal tracker. It’s a spreadsheet, or a calendar, or a field in a tool. Each row is a contract and a date. Thirty days out, something pings you. You glance, you nod, you move on. The system did its one job: it remembered the date so you didn’t have to.

Here’s where it fails, and the failure is quiet by design. The ping says Acme contract renews in 30 days. It does not say Acme contract renews in 30 days, and the rate goes up because clause eleven escalates it. The tracker holds the date. It does not hold the terms. It was never reading the document, it was reading a field someone typed once, at signing, and never touched again.

So you get the reminder, you confirm the renewal, and you feel covered. You are not covered. You’re informed about the one fact that wasn’t the danger and silent about the one that was. The increase isn’t hidden in some adversarial sense, it’s right there in the contract you signed. It’s hidden the way a thing is hidden when nothing is looking at it: in plain sight, in paragraph eleven, on a page no human reopens between the day they sign and the day they’re surprised.

A reminder that watches the date and not the terms isn’t a safeguard. It’s a confirmation that the trap sprung on schedule.

Reading the document, not the field

So what’s the version that works? The key idea is simple: stop watching the date and start watching the terms.

That sounds like a small change. It isn’t. It moves the whole job from “remember a date” to “understand a contract”, and understanding a contract means actually reading it, the way the person who wrote clause eleven assumed nobody would.

Here’s the shape of it. When a contract enters the company, the document itself gets read, not a summary someone pastes into a field, but the real terms. The renewal mechanics come out: when it renews, whether it auto-renews, the notice window you’d need to opt out, and the part that matters most, the price behavior on renewal. Is the rate fixed? Does it escalate by a set percentage? Does it reset to “current list price,” whatever that turns out to be on the day? Those aren’t dates. They’re terms, and they live in sentences, not in cells.

Now the watch has something real to compare. The renewal isn’t just an event that’s coming, it’s a number you can compute ahead of time. The system knows the rate you signed. It can read what the rate becomes on renewal. The moment those two diverge, there’s something to say, and time to say it.

Naive: your contract renews in 30 days. Better: your contract renews in 30 days, the rate increases under the escalator clause, and the window to object closes in eleven, here’s the clause, here’s the old rate, here’s the new one.

The first is a calendar entry. The second is a decision you can actually make, with the one fact that changes the decision sitting right next to it.

The watch that fires on terms, not on time

Reading the contract once isn’t the whole answer either. A one-time read catches the escalator you signed. It doesn’t catch the escalator that changes, the renewal where the vendor’s “current list price” moved, the auto-renewal whose terms shifted in a notice you skimmed, the increase that wasn’t in the original document because the original document said “subject to then-current rates.”

The naive read happens at signing and never again. That’s the same trap as the date field, one level up: a fact captured once and trusted forever, while the world underneath it moves. The terms you read in March are not guaranteed to be the terms that bill in November.

So the watch has to be standing, not one-shot. It re-reads. When a renewal approaches, it doesn’t trust the rate it cached at signing, it goes back to the source, to the contract and whatever the vendor has since published, and re-derives the number that’s actually about to post. Then it compares: signed rate against about-to-bill rate. If they match, silence, and silence here is honest, because the system checked and there was nothing to flag. If they diverge, it speaks: before the bill, while the objection window is open, with the clause quoted so you can see exactly where the increase lives.

That’s the difference between a reminder and a guard. A reminder fires on a date you set. A guard fires on a condition you’d care about, and “the rate went up” is a condition, not a date. It can happen on the renewal you expected and the one you forgot equally well, because the guard isn’t watching your calendar. It’s watching the contract.

Why this lives in the company brain, not in another tool

You could imagine building a dedicated contract-watcher app. Lots of people have. And it would help, and it would also re-create the exact problem it set out to solve, because a standalone watcher is one more box you have to remember to fill in.

Think about where a renewal increase actually hurts. It’s not a contracts problem in isolation. The vendor whose rate just jumped is the one your operations team depends on, the line item your finance close has to reconcile, the relationship someone owns. The escalator clause matters because it touches the budget, the renewal decision, the question of whether this vendor is still worth it at the new price. None of that lives in a contracts app. It lives across the whole company.

A separate tool watches contracts in a vacuum. It can tell you the rate went up. It can’t tell you that you’re already mid-negotiation with that vendor on something else, or that finance flagged this line item last quarter, or that the renewal lands the same week as three others and the increases stack. The increase is a fact; the response depends on everything around it. And everything around it is exactly what a single-purpose app doesn’t have.

This is the case for the watch living where the rest of the company’s reality lives, in one brain that already holds the contract, the vendor relationship, the budget, and the calendar, so when the rate moves it doesn’t just fire an alert into a silo. It composes the alert with the context: here’s the increase, here’s the vendor you also have a deal open with, here’s the budget line it lands on, here’s the window. The increase stops being an isolated ping and becomes a decision with its surroundings attached.

The danger was never the cancel that failed. It was the clause that quietly re-priced against you. And catching it isn’t about a better calendar, it’s about a system that reads the terms, holds the context, and speaks before the bill, not after.

The turn: the quiet leak is the one that compounds

Here’s the part that isn’t about contracts.

A renewal that re-priced against you and went through anyway is a small loss the first time. The trouble is it doesn’t stay one. The escalator that bumped the rate this year bumps it again next year, off the higher base. The vendor learned, in the most literal sense, that nobody objected, so the clause that worked once gets written into the next contract too. The single quiet increase you didn’t catch isn’t a one-time cost. It’s a slope, and you’re now standing on it, paying the compounding interest on a sentence you skimmed.

That’s the real reason this matters, and it’s not a contracts reason. It’s the same reason every quiet leak matters more than every loud one. The loud failure, the cancel that bounced, the outage, the missed deadline, announces itself, and you fix it, and it’s over. The quiet one doesn’t announce anything. It just rides along, year over year, taking a little more, precisely because the only system watching it was checking whether the contract still existed, not what it had quietly become.

Nobody should have to read paragraph eleven of every contract, every renewal, forever. That’s not diligence, it’s a tax on attention that the most careful person in the company pays and still loses, because no human reliably re-reads a document they signed a year ago to catch a number that moved by a sentence.

---

That’s what we’re building toward at Apollo Space, not another tracker that watches the date and calls the increase someone else’s problem, but a company brain that reads the terms, holds the context, and speaks before the rate posts instead of after. If you’ve ever found a price increase on an invoice and thought I would have caught that if I’d known to look, the point is that you shouldn’t have had to look. Something should have been reading the clause for you all along.