The Renewal Card

Watch the two-minute walkthrough 2:13

A two-minute walkthrough: why renewals get decided on habit or hype, the fields, the ground check, the verdict, and how to run the prompt in any model.

Play video

The decision it forces

Re-sign, renegotiate, or build the replacement? Sam's opening question on Episode 11 is the card in one sentence: when the software renewal comes up, how do we know which?

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 last three are the ground check, under substrate in the schema. The seat gap is the show's field, not the episode's: it's on the card because it's the first number a vendor will argue with.

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's no worked example beyond Ankit's own, sketched above: a filled card names our vendor, our invoice and the person who would run the replacement.

The verdict rule

The ground check comes first. If any of its three answers is no, 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. When all three are yes, the choice between re-sign, renegotiate and replace is ours, made from what we actually use the tool for and what the candidates cover. The third leg, someone who can operate it on Monday, is the show's addition to Ankit's two, from his own hedge that he was willing to take the risk if something broke and not everyone is.

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/#the-answer-format. If you can't read
that page, use these keys, in this order: schema, tool, annual_cost,
renewal_date, seats_bought, seats_used; what_you_actually_use_it_for, a list;
candidates, a list, each with name, covers (a list) and hosting; substrate, with
hosting_you_control, keys_and_tokens_managed, someone_who_can_operate_it and
ready; verdict. 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"
}