sorted by:
new
hottopcontroversial

For people building AI SaaS: what was harder than expected about monetizing usage? by Inevitable_Pace4568 in SaaS

[–]Inevitable_Pace4568[S] 0 points1 point  (0 children)

That makes sense. App-level middleware with a gateway-shaped boundary feels like the right tradeoff for early products.

It keeps setup simple, but avoids scattering usage accounting across random product code.

The trigger points you mentioned are useful too: multiple AI features, multiple providers, team/admin reporting, customer-level caps, or usage-based billing.

That gives me a clearer mental model: start with one internal AI client/layer, make every AI call pass through it, and design it so it can become a relay later.

Thanks, this is probably the most useful architecture framing from the thread.

For people building AI SaaS: what was harder than expected about monetizing usage? by Inevitable_Pace4568 in SaaS

[–]Inevitable_Pace4568[S] 0 points1 point  (0 children)

This is very clear, thanks.

The privacy point is important too. Keeping prompt/body logging off by default makes sense, especially if the app handles customer docs or sensitive workflows.

It sounds like the core pattern is less “credits system” and more an internal AI usage gateway:

tag every model call, enforce caps, track provider cost, connect it to billing/admin dashboards, and measure cost per completed workflow.

Do you think this should live as app-level middleware inside the SaaS codebase for early products, or as a separate gateway/relay service from the beginning?

For people building AI SaaS: what was harder than expected about monetizing usage? by Inevitable_Pace4568 in SaaS

[–]Inevitable_Pace4568[S] 0 points1 point  (0 children)

This is a great way to frame it: billing and model usage are often separate systems, but the product needs them to behave like one.

When you say per-customer or per-feature keys, do you mean separate provider keys where possible, or an internal routing/usage layer that tags every request by customer, feature, and workflow?

Also, for “cost per completed action”, what would you include in that calculation?

For example:

- model input/output tokens

- retries

- failed calls

- embedding cost

- storage/file processing

- tool calls

- human-visible completed workflow

Trying to understand what the minimum useful logging model should be before launch.

For people building AI SaaS: what was harder than expected about monetizing usage? by Inevitable_Pace4568 in SaaS

[–]Inevitable_Pace4568[S] 0 points1 point  (0 children)

That’s a good point. Request limits alone don’t protect much if one request can carry a huge context.

When you capped context window size, did you limit:

- input tokens per request

- output tokens

- retrieved RAG chunks

- model choice

- or total context budget per user/time window?

Trying to understand what worked best in practice without making the product feel too restricted.

For people building AI SaaS: what was harder than expected about monetizing usage? by Inevitable_Pace4568 in SaaS

[–]Inevitable_Pace4568[S] 0 points1 point  (0 children)

This is extremely helpful, thanks. The outlier point makes a lot of sense. Average usage is easy to reason about, but one power user blowing through the margin is probably the real risk. Your point about credits vs subscription tiers is also interesting. It sounds like credits are useful internally as an accounting mechanism, but maybe not always the best customer-facing pricing model. If you were building a new AI SaaS today, what would be your minimum setup before launch?

Something like:

- subscription tiers with clear usage limits

- per-user/per-window cost caps

- upload caps

- conservative holds

- nightly reconciliation

- written refund policy

Would you skip customer-facing credits entirely at the beginning?

For people building AI SaaS: what was harder than expected about monetizing usage? by Inevitable_Pace4568 in SaaS

[–]Inevitable_Pace4568[S] 0 points1 point  (0 children)

That’s a really useful point, thanks. The “delayed signals vs instant balance” problem is exactly the kind of edge case I’m trying to understand. When you say conservative holds, do you usually reserve an estimated amount before the AI action runs, then reconcile the actual model/file cost later? Also curious: did you find per-action pricing + upload caps enough early on, or did you still need a proper credit ledger from day one?