One of our customers, BetterPic, sells 4K AI headshots. Before they moved their pipeline to us, they were running their own GPUs, and two numbers told the whole story: gross margin sat around 40 percent, and customers who paid for headshots were waiting a full day to get them. The founder put it better than I could. That is not a cost problem; that is a product crisis.
A year later, the same product runs at 87 percent gross margin with no machine learning or DevOps headcount. Nothing about the headshots changed. What changed was the shape of the cost behind them. That shift is the thing most teams get wrong when they add an AI feature, so here is the test I wish every founder ran before building one.
The cost most teams forget to count
When a team prices an AI feature, they price the obvious part: the per-image or per-token charge from the model. The number that sinks the margin is the part they skip.
Build the capability in-house, and your cost is mostly fixed. A GPU sized for your peak-hour bills the same at 3am, with no traffic. An on-call rotation costs the same in a quiet week. Model upkeep, retries, queueing, and the migration to next quarter’s better model all cost engineering time, whether or not a single customer uses the feature. That was BetterPic at 40 percent: paying for capacity and reliability, they could not keep up, with a wait time that was costing them customers.
Call an API instead, and the cost is variable. You pay per call, so the expense tracks usage, and usage tracks revenue when the feature is priced into the product. The feature nobody uses costs almost nothing. The feature that takes off scales its cost in step with the income it brings in.
Why the shape of the cost matters more than the rate
Founders fixate on the per-unit price and overlook that the cost curve is what protects the margin.
Fixed cost is a bet that adoption will be high and steady enough to spread the infrastructure across enough uses to come out ahead. For a capability at the core of the product, with a large predictable volume, that bet can be right, and owning the GPUs can be cheaper per use. BetterPic has run more than 35 million images through us over the past two and a half years, so you might assume they should own the metal. They did the math the other way because the operational load and the reliability bar mattered more to the business than squeezing per-image costs.
Variable cost is the safer bet when adoption is uncertain, which is true for almost every new feature on day one. You learn whether customers want the thing before you commit capital to running it. If it works, you can revisit the build-versus-buy line later with real numbers. If it does not, you have lost a per-call bill for a few weeks instead of a quarter of engineering and a reserved GPU.
A simple way to model it before you commit
Three inputs tell you most of what you need:
- Cost per use. The real number at a realistic volume, not the list price and not the free-tier price.
- Attach rate. The share of active users who actually touch the feature in a month. Be pessimistic.
- Price uplift. What the feature lets you charge that you could not before, through a higher tier, better retention, or a usage line.
Multiply the cost per use by the expected number of uses and compare it to the uplift. If the uplift does not clear the cost with room to spare, the feature is a marketing expense, not a product line. Deciding that on purpose is fine. Discovering it after you have built the infrastructure is the expensive way.
The comparison step people skip
Once a feature passes the margin test, price the providers properly, because the per-call rate varies more than most teams expect, and so does what is bundled into it. Some providers bill inference time, so a five-second job costs you a minute of compute. Others bill a flat per-call rate you can multiply straight out to 10k and 100k uses with no surprise tiering. We put a side-by-side together on exactly this for image and video work, comparing Runflow against fal on cost shape and what each one includes, because the headline rate rarely tells the whole story.
The discipline, not the tool
The point is not which provider wins. The point is that BetterPic did not get to 87 percent by negotiating a better rate. They got there by changing the feature’s cost. Treat an AI feature the way you would treat any line on the P&L: a cost with a shape, an adoption assumption you can be wrong about, and a price it has to justify. Run that test first, and the build-versus-buy call answers itself in most cases. Skip it, and you find out at the end of the quarter that the impressive demo was the most expensive thing on the roadmap.
