Every roadmap has a moment where the fast, invisible fix is sitting right there, fully formed, ready to ship before lunch. We had one of those. We looked at it for a while, and then we didn’t ship it.
Here’s the situation: yoursignalstack includes an AI assistant we call Jack, and every plan comes with a set amount of Jack usage built in. Eventually, some merchant was going to use up what came with their plan before their billing period reset. We had to decide what happens next.
What happens when you use up what’s included with your plan?
There are really only two honest answers to that question. Either you cut the merchant off until the next cycle, or you let them keep going and charge them for the extra. We wanted to do the second one — nobody likes hitting a wall on a tool they’re actively relying on.
The fast version of that was easy to picture: just reset the usage counter back to zero on a timer, and let the overage math work itself out roughly. It would have taken an afternoon.
Why we didn’t ship the fast version
The problem wasn’t the idea. It was where the reset actually happened. Behind the scenes, not every merchant’s account runs through the exact same billing plumbing — different merchants, added at different points, ended up wired through more than one billing system. From the outside, that’s completely invisible. From the inside, it meant a simple reset wouldn’t behave the same way twice.
Two merchants doing the exact same thing — using up their included Jack usage on the same day — could have ended up treated differently, purely because of which billing system happened to be under their account. One might get a clean reset. Another might get charged for overage a little early, or a little late, or slightly wrong. Neither merchant would have any way to know that. They’d just quietly be on the unlucky side of a coin flip they never knew was being flipped.
That’s the part we couldn’t ship. Not because it was risky in an obvious, headline-grabbing way — it’s the opposite kind of risk. Nobody would have filed a support ticket about it, because nobody would have known to. It would have just sat there, quietly unfair, for as long as it took someone to notice a pattern across two accounts they’d have no reason to compare.
What we built instead
We built real metered overage billing: usage gets tracked precisely per account, and once a merchant goes past what’s included, they’re billed for the actual extra amount, calculated the same way regardless of which billing system sits underneath their account. It took longer. It’s also the kind of fix where success looks like nothing happening — no one notices metered billing when it’s working correctly, which was exactly the point.
Why this matters to you
Next time you’re comparing pricing pages and you see “usage-based” or “overage” pricing on any SaaS tool, it’s worth asking one extra question: how is that overage actually calculated, and is it calculated the same way for every customer?
Most of the time you’ll never be able to tell from the outside whether the answer is “precisely and consistently” or “close enough, and it varies.” That’s exactly what makes it an easy place for a tool to be quietly inconsistent without anyone catching it — there’s no error message for “you got charged slightly differently than the next customer for the same behavior.” It’s a reasonable thing to just ask, especially for any tool where your usage regularly runs close to what’s included in your plan.
We’re building yoursignalstack in public, decisions like this included, because we’d rather you see the real process than a highlight reel. If you want to follow along, leave your email and we’ll let you know when it’s live.
Leave a Reply