In SaaS, an extra free user costs you nothing. In AI, every free user costs you money.

Every time they hit Enter, your GPUs fire and your cash burns. Growth explodes. Then your bills arrive.

So the old freemium playbook breaks. “Give away the basics, gate the best features” assumes free is cheap. In AI, your free tier is your single biggest compute bill, and your best feature might be the most expensive thing you own.

A huge thank-you to Vikas Kansal and the Google AI team, whose paywall framework this is built on. 🙏

The trap: one premium tier

Google AI hit this wall in public. Their first move was the classic play: a single $20 Gemini Advanced tier, pay for the smartest model.

Two things broke. The free tier was already, in users’ own words, “smarter than I am,” so most saw no reason to upgrade. And the power users who did upgrade burned so much compute the unit economics were terrifying.

In other words: one tier can’t price a cost that scales with every prompt. You have to gate on what users value and what the company pays for, at the same time.

So what do you gate? Three things.

Gate the volume

Price the work pumped through the system, not the smarts. Google split one tier into three: Plus, Pro and Ultra, each a level of usage intensity, up to a 1M-token context window. Midjourney does the same with Fast Mode (instant GPU, metered hours) versus Relax Mode (free, but you queue). Light users stay free. Heavy users pay because they cost more, not just because they value more.

Gate the outcome

Stop selling answers. Start selling hours.

The free tier gives the right answer, then leaves you to copy, paste, reformat and re-prompt. Put the paywall in front of the features that finish the job: automation, agents, integrations, export. Intercom’s Fin agent is the cleanest version. It’s free to let the AI try, and you pay $0.99 only when the problem is actually resolved.

Gate the heaviest compute

Some features melt the servers. When Google built Genie 3, its real-time world model, the internal joke was that “the TPUs were melting on every prompt.” Serving that to every free user wasn’t a bad business move. It was physically impossible.

So it went to the top tier only. Make text and basic images universally free to pull people in. Set a hard gate the moment someone wants cinematic video, a real-time simulation, or a 3D world.

Tiers capture the budget. The ecosystem keeps it.

Right now, users are pouring experimental dollars into AI. Those budgets won’t last. Well-priced tiers capture that money. An ecosystem around them is what keeps it.

Convert at the moment of intent. The upsell is timing, not packaging. Google watches three signals: a user who refines the same output five times in one session (that’s real work), a user on both desktop and mobile inside 48 hours (the tool is now part of their day), and the “continue this chat” soft paywall, where a shared conversation needs a Pro model and proves its value before anyone pays.

Bundle for month two. AI churn is brutal because the habit isn’t formed yet. So tie the subscription to something stickier. Google bundled AI with Google One cloud storage, and nobody cancels the thing holding their photos, so the AI habit survives almost by accident. Cursor did it by indexing your codebase: churning means tearing down your own setup.

Route prompts so cheap stays cheap. You can’t serve your biggest model to every free prompt. “What’s the capital of France?” should hit a tiny, fast model. A logic puzzle routes to a heavy reasoner with token metering. The user still gets instant magic. Your margin stays invisible.

The traps underneath

Three margin traps will catch you even when the gates are right.

Don’t break trust. AI usage spikes around projects and exams, then stops. Bury the cancel button and a temporary pause becomes a permanent exit. Offer a one-click pause that keeps their saved prompts, and they come back for the next heavy week.

Don’t lock your tiers in stone. Today’s premium model is next quarter’s commodity. Lock the boundaries and you bleed margin (giving away $5,000 of compute on a $200 plan) or bleed users (a rival gives your “premium” away free). Audit unit costs constantly. Keep room at the top for the next breakthrough.

Don’t ship peak-agnostic pricing. A flat 24/7 rate while your GPUs redline on weekday afternoons and sit idle on Sundays trains people to run heavy jobs at your most expensive hour. Add usage multipliers or compute “happy hours” to smooth the load.

Gate the volume. Gate the outcome. Gate the heaviest compute.

Open your pricing page next to your compute bill. If your most expensive feature sits in your cheapest tier, you’ve found the leak. Tell me which feature it is. I read every reply. 🙏

Source Notes

• AI freemium cost structure. Vikas Kansal’s Google AI essay via Lenny’s Newsletter supplies the central claim: SaaS freemium assumes low marginal cost, while AI freemium has real inference cost on every active user.

• Volume, outcome, and compute gates. The Google AI examples, Gemini tiering, and Genie 3 compute constraint come from Kansal’s pricing framework. Source:

Lenny's Newsletter

Why SaaS freemium playbooks don’t work in AI, and what to do instead

👋 Hey there, I’m Lenny. Each week, I answer reader questions about building product, driving growth, and accelerating your career. For more: Lenny’s Podcast | Lennybot | How I AI | My favorite AI/PM courses, public speaking course, and interview prep copilot…

Read more

3 months ago · 346 likes · 6 comments · Vikas Kansal

• Aha moment without unlimited compute. Elena Verna’s freemium analysis supports the point that the free tier still has to deliver enough value for activation, even when cost must be controlled. Source:

Elena's Growth Scoop

Why AI doesn’t mean the end of Freemium

I’ve been a Freemium fan forever. It’s the best. But LLMs are expensive, so does that mean freemium is dead? A lot of products seem to think so - locking every AI feature behind a paywall like it’s 2014 SaaS all over again…

Read more

7 months ago · 57 likes · 5 comments · Elena Verna

• Outcome pricing. Intercom’s Fin pricing is the clean example of charging when the AI resolves the customer problem, not merely when it generates an answer. Source: https://www.intercom.com/help/en/articles/8205718-fin-ai-agent-outcomes

Someone in your company is still asking the wrong AI question.

“Which model should we use?”

“Which agent platform should we buy?”

“How many people are using it?”

Those questions are not useless. They are just not the hard part anymore.

The hard question is:

What work will change because of this?

That is the integration gap: the space between AI being available and AI changing how work happens.

Adoption means people used the tool. Integration means the work changed because of it.

Most companies are counting adoption and hoping it proves transformation.

It does not.

The model clock is faster than the work clock

There are two clocks running inside every company now.

The model clock moves in releases, benchmarks, demos, context windows, coding gains, and product drops.

It is fast. It is public. It is easy to see.

The work clock moves through incentives, leaders, workflows, data access, controls, trust, job design, quality standards, and one political question most AI roadmaps avoid:

Who has to change how they work?

That clock is slower.

Sometimes it barely moves.

When the model clock keeps accelerating and the work clock stays stuck, companies do not get transformation.

They get more impressive activity.

The last mile was the whole road

The clearest signal is not another model release.

It is the model companies moving into deployment.

In 2026, OpenAI launched the OpenAI Deployment Company to help businesses build around intelligence. Anthropic announced an enterprise AI services company with Blackstone, Hellman & Friedman, and Goldman Sachs.

Strip away the launch language and the admission is plain:

Access is not enough.

If access were enough, frontier labs would sell the interface and wait. Instead, they are moving toward workflows, data, use cases, handoffs, controls, permissions, and change management.

That is where the value is stuck.

Not in the model.

In the work around the model.

The last mile was not adoption.

It was integration.

Adoption is not integration

Adoption is easy to count.

Seats assigned. Training completed. Pilots launched. Champions nominated. Usage up. Internal posts saying, “I made this with AI.”

That can be a good start.

But it is not proof that anything important changed.

A person can use AI every day and still leave the organisation untouched. They can draft faster, summarise faster, code faster, analyse faster, and still push the work through the same old system.

The same meeting.

The same handoff.

The same approval path.

The same quality bar.

This is the difference:

Adoption → Integration

• People use the tool → The workflow changes

• Usage goes up → A task, handoff, or decision changes

• Champions share tips → Teams reset the baseline

• Pilots prove possibility → Controls make scale possible

• Leaders ask for examples → Leaders change the operating model

Adoption is contact with the tool.

Integration is change in the work.

The power-user story is not the strategy

The most dangerous companies are not the ones doing nothing.

They are the ones where smart individuals have moved faster than the system around them.

You can see the pattern.

A product leader has a private research workflow. An engineering leader has a code-review loop. A finance analyst has a forecasting prompt chain.

Each one is real.

Each one saves time.

Each one makes the person look sharp.

Then it dies there.

No one turns it into a reusable workflow. No one defines the quality bar. No one wires it to governed data. No one asks whether this should become the default way the team works.

The company gets AI anecdotes instead of AI infrastructure. That is the real failure mode: not lack of enthusiasm, but lack of integration.

The leader layer decides what sticks

If you want one diagnostic, look at leaders.

AI becomes real work when leaders change what good work looks like.

A leader who uses AI visibly gives permission. A leader who checks AI-assisted work sets the quality bar. A leader who only asks for usage numbers teaches the team to perform adoption.

This is why leader-on-tools matters.

Not because every executive needs to become a prompt engineer.

Because a leader who has never sat with the tools cannot set the standard for the work the tools produce.

They cannot tell the difference between a saved hour and a redesigned workflow, a clever demo and a production system, a prompt trick and a new team baseline.

The leader layer is where adoption either becomes the work or stays a side project.

Change the dashboard

Stop asking only whether people used AI.

Ask whether the work changed.

Use one integration review with five questions:

1. What workflow changed? — Whether AI removed, redesigned, or improved a real step in the work

2. What baseline moved? — Whether one person's better method became normal for the team

3. What quality bar changed? — Whether leaders can judge the output beyond "the tool produced it"

4. What controls are in place? — Whether data access, evaluation, logging, policy, and escalation can support scale

5. What decision or outcome improved? — Whether the change made work faster, better, cheaper, safer, or more reliable

These questions are industry-agnostic. They work for product surfaces, internal workflows, service operations, marketplace processes, regulated decisions, and engineering systems.

If the answer is only “people saved time,” the value story is still soft.

Saved time matters.

But the company has to decide what that saved time becomes.

Replace the adoption update with an integration review

Pick one AI initiative on the roadmap.

Replace the adoption update with an integration review.

Do not ask:

“How many people used it?”

Ask:

What work changed, who owns the new baseline, and what proof shows a better decision or outcome?

If the team cannot answer, the initiative is not transformation yet.

It is adoption.

That is not a failure.

It is just not the finish line.

The models are moving.

The question is whether the institution can move with them.

Do not buy a faster model and call it strategy.

Change the work.

Source Notes

• Adoption versus integration. PwC’s AI performance work supports the claim that value concentrates in companies that change the operating model around AI, not only adopt tools. External source: https://www.pwc.com/gx/en/issues/technology/ai-performance/want-ai-roi-go-for-growth.html

• Leader and organisation effects. Microsoft’s Work Trend Index supports the point that AI impact depends on agents, human agency, and organisational conditions, not only individual usage. External source: https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization

• Deployment-company signal. OpenAI and Anthropic moving into enterprise deployment services are used as evidence that access alone is no longer the hard part. Sources: https://openai.com/index/openai-launches-the-deployment-company/ and https://www.anthropic.com/news/enterprise-ai-services-company?pubDate=20260225

AI can now pass almost any test we give it. So people say it has caught up to us.

The sharpest warning about that came from an odd place. Not a tech lab. The Vatican.

Pope Leo XIV wrote a letter that captures it exactly. A machine can beat you on every test you can write, and still not be able to replace you.

The trap has a name worth keeping. The benchmark fallacy: treating “AI beat the human on the test” as “AI can replace the human.” (A benchmark is just a scored test.)

A test grades the answer. It never grades what makes an answer good when things go sideways: judgment, and the nerve to own the result. Passing the test and holding the job are two different claims. We keep merging them.

Acing the test is not the same as being trusted with the job.

Picture a sixteen-year-old who aces the written driving test. The score is real. It proves they learned the rules.

It does not mean you would hand them the keys to an ambulance in a snowstorm.

The test and the road are different places. Only one of them has a patient in the back.

AI keeps passing, which tells us less, not more.

The scoreboard looks one-sided. Back in 2024, AI was already clearing 80% on broad knowledge exams. By 2026 it was near 80% on harder tests too, including graduate-level science and fixing real bugs in real code.

The easy read is “the gap is closing.”

But there is an old rule here. Once a test becomes the goal, people aim at the test instead of the skill, and the test stops measuring anything real. Economists call it Goodhart’s Law.

A test everyone passes has stopped being a test. So the more AI aces them, the less the scores tell us about what people are for.

A priest and a tech crowd reached the same verdict.

In May 2026, Pope Leo XIV put it plainly:

“They may imitate language, behavior, and analytical skills, or even simulate empathy and understanding, but they do not understand what they produce.”

AI can copy how we talk. It can act caring. It still does not know what it is saying.

Here is the part I keep coming back to. The tech world reached the same place from the opposite side. Their version: AI does the easy part fast, so the hard part, the judgment, lands back on a person. The work does not vanish. It moves.

A priest and a tech podcast do not usually agree on anything. When they do, it is not a coincidence. It is a finding.

Some of what you would automate is how your team learns.

The Pope’s next point is the one most roadmaps miss:

“humanity flourishes not despite limitations, but often through them.”

In plain terms: the hard parts are often how we grow.

A job works the same way. Some struggle is just tedious, and a machine should take it. Some struggle is how a person becomes good at the work. Automate all of it, and the work ships faster while your people quietly get worse.

This argument has one real failure point, so I will name it. If AI gains lasting memory, a body, and real stakes in long relationships, the line blurs. Watch that line. But notice what would cross it: lived experience, not a higher score.

Before you automate a job, ask what the test never measured.

Stop scoring on “can AI beat the human.” Ask three smaller questions about each thing you plan to automate:

1. Where does a person have to understand the output, not just pass it on? That step is where your risk lives.

2. What are you giving up: judgment, a hard-won skill, a human touch? Decide that on purpose, before a postmortem decides it for you.

3. Which hard parts teach your team the most? Protect those. Automate the busywork.

And one rule for the calls you cannot take back: if you cannot see how AI reached its answer, do not give it the final say.

AI aced the written test. It was always going to.

Whether to hand it the keys was never on the test.

That part is still yours.

Source Notes

• The encyclical and its exact words. Magnifica Humanitas, Pope Leo XIV, issued 15 May 2026, “On Safeguarding the Human Person in the Time of Artificial Intelligence.” Paragraphs 99 and 118 are quoted word for word; the irreversible-decision rule is grounded in paragraph 198. External source: https://www.vatican.va/content/leo-xiv/en/encyclicals/documents/20260515-magnifica-humanitas.html

AI did not remove the need for product judgment.

It removed the excuse for not having any.

When agents can produce five flows, three prototypes, two launch plans, and a passable landing page by Friday, the hard question changes. It is no longer “Can we build it?” It is “Which version is worth shipping?”

That scarce work is taste.

By taste, I do not mean aesthetics. I mean product discrimination: the ability to tell useful from noisy, sharp from generic, finished from merely working, and necessary from extra.

The taste tax is the bill that comes due when execution gets cheap.

Subscribe now

When building gets cheap, choosing gets exposed

At Notion, the AI shift did not start with designers making prettier static mocks.

It moved the work into a shared prototype playground.

Brian Lovin, a designer on Notion AI, built an environment where designers could turn ideas into working prototypes with Claude Code. The point was not that every designer should become an engineer. The point was that AI products are hard to judge from static screens.

You have to feel the system behave.

A prototype that answers can still be wrong. It can use the wrong tone. It can hide the moment where trust breaks. It can complete the task and still feel generic in the user’s hands.

That is the right scene for the taste tax.

AI made the first version cheaper. It did not decide whether the interaction was good.

The new bottleneck is not making the artifact.

It is judging it while there is still time to change it.

Taste is not decoration

Taste is often treated as a soft word. That makes it easy to ignore.

Do not ignore it.

Taste is the operating standard underneath product work:

• What should we cut?

• What should we polish?

• What should we call this?

• Which version helps the user think less?

• Where does the feature cross from useful into trying too hard?

• What would make this feel like us if the logo disappeared?

Those are not decoration questions. They are product questions.

Before AI, weak taste was partially hidden by execution cost. Building was expensive, so fewer bad ideas made it all the way to users.

Now the gate is lower.

Bad taste ships faster too.

The failure mode is generic abundance

The first-order effect of AI is more output.

More drafts. More screens. More tests. More strategy docs. More prototypes. More “pretty good” versions of almost everything.

That sounds like leverage. Sometimes it is.

But abundance has a failure mode: teams stop discriminating. The roadmap only adds. The interface gets busier. The product starts to look like every other product built with the same models, the same templates, and the same unwillingness to say no.

This is the taste tax in the wild:

• The team can name twenty things to build and nothing to remove.

• “The model wrote it” becomes a defense.

• Code review catches bugs but not mediocrity.

• The definition of done ends at “it works.”

• Nobody can name a product they admire and explain the standard behind it.

The product is not broken.

That is the problem. Broken work gets fixed. Generic work gets shipped.

The signal is what the team refuses

The easiest way to see taste is to ask what the team refused.

A team with taste can show you the versions they rejected. They can explain why a feature was removed, why a label changed, why one interaction got another hour and another got killed.

A team without taste can only show you the output.

This is why “move fast” became more dangerous in the agent era. Speed without discrimination converges to the mean. If everyone has access to similar generation tools, the difference is not who can produce more.

The difference is who can choose better.

James Bessen’s work on automation points to the broader pattern: technology often shifts work rather than simply removing it. When the task gets cheap, the judgment around the task becomes more valuable.

The artifact got cheaper.

The standard did not.

Install a quality bar, not a taste lecture

Do not tell teams to “have better taste.” That is not a process.

Make the standard visible at the moment work is about to ship.

Use one review with three questions:

• What did we refuse? Tests whether the team can cut. A good answer names a rejected version, feature, message, workflow, or interaction — with a clear reason.

• What did we elevate? Tests whether the team improved beyond “it works.” A good answer names one change that made the output clearer, simpler, safer, more useful, or more distinctive.

• What standard did we apply? Tests whether taste is shared or personal. A good answer is a reusable principle the next team can apply without the original reviewer in the room.

This keeps the advice industry-agnostic. The artifact might be a product flow, pricing change, policy answer, data workflow, onboarding moment, service script, or internal tool. The standard is the same: the team can explain why this version deserves to exist.

Over time, save the best answers. That becomes the team’s taste library: not a mood board, but a record of good decisions.

What changes Monday

Pick one AI-assisted feature your team is about to ship.

Do one thing before launch: run a refusal review.

The launch decision should not be: “Does it work?”

It should be:

Can the team explain what it refused, what it elevated, and what standard it used?

If the answer is mostly silence, do not call the work finished.

Call it generated.

The market will not punish you because your team is slow.

It will punish you because everyone is fast now, and your product looks like theirs.

Sources

• Lenny’s Newsletter — I haven’t written a single line of code in six months: https://www.lennysnewsletter.com/p/i-havent-written-a-single-line-of

• Lenny’s Newsletter — Why cultivating agency matters more than cultivating skills: https://www.lennysnewsletter.com/p/why-cultivating-agency-matters-more

• James Bessen — Toil and Technology: https://www.imf.org/external/pubs/ft/fandd/2015/03/bessen.htm

• Paul Graham — Taste for Makers: https://www.paulgraham.com/taste.html

An AI demo is not an eval.

That is the mistake behind a lot of brittle enterprise AI rollouts. The demo proves the model can answer one polished question in one controlled room. An eval — a test set of real cases, scored against a written standard — tells you whether the system can survive actual users.

Most teams still ship the demo.

That is what I am calling straw prompting: building an AI feature out of a hand-tuned prompt, testing it on the cases that already work, and launching before the messy cases arrive.

It looks like a house.

It is not ready for weather.

Subscribe now

The happy path is not the product

Air Canada learned this in public.

In 2022, a customer used Air Canada’s website chatbot while booking travel after a death in the family. The chatbot told him he could buy a full-price ticket, travel, and then apply later for the airline’s bereavement fare.

That was wrong.

The airline’s actual bereavement policy said the discount could not be requested after travel had already happened. The chatbot even linked to the page with the correct policy, but the answer it gave in the conversation was still misleading.

The customer relied on the chatbot, travelled, and later asked for the fare difference. Air Canada refused. In 2024, British Columbia’s Civil Resolution Tribunal found Air Canada liable for negligent misrepresentation and ordered it to pay damages, interest, and fees.

The product lesson is not “chatbots are bad.”

It is sharper than that.

Air Canada had the correct information on its own website. The failure was that the interactive answer surface did not reliably behave like the policy it was supposed to represent.

That is the straw-prompting pattern in the wild.

The company did not just need a chatbot that could answer bereavement questions. It needed a system that could notice policy conflict, ground answers in the current source of truth, and escalate when the answer affected money, rights, or obligations.

A working answer was not enough.

The answer had to be governed like part of the product.

The wolf is variance

The wolf is not a smarter model from a competitor.

The wolf is variance: the messy spread of real-world inputs that your demo never saw.

Users misspell things. They paste half a policy. They use internal acronyms. They ask two questions at once. They omit context. They ask in anger. They ask in formats your prompt writer did not imagine.

OpenAI’s eval guidance makes the point plainly: AI systems need task-specific tests that reflect real-world conditions, edge cases, and continuous change. “Looks good to me” is an anti-pattern, not a launch gate.

That is the trap. A demo that works ten times in a row does not tell you how the system behaves on the eleventh thousand.

The launch review should expose the failure mode

You do not need a 40-point governance checklist to spot straw prompting.

You need a launch review that separates symptoms from causes. Run it against five patterns:

• Polished examples, not error rates — the team tested the demo, not the system. Require a real-input eval set before launch.

• No one can name the top failure modes — the risk model is missing. Write the failure list before tuning the prompt.

• Output quality judged by vibes — the team has no shared standard. Create a rubric before reviewing answers.

• “Guardrails later” in the plan — controls are being treated as cleanup. Define refusal, escalation, and source-of-truth rules now.

• The prompt writer also wrote the tests — the eval is likely overfit to the happy path. Add messy cases from real usage, edge conditions, policy boundaries, and expert review.

The point is not to punish the team for moving quickly. It is to find the root cause while the cost of fixing it is still low.

Build the test before the prompt

The fix is not a giant governance program. It is a different order of operations.

Start with the test.

For any AI feature, collect 100 to 300 real or realistic inputs from the hardest part of the workflow. Include short requests, long requests, ambiguous requests, boundary cases, policy conflicts, and cases where the right answer is “I do not know.”

Then write the rubric.

What counts as correct? What counts as unsafe? When should the model refuse? When should it escalate to a human? What evidence should it cite? What must it never invent?

Only then tune the prompt.

The prompt has to earn its way through the mess. Otherwise you are not improving the product. You are decorating the demo.

The brick house has gates, owners, and reruns

Once the root cause is clear, prevention is boring on purpose.

Brick-house AI rollouts put four controls in place before launch:

1. A golden set. The small, trusted collection of examples that defines what “good” looks like. It includes normal cases, edge cases, and failures you never want to see twice.

2. A named owner. Someone owns the eval set, the rubric, and the launch threshold. Without an owner, quality becomes a meeting mood.

3. Escalation rules. The system knows when to refuse, when to cite the source of truth, and when to send the user to a person.

4. Scheduled reruns. Models change. Prompts change. Retrieval changes. Product policy changes. The system that passed Tuesday may not pass next Tuesday.

What changes Monday

Pick the next AI feature waiting for launch approval.

Do one thing: replace the demo review with an eval review.

The launch decision should not be: “Did the examples look good?”

It should be:

Did the system pass the real cases, against the written rubric, with clear escalation rules and an owner for reruns?

If not, do not approve the launch.

Approve the demo, if you want.

Just do not mistake it for a brick house.

Sources

• OpenAI — Evals: https://platform.openai.com/docs/guides/evals

• OpenAI Cookbook — Evals design guide: https://cookbook.openai.com/examples/evaluation/evals_design_guide

• NIST — AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework

• Deeth Williams Wall — BC Tribunal Finds Air Canada Liable: https://www.dww.com/articles/bc-tribunal-finds-air-canada-liable-for-inaccurate-advice-given-by-website-chatbot

• American Bar Association — BC Tribunal Confirms Companies Remain Liable: https://www.americanbar.org/groups/business_law/resources/business-law-today/2024-february/bc-tribunal-confirms-companies-remain-liable-information-provided-ai-chatbot/