Your launch credits are not your budget

Everybody has seen the credit card with the zero-percent introductory rate. The real rate is printed right there on the offer, and nobody reads it, because for the first year the number that matters is zero. Then the intro period ends and the balance starts behaving like the real thing.

Usage-priced tools work the same way, and they’re a lot quieter about it. You sign up, the vendor drops a generous launch allowance into the account, and everything you build runs on that cushion. The monthly refill, the number you’ll actually live on, is sitting in the pricing page. Nobody does the arithmetic against it, because in the first month the answer looks like zero.

We missed this on a small build recently. The miss was cheap, the catch was good, and the whole thing is a clean autopsy of how a budget can be broken on the day you launch without anyone noticing until the cushion runs out.

TL;DR

A small client had two event-listing microsites that refreshed automatically through a metered data-enrichment API. The launch allowance was roughly six to seven times the monthly refill, so everything looked fine. Once it ran out, the refresh schedule we’d picked at build time was burning about six times the refill. Our build team caught it, brought the numbers, and fixed it by matching refresh frequency to budget: once a day instead of twice, one paid tier up, a low double-digit monthly change that kept the client inside the budget they’d already agreed. The fix wasn’t a negotiation with the vendor. It was putting the refresh rate and the budget on the same page, which is something we should have done before launch.

What we built

The client is small. Two regional event-listing microsites, the kind of thing where the value is that the listings are current. Nobody wants to show up to an event that got cancelled.

So the listings refresh automatically. Each refresh pulls the listings through a metered API that enriches them, and each refresh makes several calls per site. The sites refreshed twice a day. That schedule was a product decision made at build time, and it was a reasonable one. Fresher listings are better listings.

At launch the vendor granted a one-time allowance roughly six to seven times the size of the monthly refill. The sites went live, the refreshes ran, the listings stayed current, and nothing looked wrong. Nothing was wrong yet. We were spending the cushion.

The arithmetic nobody ran

Here’s the whole mechanism in three lines.

At two refreshes a day, usage came to about six times the monthly refill. Even at one refresh a day, it came to about three times. And a launch allowance of six to seven times the refill, burned at six times the refill, lasts about a month.

That’s it. Cost per refresh, times refreshes per day, times sites, times days in the month, set next to the refill. Anyone on the project could have done it on a napkin before launch. The inputs were all known: the call count per refresh, the schedule, the number of sites, the tier. What wasn’t known was the answer, because nobody multiplied it out.

The part I keep coming back to is the second line. Even the conservative schedule was three times over the refill. There was no refresh rate on the free refill that would have kept these sites current. The build was structurally over budget from the day it launched, and the launch allowance was the only reason it didn’t look that way.

Where we went wrong

We built and launched on the introductory allowance with no steady-state number. That’s the miss, and it’s ours.

It’s worth being specific about why it happened, because it wasn’t carelessness. The refresh schedule was chosen as a product decision: how current do these listings need to be? That’s the right question to ask, and it got a sensible answer. What didn’t happen was the second question, the one that turns a product decision into a budget line: what does that answer cost per month once the launch credits are gone?

The two questions got asked by the same people, in the same build, and only one of them got asked out loud. The launch allowance made the second one feel unnecessary. When the meter reads zero there’s nothing to model.

So the cost of a schedule chosen at build time only showed up after the cushion ran out. That’s the pattern, and I don’t think it’s rare. It happens across thousands of small metered builds, most of them without anyone on the project who’d think to look.

The standup

Our offshore build team spotted it. They didn’t just flag that usage looked high. They worked out the numbers, took screenshots of the usage and the billing, and brought the whole thing to the engagement lead.

The part I want to dwell on happened in our internal standup, and it’s the reason I’m writing this at all.

The delivery lead retold what he’d said to the build team when they brought it to him: “I love hearing bad news. I’m glad you told me. Now we know.”

That’s the beat. He rewarded the people who found the problem, and he did it first. The people who surfaced an overrun got thanked first and questioned second, and I think that order matters more than almost anything else in how a team handles cost.

Here’s why. An overrun that nobody wants to report doesn’t stay small. It sits in a dashboard until the invoice arrives, and then it’s a client conversation about why you didn’t say something sooner. The build team could have waited for someone else to notice. They could have quietly dropped the refresh rate and hoped. They did neither, and the first thing they heard back was that bad news was welcome. That’s how you get the next one early too.

The other moment from that standup was smaller. The engagement lead said he hadn’t read the thread yet. He’d seen it on his drive in. The delivery lead walked him through it right there, and he was careful about how he framed it: “not to supervise your work.” He meant it as a walkthrough, and that’s how it landed. Nobody left the standup feeling like the cost problem had become a people problem.

The fix wasn’t a vendor call

The obvious move when a metered tool runs hot is to call the vendor. Ask for more credits, ask for a startup discount, ask them to extend the launch allowance. Anyone who’s run procurement has done it and gotten somewhere with it, and I expect a procurement lead reading this would push back hard on me skipping that step.

I’d still skip it. Negotiating with the vendor treats this as a price problem, and it was a frequency problem. The refresh rate and the budget had never been put side by side, and no discount would have closed a gap of six times the refill. Even if the vendor had given us another cushion, we’d have been having the same conversation a month later.

The build team didn’t recommend dropping the feature either. They matched frequency to budget:

• Cut the refresh to once a day. That halves usage.
• Move up one paid tier to cover what’s left.

The cost change was small, a low double-digit monthly figure, and it kept the client inside the budget they had already agreed. Nobody had to give up the feature.

Then they told the client where the boundary was. The way the delivery lead summed it up in standup, it’s one line with three options. This keeps you inside budget and fresh once a day. Anything fresher, you bring more money. Or freeze the refresh and save the money.

I like that offer a lot. It doesn’t pretend the tradeoff isn’t there. It hands the client the dial and tells them exactly what each setting costs, which is the conversation that should have happened at build time.

Freshness is a budget line

The general lesson here is bigger than one small build. On a usage-priced tool, a product decision is a spend decision. How fresh, how often, how many calls, how many sites… every one of those is a multiplier on the bill. When the product conversation and the budget conversation happen in different rooms, or in the same room at different times, the product conversation wins by default and the budget finds out later.

That’s the same blind spot I wrote about in technology as your largest unwatched expense, at a much smaller scale. Nobody reviews the line item because nobody can see the line item. Here the line item existed. It just wasn’t going to show up until a month after launch, and by then the schedule that caused it looked like part of the product.

It’s also a cousin of the vendor contract you can’t measure. There, the real cost hides in workarounds nobody adds up. Here, it hides behind an allowance nobody subtracts from. Different camouflage, same result. The invoice you’re looking at isn’t the invoice you’re going to get.

The question nobody asked

“What does this cost per month once the launch credits are gone, at the refresh rate we picked?”

It doesn’t get asked because in the first month the answer looks like zero. That’s the whole trap. It’s a one-line question, the arithmetic fits on a napkin, and it’s the only question that tells you whether the build you’re about to launch fits the budget you agreed.

Ask it before launch, on anything metered. Put the schedule, the call count, and the refill on one page and multiply. If the answer is over, you have options while they’re still cheap: slow the schedule, move up a tier, or tell the client what fresher costs before they’ve gotten used to it.

And when somebody on your team runs that arithmetic after launch and brings you a number you don’t like, thank them first. You can ask how it got missed later.