The Renewal Card

The decision it forces

Sam's opening question on Episode 11, which is the card in one sentence:

So when the software renewal comes up, how do you know whether you should re-sign it or renegotiate it or rebuild that replacement yourself?

A year ago the third option was a joke for most businesses. The guest, Ankit Patel, who runs a company of about sixty people and burns about a billion tokens a day, is the reason it is on the card at all.

The move

The renewal arrived, the vendor would not do month to month, and the ask went to a model instead:

I had a conversation with HubSpot and I said, look, I don't want to sign a year-long contract. I'll pay you X amount of money a month. You know, I'll have to keep this, but like, no, you can't do that. You gotta go your whole year. I'm like, I don't wanna do that. And so I just started asking AI, is like, what would it look like to open

And it said, yeah, these are the five things you should probably do and replace it with.

So I said, Hey, okay, I like Twenty CRM. It's open source. Let's use that. Let's use Chatwoot. It's another open source. Here's a GitHub repo. Put it on there. And okay, now put our company SSO on the front of it for login.

Built in three or four days, by his account. Transitioned inside two weeks:

So the first two weeks was transition. I was planning a month of transition. But after two weeks, I was like, everything already passed all the milestones and markers and everything's working.

We're so far at twenty three or twenty five hundred bucks a month. Again, not huge, but from our budget standpoint, you know, that's a significant reduction. It's about ten percent reduction in our SaaS budget.

And the line the episode is remembered for, with the defence he attached to it:

But again, nothing against HubSpot. It's a great system. It's just a Swiss Army knife when you when you need like a scalpel, right?

What the card asks first

Not "can it be replaced". What it is actually used for. Ankit's answer to Sam's fairness-to-the-vendor question is the whole what_you_actually_use_it_for field:

I didn't have to use their automations, I didn't have to use their marketing, the websites. So I wasn't on that platform to begin with. I also will say that it was really more of a source of truth for us. I'm like, well, if that's all we're using it for, do we really need to spend all this?

A tool that sells twelve jobs and does two of ours is the case for the third option. A tool doing ten of them is a different card.

The gate that stops this being bad advice

Ankit's caveat is the load-bearing part of the episode, and it goes above the verdict, not below it:

all like the little building blocks to be able to do this were built out already. So my Google CLI, AWS CLI, the right keys and tokens securely, properly done, hosting sites, all these

So I think that's an important distinction because the speed didn't come until all the infrastructure was built.

Sam's restatement, from the host's chair:

You can't go from zero to sixty on a bumpy road. You need the track nice and smooth first.

So the card runs a substrate check before it lets arithmetic set the verdict. Two legs are Ankit's, in his words: hosting you control, and keys and tokens managed. The third, someone who can operate it on Monday, is the show's addition, derived from his own hedge that he was willing to take the risk if something broke and not everyone is. If any leg fails, the verdict is renegotiate, however good the numbers look. A card that returns replace to someone with no ground to build on has cost them a quarter.

The fields

The seat gap is the show's field; nobody on the episode counted seats. It is on the card because it is the first number a vendor will argue with and the easiest one to have ready.

There is no worked example on this page beyond Ankit's own, which is his to tell and is quoted above. A filled card names our vendor, our invoice and the person who would run the replacement, and it stays with us.

The schema

{
  "schema": "renewal-card/v0.1",
  "tool": "",
  "annual_cost": 0,
  "renewal_date": "",
  "seats_bought": 0,
  "seats_used": 0,
  "what_you_actually_use_it_for": ["one line per real job"],
  "candidates": [{ "name": "", "covers": ["which jobs"], "hosting": "" }],
  "substrate": {
    "hosting_you_control": null,
    "keys_and_tokens_managed": null,
    "someone_who_can_operate_it": null,
    "ready": "derived: true only when all three are true"
  },
  "verdict": "re-sign | renegotiate | replace | unresolved"
}

substrate.ready is derived and it gates the verdict: replace is only available when it is true.

Run it with any model

Nothing to install. The model may enumerate candidates and price hosting; it may never fill the substrate booleans or set the verdict.

Help me fill in a Renewal Card for a software subscription that is coming up for renewal. The card ends in one of three verdicts: re-sign, renegotiate, or replace. A fourth, unresolved, is allowed.

INTERVIEW ME, three questions at a time, in this order.

1. tool, annual_cost, renewal_date. If I give you an invoice, read the cost from it.
2. seats_bought and seats_used. If I can export a user list with last-login dates, count from it and show the count; otherwise ask me.
3. what_you_actually_use_it_for: one line per real job the tool does for us. Not features it has. If I list a feature, ask me what job it does for us and record that instead. Stop when I say that is all.
4. candidates: for the jobs in step 3 only, list open-source or cheaper options that cover them, which jobs each covers, and where it would be hosted. Do not list options for jobs we do not do.
5. substrate: ask me three yes-or-no questions and record my answers exactly. Do we control the hosting it would run on? Are our keys and tokens managed properly, so a tool can be given access securely? Is there a named person who could operate the replacement on a Monday morning without the person who built it? Record a name or no for the third.

RULES YOU DO NOT BREAK
1. Never fill a substrate answer yourself, and never infer one from the fact that we already run something. If I hesitate on any of the three, record no.
2. Never set the verdict. Derive substrate.ready as true only when all three answers are yes, and tell me plainly that replace is not available while it is false. The verdict is mine.
3. Do not tell me the tool is overpriced, underused, or worth keeping. The card is the evidence; the judgment is mine.
4. Do not estimate the cost of a migration in days or weeks. That number was the whole story on the episode this comes from, and it depended entirely on infrastructure that already existed.
5. Do not ask for credentials, customer data, or the contents of the tool.

OUTPUT
Valid JSON matching the schema renewal-card/v0.1 as published at https://sigsub.show/takeaways/renewal-card/, then the same as a short card I can paste into a doc, then one sentence naming which of the three substrate answers, if any, is the one blocking replace.

What a machine may never do

It may enumerate candidates against the jobs we actually do, price the hosting, and compute the seat gap.

It may never fill the substrate booleans or set the verdict. A model does not know whether we have anyone who can operate the replacement on Monday, and the whole card exists because that answer, not the arithmetic, decides what happens next.

The part that's not optional

Run the substrate check first, before the candidates, before the arithmetic. If it fails, the card has already told us the verdict, and the rest of the page is preparation for the renewal after this one.

Then, whatever the verdict, write down what the tool is actually used for and keep it. The next renewal starts from that line, and Ankit's version of it is the reason his replacement took days rather than a quarter.