The messy middle of PLG AI economics

The economics of PLG are changing again.

The old PLG move was simple: remove friction, let people try the product, and ask for money after the product has proved itself. That bargain still feels right to users. It is also getting harder for the company on the other side of the signup form.

AI products, data products, API products, automation products, and agentic workflows do not just reveal a dashboard after signup. They spend inference credits, paid API calls, exports, automations, support attention, team seats, and sometimes real operational risk.

That creates a bad choice.

You cannot blindly trust every new user, because sophisticated spam and abuse traffic can spend your budget before a human even notices. But if you put a credit card in front of everyone, you lose the conversion lift that made PLG worth doing in the first place.

AfterAuth serves the messy middle between those two instincts.

A card gate is clean because it is crude

A card gate gives you an easy story: no card, no cost.

That story is often too expensive.

The serious buyer who would have converted after seeing value leaves at the checkout wall. The curious developer never proves the integration works. The champion trying your product between meetings never gets to the aha moment. You protected the budget, but you also protected the product from being evaluated.

The opposite story is not acceptable either. "Let everyone try it" worked better when trying mostly meant reading screens and clicking around. It gets dangerous when trying means subsidized compute, generated content, enrichment calls, exports, credits, or agentic action.

This is why the middle is messy. You need more than authentication, but less friction than payment. You need a policy-backed way to say:

• yes, this account can run the full workflow;
• yes, but only for a starter amount;
• not yet, verify something first;
• no, this looks abusive;
• queue this for review because the signal is ambiguous.

That is not a signup page. It is a runtime decision.

What you end up building in-house

The first in-house version usually looks reasonable.

You add a feature flag. Then a quota column. Then a rate limit. Then a billing check. Then a fraud signal. Then a support override. Then a customer-success exception. Then a policy table. Then a dashboard view. Then an audit trail because finance asks why a no-card trial spent money. Then support needs to explain why one user got a limit while another user got a full unlock.

None of those pieces is exotic. The hard part is that the decision stops living in one place.

Auth knows who the user is. Feature flags know which path they saw. Billing knows whether a card exists. Rate limiters know request volume. Analytics knows what happened after the fact. Fraud tooling may know whether the account looks risky. OPA or an internal policy engine can evaluate rules. Support has the human exception history.

But the PLG product needs a single answer before the costly action happens:

Given this user, this request, these signals, this policy, and this past behavior, what is the grant?

If you do not make that answer a first-class object, it becomes a scattered convention.

What AfterAuth already had to make real

This is the part that is easy to underestimate from the outside.

AfterAuth is not just an if statement around a trial. The product has to turn a messy trust question into a repeatable runtime contract.

The core evaluator produces one of five outcomes: allow, allow_limited, delay, require_verification, or deny. That matters because PLG trust is not binary. A product often wants the starter yes: enough value to prove the workflow, not enough budget to become an open tab.

The policy model supports ordered rules, defaults, approved ratios, maximum approved amounts, allowed capabilities, reason codes, prior-event checks, and review queue flags. In plain language: the policy can say "give this user the sandbox capability for up to four generations if they verified work email and have not already completed three generations." That is the kind of condition teams end up hand-rolling in product code.

The evaluator also separates abuse dominance from ordinary policy matching. Known abuse, disposable email, multi-account detection, velocity spikes, and repeated-device signals can force a hard deny or queue the decision for verification before the normal generous policy path runs.

Every decision freezes the request, signals, abuse result, policy match, email classification, requested amount, approved amount, allowed capabilities, outcome, and reason codes into a context object. Then it hashes that evidence. The receipt is not marketing decoration. It is how the company explains what happened later.

The API makes evaluation idempotent on requestType plus requestId, so a retry does not silently re-roll the trust decision. It persists decisions, events, and review queue items per tenant. Prior events feed back into later policy checks, so the system can reason about behavior like "this user already consumed the starter generation limit."

The SDK keeps customer code focused on the decision: call evaluate, read outcome, use approvedAmount, and report later events back. The dashboard and demo surfaces expose the same mental model: trust profile, requested amount, approved amount, capability, decision cause, reason code, next milestone, and receipt.

None of that is impossible. That is the point. It is possible enough that many teams accidentally build pieces of it. It is also enough moving parts that it deserves to be a product if your team does not want to own the whole trust workflow.

The build-versus-buy line

You should absolutely build this yourself if you are Notion, or a company operating at that level of product scale.

If you have a trust and safety team, a mature data platform, internal policy tooling, fraud operations, support workflows, finance reporting, and an engineering team of roughly five people who can own this surface across product, backend, dashboard, SDK, and operations, build it. You will want the control. You will have enough volume to justify custom machinery. Your weird cases will be important enough to deserve first-party ownership.

If that is not you, be honest about what "we can build this" means.

It means building the evaluator. The policy authoring model. The event model. The abuse override path. The limited-unlock semantics. The receipt. The evidence hash. The idempotency story. The review queue. The operator dashboard. The support explanation. The finance explanation. The SDK boundary. The migration path when rules evolve. The tests that prove a retry does not grant twice and a policy change does not rewrite history.

And then it means maintaining all of it while you are also trying to build the actual product your users came for.

Why this is a PLG primitive

The thing changing in PLG is not that users are less trustworthy. It is that the first proof of value has become more expensive.

That means teams need a new primitive between "logged in" and "paid customer." They need something that can preserve the product-led motion without pretending every new account deserves the same budget.

AfterAuth is that primitive: a deterministic trust decision layer after auth and before costly usage.

It lets a PLG product keep the door open without handing every stranger the same wallet. It gives the user a path to value, the company a way to limit spend, support a receipt, finance an explanation, and product a policy surface that can evolve without scattering trust logic across the codebase.

That is the messy middle. It is not glamorous. It is where the economics now live.