Save Your Rockets for the Moon

Two questions every product builder needs to answer before shipping AI — and why your unit economics live or die on the answers.

There’s a trend I see almost every day now: products promising the moon with AI. New features, new agents, new workflows. Some of it is fantastic — real augmentation of real services. Some of it is a path to a P&L meltdown that nobody has looked at yet.

Here’s the part most builders aren’t being conscious about: the profitability of the product once AI is in it.

Two questions decide whether your AI features make you money or burn it. If you can’t answer both clearly before you start coding, you’re not building a product — you’re building a subsidy.

Question 1: How much AI does your product actually need?

You can use as little or as much AI as you want, and there is no universally right answer.

On one end of the spectrum, AI lives only inside specific surfaces — a button, a panel, a workflow that the user explicitly invokes. They click here and AI augments. They click there and AI enhances. The rest of the product is deterministic, cheap, and predictable.

On the other end, AI is always running. Proactive agents, background analysis, continuous reasoning over the user’s data whether the user asked or not. The product is, in effect, a layer of intelligence wrapped around whatever the user is doing.

Neither extreme is wrong. But they have wildly different cost profiles, and that is the part most product owners skip past. Always-on AI in a low-margin SaaS is a path to losing money on every active user. Surgical, click-triggered AI in a premium product can be one of the cheapest parts of your stack.

The conscious choice — do we actually need AI in this surface, or are we putting it there because everyone else is? — has to sit at the top of both the product and the engineering minds. Otherwise the bill that lands when the product is used will not match the value the user actually got.

Question 2: Which model for which job?

This is the question early-stage teams almost never give enough weight to.

The instinct is: pick the smartest model and use it everywhere. It works on the demo, it sounds great in the pitch, the latency is fine when you have ten users. The problem is what happens at scale.

Save your rockets to go to the moon. Use your scooter to go to the grocery store.

There is no one-model-fits-all implementation that survives contact with real-world unit economics. You have to layer your models — use only the IQ level the task at hand actually requires.

In practice that looks like:

• Classification, routing, intent detection, simple extraction → a small local model or a cheap hosted one.
• Reasoning over user context, drafting, multi-step decisions → a mid-tier model.
• Genuine planning, complex synthesis, long-context reasoning → save the frontier model for these, and only these.

A well-architected agent stack might call three different models inside a single user request — a cheap one for triage, a mid one for the lift, an expensive one only when the cheap path can’t decide. Your bill drops by an order of magnitude. Your users notice nothing.

The rule of thumb: every model call is a question of what’s the minimum capability that gets this job done correctly? — not what’s the most capable model I have access to?

The unit economics nobody is doing

Once those two decisions are conscious, the next part is the one most teams have already done for hardware but haven’t done for AI: cost per user per month.

For storage, compute, bandwidth, you have it nailed. Engineers can tell you within a small margin what an active user costs you per month. For AI features, very few teams have the same number to hand.

You need it. Walk through every AI-enabled feature in the product and estimate, per active user per month:

• How often each feature gets triggered.
• Which model gets called, at what input/output token volume.
• Whether it’s self-hosted (cost = GPU/hour amortized) or cloud LLM (cost = per token).
• What the realistic cache hit rate is on repeat queries.

Add it up. That is your AI unit cost. Now put it next to the price plan you are about to publish.

If the AI cost per user per month exceeds the gross margin in the plan, you have one of three options: raise the price, reduce AI usage (back to question 1), or shift more of the work to cheaper models (back to question 2). What you cannot do — but what a lot of AI-forward startups are quietly doing right now — is hope it’ll work out at scale. It won’t. The cost grows linearly with usage; the price doesn’t.

Pricing follows from the math, not the other way around

There is a real shift happening in AI product pricing — away from allocated quotas (“you get 100 AI credits a month”) and toward consumed-value plans (“you pay for what you actually used, or for the outcome we delivered”).

Quota plans were the safe default in the early days because they gave the vendor predictable upper bounds. Value-based plans are harder to design but more honest, and customers increasingly expect them — they don’t want to pay for capacity they didn’t use.

The shift only works if your unit economics are solid. If you don’t know what an AI feature costs you per call, you cannot price it confidently per call. If you don’t know the cost-to-value ratio of your different model tiers, you cannot meter outcomes without losing money on the long-tail queries.

Get the fundamentals right first — surgical-or-proactive AI, tiered models, cost per user per month — and the pricing model that fits your product becomes a math problem, not a bet.

The takeaway

AI is the most exciting layer to build on in a generation. It is also the easiest place to bake a structural unit-economics problem into your product before you have even shipped.

Two conscious decisions, made early:

1. How much AI does this product actually need, and where?
2. Which model is the minimum sufficient for each job?

Get those right, do the math on cost per user per month, and your pricing strategy stops being guesswork.

Save your rockets for the moon. Take the scooter to the grocery store.