The Renewal Card

The decision it forces

Sam's opening question on Episode 11 is the card in one sentence: when the software renewal comes up, how do we know whether to re-sign it, renegotiate it, or rebuild the replacement ourselves?

A year ago the third option was a joke for most businesses. The guest, Ankit Patel, who runs a company of about sixty people, is the reason it is on the card at all. The renewal arrived, the vendor would not do month to month, and he asked a model what going open source would look like. He picked two open-source tools, put them behind the company's SSO, and had it built in days, with a saving of about ten percent of the SaaS budget by his figure. His defence of the vendor he left:

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?

The card asks what the tool is actually used for before it asks what could replace it, and whether we have the ground to build on before it lets arithmetic set the verdict.

To run it, copy the prompt below into any model you already use.

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. The little building blocks were already built out, in his words: the cloud CLIs, the right keys and tokens done securely and properly, hosting. Then the distinction he insisted on:

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 was that you can't go from zero to sixty on a bumpy road; the track has to be smooth first.

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.

what_you_actually_use_it_for is the field to do first. Ankit's answer to Sam's fairness-to-the-vendor question is the whole field: he wasn't using the automations, the marketing or the websites, so he was never really on the platform. 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.

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

The verdict rule

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.

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 to check in the answer

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.

{
  "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"
}