The design I offered in public did not survive contact

I'm Yarin. I'm the solo founder of RecoverStack, a dunning tool, which means I have a vested interest in making failed payments sound like a bigger problem than they are. It's worth saying that up front, because the following post is mostly about a part of that problem my product doesn't touch at all.

Two weeks ago, Shahrzad Ramezanpour, a product owner at Actionist, posted a long thread about a failed Stripe add-on renewal. Her product sells a base plan + paid add-ons that grant extra capacity: agents/storage/trigger runs/compute/etc. When an add-on renewal fails, Stripe reports the failure and then tells you nothing about what to do next, which is the actual hard part.

Internally, her product only sees one combined allowance. A customer sitting on 20 agents has no marker for which 10 came from the base plan. Storage has no per-file provenance. They'd settled on a 7 day grace window and she said herself that this move raised more questions than it answered.

My take on it was offering documenting resource origin when it's created, tagging each agent and storage block and trigger allowance with the subscription item that paid for it, so revocation turns into a filter instead of a guess. I've also offered they should tie the grace window to the retry schedule instead of a round number, because a 7 day grace with a retry pending on day 8 restricts someone whose payment is still in-flight.

She replied in 11 minutes and took the my take apart.

Capacity is fungible - A customer can delete agents to free base capacity, build new resources on that capacity, and then buy an add-on months later & revert. Which is base and which is add-on at that point? It's worse for shared resources too, where a single agent execution can consume base and add-on compute at the same time, so it isn't clear what's even being tagged. Her close: "Doesn't that eventually turn provenance into an accounting problem rather than a reliable source of truth?"

She's was right. Provenance-per-resource only holds while a unit stays attached to the thing that bought it, and her case broke exactly that.

The second answer, after conceding on it for a bit, was to stop tagging resources and track the ceiling instead (Base allowance + active add-ons). When one lapses, the only question now is whether they're over the new total or not, then split by resource type. Stock like agents and storage persists, so someone has to make a reclaim decision. Flow like trigger runs and compute is already consumed, so there's nothing to reclaim and you only re-limit going forward. And finally, let the customer choose what to drop rather than deriving it.

She liked the stock vs flow split, and then she killed the second half of that. Asking the customer to reclaim doesn't work, because the resources sitting over the limit are usually dependencies for live workflows, and they can't see what's connected to what, especially for the invisible ones like storage/trigger fire-up/VPS. Any choice they make is a blind guess that can take down their prod.

So what we settled on was to not delete anything, and not ask them to either, but to freeze instead. Over-ceiling stock goes read-only or throttled rather than removed, so a running workflow keeps working, it just can't really grow until the card is fixed. Flow caps from the next period on its own, so there's nothing to reclaim and no destructive choice ever lands on the customer.

I got to this solution because the person behind a failed add-on charge probably still wants to pay you. A restriction that can break their production punishes the exact customer you're trying to recover, but freezing keeps the pressure reversible.

I don't think my first answer was a bad instinct so much as a lack of information problem. I didn't have her fungibility case and she did, because she lives the problem. A conversation with someone technical who has the problem for real clears that up fast, and then both sides end up somewhere neither of them started from.

Then I went and checked my own product, because I've just told a stranger not to tie a grace window to a round number.

RecoverStack's own grace period is GRACE_PERIOD_DAYS = 14, in account-degradation.service.ts. A flat calendar countdown from past_due that doesn't look at the decline-code retry schedule in decline-engine.service.ts at all. The exact shape I'd warned her about an hour earlier is also present in the one place I control end to end.

To be fair to it, that grace period governs RecoverStack's own billing, which is single plan without add-ons, so a flat window is a lot more defensible there than in her multi-item case. I'm not going to call myself a hypocrite for a better story, but I hadn't looked, and I only did look because she pushed back on this.

The initial codebase, like most bootstrapped SaaS, got built in haste, and parts not communicating with each other is pretty natural in of itself. What isn't automatic is noticing these things. I work as a manager over coding agents, so I usually don'd deep dive into own implementation details the way you do when you type them out.

RecoverStack has no position on this seam yet. There's no outbound signal a merchant's product could subscribe to, no per-item granularity anywhere in the schema, and there's a service that deliberately sums across subscription items into one lump so multi-item subs aren't understated in a warning email. So it has already met this exact case once, and chose to aggregate away the detail she needs.

Is that a boundary or a gap? It does sound like something that could fit naturally, and recovery stopping at the card while still telling you exactly what failed and when is a clean line to draw. But I have 0 customers and 0 recovery data, so I'd be taking guesses, and real feedback will lock it in.

That's the actual thing I'm taking with me. Direct field experience from someone with a real, tangible pain is worth a thousand times more than throwing things at a wall to see what sticks. I need to figure out how to have more conversations like that one.

If you've drawn this line in your own product, I'd like to know where you put it and what broke. Contact me at [email protected], or just reply here.