Analyze the pricing model of an AI product and what it reveals about its cost structure.

Cindermark generates product photos from a text prompt, charged at one flat rate per image no matter what's in it. Tobias Klerk leads marketing for a mid-size textile company and uses it to generate everything from single-swatch thumbnails to full multi-model catalog scenes.

How to answer this, stage by stage

Nobody's grading whether your cent figures are exact. They're grading whether you can show the arithmetic and name what it reveals.

Let's learn

The Cindermark laptop dashboard shows one number for every image generated: 8 cents, no matter what's inside it.

Cindermark is an AI image generator. Type a prompt, get a product photo back, and every single one is billed at the same flat rate.

For simple images, single garment, plain background, modest resolution, the flat price works out great for Cindermark. The real compute cost is a fraction of what's charged.

At its worst: a customer generating a large batch of complex, multi-model catalog scenes for a big seasonal campaign is, without anyone intending it, one of Cindermark's least profitable customers, even while paying the same rate as everyone else.

What I would leave alone: simple, low-res single-garment images are genuinely profitable at 8 cents, with a real margin of around 6 cents each. There's no reason to touch pricing for that segment; it isn't the part that's broken.

The lesson: a pricing model isn't just a number on a page. It's a bet about which use cases the company wants more of, and Cindermark's flat rate is quietly betting against the complex scenes its own customers actually want most.

Now here is the same thing as a story

The short version above is what you'd say defending this estimate to a pricing team. Read this one for how Tobias actually noticed the pattern.

Tobias Klerk's laptop sits open most afternoons to Cindermark's generation dashboard, tracking exactly how many images his team burns through each week for the textile company's catalog.

Five steps behind every single image. Only one of them, compute, actually swings by complexity, and it's the one the flat price never asks about.

For months, his team mostly generated single-swatch thumbnails, quick previews of a new fabric color. At 8 cents each, batch-generating fifty of them cost four dollars and felt cheap.

Same sticker price. One of these two takes fifteen times longer to actually compute.

Then came a full seasonal catalog shoot: four models, several garments each, high resolution, styled scenes. Tobias generated dozens of these at the same flat 8 cents, assuming the pricing scaled with what the image actually needed. It didn't.

The pricing decision was made at the first milestone. Nothing about it changed at any of the next three, even as the cost picture shifted underneath it.

He never saw a bill that reflected the difference, because there wasn't one. But he did notice, over a few months, that his own team had started quietly rationing the big catalog scenes, running them only for the highest-priority products, while burning through swatch previews freely for anything and everything.

The most valuable images to Tobias's team, the full catalog scenes, sit in the exact corner where Cindermark loses money on every one.

Cindermark's engineers hadn't hidden anything. Somebody, at launch, decided a single flat rate was simpler to explain and to bill than a tiered, complexity-based price, and at the time nearly every generated image really did cost about the same to produce.

I would take that decision back the moment usage data showed scene complexity had become the real driver of cost, not just resolution or file size. A tiered price, even a simple three-tier one, would let Tobias's team generate the catalog scenes they actually need without quietly training themselves to avoid the tool's most valuable use.

We priced flat because it was the simplest thing to explain in a launch announcement, and every early tester happened to generate roughly the same kind of image. It took watching real customers ration their most valuable use case, without ever filing a single complaint about price, to see that "simple to explain" and "reflects reality" aren't the same thing.

BOUND, the eight cents broken openNot a guess dressed up in a confident tone. BOUND is what forces every cent to say where it came from.

The recap, one line per letter: break it down is the four-part cost equation, own numbers is the 2-cent and 30-cent figures for each extreme, use a range is the fifteen-fold spread against a flat price, nail the sanity check is the espresso-and-mocha comparison, and direction is scene complexity as the biggest lever.

And if you want to be sure it really works, try it somewhere elseSame five letters, a factory's predictive-maintenance tool instead of a fashion catalog. This time the flat fee hides a very different kind of variance.

Alloycast sells an AI tool that reads sensor data from factory machines and flags likely equipment failures, charged at one flat monthly fee per machine, regardless of how many sensors that machine actually has or how often it gets checked.

Mapped onto BOUND: break it down is cost per machine equals sensor-read cost times number of sensors, plus model inference cost times check frequency, plus alert-generation cost. Own numbers: a simple machine with two sensors checked hourly costs Alloycast about four dollars a month to monitor; a complex machine with twenty sensors checked every five minutes costs closer to sixty dollars a month. Use a range: real cost per machine spans four dollars to sixty dollars, a fifteen-fold spread again, against one flat forty-dollar fee. Nail the sanity check: that flat fee is profitable on simple machines and a clear loss on the most heavily monitored ones, the machines a factory cares about watching most closely. Direction: check frequency, not sensor count, swings the estimate hardest, since it directly multiplies how often the model has to run.

The same shape of problem, a fashion catalog swapped for a factory floor: one flat number standing in for a cost that actually swings by a factor of fifteen.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "the flat price is subsidized by simple cases and loses money on complex ones, and scene complexity is the biggest driver" and stop.
Cost: no time to rebuild pricing tiers this quarter. Say so, and start by simply showing customers an estimated compute cost next to each generation, so at least the gap becomes visible before it becomes a pricing project.
The model gets better, for real: even if compute costs fall 30 percent across the board, the fifteen-fold gap between simple and complex images barely narrows, because it's driven by relative complexity, not the absolute price of compute.

Where people run it wrong.
They treat a single sticker price as proof the underlying cost is also flat.
They blame customers for "abusing" the cheap tier, when the pricing model itself created the incentive to ration the expensive one.
They assume resolution alone drives cost, missing that scene complexity, how many things the model has to generate correctly at once, swings it far more.

How to use it live. When asked to analyze a pricing model, ask yourself one question before anything else: what's the cheapest possible use of this product, and what's the most expensive, and does the price actually move between them? If it doesn't, you've found the story.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0