One thing we’ve tried to do in every edition is build AI tools for specific problems. Automate this, extract that, summarise the other thing — basically all the engineering stuff.
The fact of the matter is: no matter how helpful your product is, there’s no guarantee it will sell. Simple reason: AI products work differently compared to regular SaaS products.
Build Sprint S3 sold out in 48 hours. S4 could sell out faster.
GrowthX presents Build Sprint Cohort 4: Learn to build and sell an AI product in 2 weeks.
Week one: ship a live product. Week two: put it in front of real people and sell it. Runs on weekends and weekday evenings — no quitting your job or coding experience required.
Build Sprint is priced at ₹19,999 today. It includes a month of ChatGPT Pro worth ₹10K, in collaboration with OpenAI.
AI products evolve differently.
Think about a SaaS product you’ve used. Say, Slack before it had AI features. And compare it to ChatGPT for a second.
1. The cost structure changes.
Take Slack, for instance. It uses the same underlying technology to serve every new user entering the platform. Adding one more seat costs nothing on the backend.
Meanwhile, AI products carry a real cost for every inference, every generation, every query. GitHub Copilot averaged a $20-per-user monthly loss against a $10 subscription because heavy users consumed 2–3x the seat fee in compute.
2. There’s an additional cost to switching.
AI products learn from individual use. The product a specific user has on day 300 is meaningfully different from what they had on day 1 — not for everyone, but for them. Leaving means losing that. So, personalisation and AI context become a structural moat. It’s also why I’m struggling to move from Claude to ChatGPT at work.
3. There’s no predictable path to conversion.
RevenueCat’s 2026 data shows AI apps earn 41% more per paying user but churn 30% faster than non-AI apps. That stat tracks. Why? AI products must meaningfully make our lives easier compared to regular SaaS products.
Think about it.
If I went to Claude looking for an answer and it didn’t give it to me quickly in the format I wanted, I’d switch. After all, AI is supposed to be quicker and intuitive.
This expectation compresses the delight window. Meaning funnels must compress and adapt as well.
4. Acquisition and distribution can converge
Traditional software companies need a dedicated team to acquire new users. Often, it’s a dedicated marketing team.
Many AI products don’t need that. Why? When you use an AI product, what it produces for you is good enough to share. You generate an image on Midjourney and post it on Twitter. Your friend sees it, asks, “How did you make that?” and signs up. The product acquires users through distribution rather than marketing, up to a point.
All those points put together change how AI products can grow then. Let’s explore that.
1. Acquisition
Traditional software had a gap between “I’m curious” and “I see the value.” That gap was filled by forms, sales calls, product tours, and onboarding checklists because the product value wasn’t clear.
AI products collapse that gap to one interaction. Perplexity’s first screen after signup is a search bar. You needn’t even log in.
Gamma took this further. Their founding team discovered through testing that users left at the blank page of an unfamiliar tool on the first screen, gone. Instead, their first page had a field for entering a prompt to generate a complete presentation in under a minute. Lovable does the same thing with product builds — describe what you want, get a working prototype.
Now, ProductLed’s research puts AI time-to-value at 60 seconds, not 30 minutes. Meaning, in an AI product, 30 minutes might mean the user couldn’t get the output they needed.
It also changes what data you have access to.
In a traditional product, you infer intent from behaviour — clicks, drop-offs, funnel conversion rates. In an AI product, every prompt is the user stating their intent in their own words. What people ask for, how they phrase it, where the AI fails them — none of that requires a survey.
Where you spend your time shifts as well.
Traditional experimentation meant changing the button colour, the headline, the layout. AI product experimentation means changing the system prompt, the output format, and the context the model receives across sessions.
In practice, this means defining the rubric. What does a minimum acceptable output look like? A customer support AI that escalates any refund-related issue to a human is a rubric. An image tool that automatically regenerates when the output contains a distorted face is a rubric. You get the drift.
2. Engagement
Every traditional engagement playbook is built on one assumption: the company decides when the user comes back. All while the product waits, manufactures a reason to interrupt, and hopes the timing is right.
AI products have landed on three distinct ways to solve this: pull utility, platform embedded, and ambient.
1. Ambient engagement
Take Wispr Flow, for instance. It sits at the system level and appears wherever your cursor is, including Gmail, Slack, Notion, Claude, and your terminal. You hold a hotkey, speak, and the text appears. No app to open. No interface to learn. No engagement loop to design.
Ambient engagement has only been possible since LLMs arrived. Microsoft attempted exactly this with Clippy in 1997 — sitting at the OS layer, triggering based on what you were doing across applications. It failed because the system couldn't understand natural language, couldn't act without explicit commands, and had no standard protocol for cross-app presence. MCP solved the third problem. LLMs solved the first two.
2. Platform-embedded engagement
Starting February 2026, Claude Code users could type “Send this to Figma” and watch running UI translate into fully editable design layers. Figma became a destination that AI agents routed to when they needed to generate UI or obtain design context. Result? Figma Make usage jumped 70% quarter over quarter. Moreover, 60% of Figma Make files are now created by non-designers.
Canva, Spotify, Booking.com, and Coursera took the same path. All four now live inside ChatGPT via MCP Apps. Users don’t go to Canva to design — they describe what they want mid-conversation, Canva renders it, and editing happens in Canva’s native product if the output is worth developing. So, the native app is where deeper engagement can happen.
3. And then there is pull utility
Products like ChatGPT itself, which engage like Gmail. They open it because they need it.” 250 million users return every single week. These products engage when there is a problem to solve. When there isn’t, they wait.
So, did streaks, leaderboards, and push notifications disappear?
No. Duolingo, for example, still runs them. That decision led to churn dropping from 47% to 28% in core markets. What AI adds on top is this: the product can now generate a personalised reason to return, unique to each user, that didn’t exist until the AI computed it from their own data.
Something like: your recovery time improved by 8% this month; here is what changed. The trigger is generated, instead of scheduled. And the insight is personal.
So, how does it impact building?
The question for any product builder in 2026 is not which re-engagement campaign to run. It is which model fits the job the product does: utility that earns return visits through memory, ambient presence that makes return visits irrelevant, platform embedding that borrows someone else’s engagement loop, or a native experience with AI-generated triggers that no notification team could have written at scale.
3. Retention
For decades, SaaS companies built retention the same way. Get your workflow inside the product. Make your tool the place where work happens. Once a sales team runs their pipeline in your CRM and a design team keeps all their files in your platform, the data is trapped, the workflows are memorised, and switching is too painful to bother with. Good UX helped.
Not anymore.
“Imagine moving from Gmail to Outlook, or HubSpot to Salesforce, with a prompt. Imagine the new app’s AI spinning up templates for your business and cleaning up your data, making the switch feel like a fresh install.” AI makes switching frictionless by operating any tool, migrating any data, and rebuilding any integration.
So, retention in AI products is a fundamentally different problem.
We think there are three levers at play here.
1. The first is accumulated memory.
Model switching cost keeps falling. Memory switching cost compounds with every week on the platform. The widening gap between the two curves is the moat.
Put simply, as time goes by, upgrading your model within an AI tool will get easier, and models will get better at doing the work. At the same time, you’ll continue to build your personal context within the tool. Ideally, a product will do both for you.
Take Spotify.
Their Large Taste Model processes 3.4 trillion user events daily. The recommendations a listener receives in month twelve diverge meaningfully from month one — twelve months of their specific plays, skips, saves, and replays, accumulated and non-transferable. Switching to Apple Music means starting over.
2. Then there’s workflow depth.
When the AI becomes the operating system for a specific job rather than a tab someone opens occasionally, switching costs are no longer about effort — they are about rebuilding institutional memory.
So, if you have all your skills stored in ChatGPT, for instance, and have devised a way of working with it, like me, switching to Claude is a chore.
3. The third is predictive intervention.
Netflix’s ML models analyse viewing frequency, engagement with new content, and billing-cycle behaviour to flag at-risk subscribers before they cancel, based on their behaviour over time. A targeted program in 2022 cut cancellations by 6% in three months. Their recommendation engine is estimated to save over $1 billion annually. 80% of hours watched originate from AI-personalised suggestions.
What that means for the builder.
You must ask yourself if the product is designed to accumulate something the user cannot easily reconstruct elsewhere — and whether the user trusts it enough to let it learn. Both have to be true. One without the other is either a moat with no users or a product with users and no moat.
Which brings the hardest question in AI product building: how do you monetise something people increasingly don’t want to pay for?
4. Monetisation
OpenAI projects $14 billion in losses for 2026. Sam Altman has publicly admitted he personally set the price for ChatGPT Pro at $200 a month, thought it would make money, and was wrong. “People use it much more than we expected.” If the company that invented the category hasn’t solved AI monetisation, nobody has.
Why is that?
See, traditional software has near-zero marginal cost. Adding one more user to Slack costs almost nothing.
Meanwhile, AI products carry a real inference cost for every query, every generation, every agent run. A heavy user and a light user pay the same seat fee but consume wildly different compute.
The demand side makes this problem much harder.
People try the product, say “wow,” tell their friends, and then use the free tier forever. The problem isn’t that users don’t value AI. They do. The problem is they value AI in general, not your specific AI.
Three pricing models have emerged.
1. The first is usage-based pricing.
Revenue moves with inference cost. You pay for what you consume. It solves the margin problem for the seller, and then immediately creates a new one for the buyer.
The thing is, procurement teams cannot forecast spend. Individual users cannot predict their bill. So, churn goes up even when usage is high because people can’t pay up.
2. The second is hybrid pricing.
A subscription base that includes a consumption quota, plus overage pricing beyond that quota. Telephony, cloud infrastructure, and CDNs have run on this model for decades. It is the shape the AI SaaS category is converging toward. By 2025, 85% of SaaS leaders had adopted usage-based or hybrid models.
Clay introduced dual-track monetisation in March 2026, separating platform value from token cost into distinct buckets.
3. The third is outcome-based pricing.
The user pays for results — a lead generated, a contract processed, a support ticket resolved. The logic is clean: align revenue with the value the user actually receives.
Salesforce launched AgentForce at $2 per conversation. And then they moved quickly to a credit-based model. Why? Because outcome-based pricing works when the value metric is clear, trackable, and agreed on. Most AI products do not have that yet.
Besides, the prices users pay today are not market rates.
They are customer acquisition costs. OpenAI is pricing inference below cost to capture market share, and that subsidy is what makes the category look accessible right now.
What does that mean for builders?
Ask these three questions in sequence. What does the user perceive as the value unit — a session, an output, a result? Does the pricing model survive a power user, or does it actively lose money on the people who love the product most? And does the model encourage the behaviour that leads to retention? Then make a decision.
What’s next?
None of what we discussed today is theoretical. AI product builders are making all these decisions right now, some of them in our new cohort.
If you’re tired of building side projects and want to really build AI products that sell, you’re invited. In 2 weeks, you’ll go from a beginner to someone who builds with AI, thinks like a PM, and sells confidently.
What’s more, OpenAI covers your build credits. And you’ll get access to live sessions, daily check-ins, and 24/7 support.
Cohort starts 2nd October.
There's also a packaging issue underneath this: SaaS pricing assumes stable, predictable usage patterns, but AI tools have variable output quality depending on the input, so buyers are effectively pricing in uncertainty. That's why so many AI products end up selling as a pilot or a service wrapped around software rather than a straight subscription. Did Build Sprint S3 end up changing the pricing model, or just the sales motion?
This feels like a shift from selling software to earning a place in a workflow. The moat may be less about feature count and more about reliable context, distribution, and a clear handoff when the model is uncertain.