Building an agency profitability SaaS. AI features (SOW generation, data chat, PDF parsing) run on Anthropic Claude Sonnet 4.5.
My unit economics work out roughly:
— Claude call for AI SOW generation: ~$0.05-$0.10 in API costs
— Claude call for data chat query: ~$0.01-$0.03
— Average per "AI action": ~$0.04 = ~£0.03
If I charge £0.10 per credit (£1 = 10 credits), I keep ~£0.07 margin per action.
Tier structure:
— Starter £19/mo: 10 credits included (breakeven if all get used)
— Growth £49/mo: 50 credits included
— Scale £75/mo: unlimited
Why included credits, not "you pay only for what you use":
Pure usage-based feels cheap but kills product commitment. Nobody who pays £0/month is your customer — they're a demo user. Including credits with a subscription creates the anchor.
Why top-up £1 = 10 credits:
Because £1 is genuinely nothing. Nobody debates a £1 purchase. When your customer thinks "should I upgrade to Scale for £26 more or grab another £1 of credits?" — most will choose £1 several times, then upgrade when it becomes obvious.
That's the psychology. Small enough not to think about; frequent enough that the upgrade eventually looks smart.
Not building enforcement yet:
Have zero paying customers. Building AI credit tracking backend now = 5 hours on infrastructure for imaginary users. Waiting until first 5 customers actually want top-ups. Track manually until then.
Live at clobsow.com. Feedback appreciated, especially on the credit price — I might be underpricing.
The included credits architecture is right, and the psychology on top-ups is sound. The £1 top-up sitting between 'a few more credits' and 'just upgrade' is genuinely clever friction design.
On underpricing: the real risk isn't the £0.10 rate, it's whether the Starter at £19 with 10 credits creates a frustration exit rather than an upgrade. If someone pays £19, burns through 10 credits in week one, then faces 'buy more or upgrade,' that decision point is where you lose people. It's not about the credit price — it's about whether 10 credits is enough to actually hook them on the product before they hit the wall. Worth tracking that specifically once you have your first 5 customers.
This is the sharpest of the pricing comments so far. You're right that the 10p rate isn't the real risk — the paywall timing is.
Honest math on Starter — one SOW gen + a few chat questions + one PDF parse = 5-6 credits in a first session. Second session and they're at the wall. That's not "aha, this saves me hours" — that's "wait, I need to pay more already."
The obvious fixes: raise Starter to 20 credits (double), or introduce a "first 30 days = 3x credits" onboarding boost that resets after. Second one is cleaner because it doesn't inflate ongoing costs but does buy the first-month runway to prove value.
Watching this once I have real signup data. First 5 customers will tell me exactly where the wall hits them. Might turn out 10 is fine because most burn through 2-3 in the trial, not 10.
Thanks for making me think about this dimension. Everyone else was arguing the £ number, you're arguing the timing.
You are pricing off your API bill instead of what the output is worth. An SOW that saves an agency two hours of a senior person's time is worth tens of pounds to them, and charging 10p for it teaches them to value it at 10p, which is a brutal anchor to raise later. Separately, unlimited at 75 with no enforcement built is a bet you cannot see: one heavy agency running data chat all day flips that tier negative and you will not know until the Anthropic invoice lands.
Brutal and completely accurate feedback, Gregory. Selling an hour of saved senior time for 10p sets a terrible precedent, and leaving £75 uncapped is a direct path to a surprise API bill. Swapping the top tier over to clear project limits instead. Really appreciate you pushing back on this!
Yeah — landed hard, both points. The £0.10 anchor thing especially. Once you post that number, you can't un-post it.
Moving Scale to 500 credits/month with a fair-use footnote at 1,000. Not building the enforcement backend yet (zero customers), so fair-use language for now, real tracking later when someone gives me a reason to build it.
The value pricing point I'm sitting with. £0.50/credit still feels wrong (too cheap against a saved hour) but 5x jump from what I posted 6 hours ago also feels wrong. Might do it in two moves — settle at £0.50 for 30 days, then take it higher if the market doesn't push back.
Would you have done it differently — one big correction or staged?
I like the simplicity of “1 credit = 1 action.” One thing I’d watch is the cost difference between actions. If some actions consistently cost 3–5x more than others, a flat credit system could eventually squeeze margins. Would you keep the simple model and absorb that difference, or introduce weighted credits only once usage data shows it’s necessary?
Simple model, absorb the difference — for the first 20-30 customers. Weighted credits when I have real usage data showing which actions dominate.
Two reasons for keeping it simple now:
Weighted credits are impossible to explain without a pricing table. "1 SOW = 3 credits, 1 chat = 1 credit, 1 PDF parse = 2 credits" adds three sentences of complexity to every pricing conversation. That kills conversion before the pattern is even worth solving.
I don't actually know which actions will dominate. Might be 80% chat, might be 80% SOW gen. Guessing before data means baking in the wrong weights. Better to eat a bit of margin variability for 6 months than lock in weights that turn out to be backwards.
Threshold for introducing weighted credits: when a single action type consistently exceeds 60% of usage OR when Anthropic bill exceeds 40% of revenue. Neither is close to happening.
Pricing AI actions at a simple $0.10 flat rate is brilliantly intuitive for onboarding users, but pairing it with an "unlimited" top tier creates a massive hidden margin risk when power users exploit heavy API calls. While predictable pricing reduces buyer friction early on, long-term profitability usually forces a shift toward strictly usage-capped or tiered-rate models to prevent API costs from eroding revenue.
I’d be careful not to replace one untested pricing model with another just because the comments make project-based pricing sound cleaner.
You have zero paying customers, so the next decision isn’t really “10p per credit vs project limits.” It’s: what unit already matches how your buyer thinks about money?
Keep the AI-action meter internally for cost control. I wouldn’t expose it to customers unless they actually need it.
Then price around the economic unit the agency already manages. If they sell fixed-fee projects, a project allowance may feel natural. If they live on retainers, client/account limits may make more sense. If they bill hours, time saved may be the stronger anchor.
That also lets you learn pricing without spending the 5 hours building enforcement for a model you may throw away.
The one thing I’d find out before changing the tiers again: how do the agencies you’re targeting actually charge their own clients today - fixed project, monthly retainer, or hourly?
This landed hardest of any comment on the post. You're right that I was about to iterate pricing again based on comment-thread signal instead of customer signal.
Concrete answer to your question: my target agencies are UK creative and tech shops, 5-50 people. Mixed billing models — most run some combination of fixed-fee projects, monthly retainers, and T&M for overflow. Very few are pure-play any single model. Which means "match the unit they charge in" needs actual conversations to figure out which of those three anchors dominates in each buyer's head.
What I'm going to do:
Not change pricing again this week. Keep the current £19/£49/£75 with the fair-use footnote, ship as-is.
Book 5 conversations with actual UK agency owners in the next 10 days. Ask them exactly how they think about SaaS pricing — per-project, per-user, per-outcome — and what feels natural vs punitive.
Then iterate once, based on that data.
Also going to keep the AI-action meter internal for now as you suggested. Cost control tool, not a customer-facing unit until it needs to be.
This comment is genuinely worth its own IH post. Thank you.
The restraint around not building top-up infrastructure before customers need it makes sense.
Curious whether you expect buyers to think in “AI actions” at all, or whether the credit system risks making the cost feel more visible than the business outcome those actions produce.
Metered credits just create usage anxiety. If a PM hesitates to run a scope check because they’re counting credits, the pricing has failed. Agencies want protected margins, not a utility bill. Shifting to project-based tiers solves this cleanly. Many Agencies will go for unlimited only small who has limited scope of AI will go for metered billing
That’s useful context. The difference between usage anxiety for smaller users and margin predictability for agencies is worth watching as you get more customers through the pricing.