The first real users of a product aren’t just testers. They’re mirrors. Every drop-off, complaint, or upgrade hesitation reveals something that was missed.
For Learnflow AI, I launched fast.
- Voice-first learning agents, powered by Vapi
- Convex as a real-time backend
- Kinde for auth, access, and pricing
I had the scaffolding in place. Auth worked. Sessions were tracked. People could talk to AI tutors.
But when the first 10 users came in, I realized: the code worked. The logic was solid. But the business layer? It was foggy. Friction was everywhere.
Almost all of them stopped using it after their first try.
No upgrades. No sessions beyond the free credits. Just one brief interaction... and silence.
This post is about what happened next.
It’s a breakdown of what I got right, what I got wrong, and how those 10 users taught me more than any launch plan ever could.
First Signs of Friction
One weekend after launching to a small early access list, users signed up.
- 7 created a tutor.
- All 7 started a session.
- 4 finished more than one session.
- 0 upgraded.
I had built pricing tiers, but they were optional. Users landed inside Learnflow AI, got a free 10-credit plan, and only hit the paywall when credits ran out.
That seemed reasonable.
But the first 10 users didn’t behave like I expected.
Behavioral friction appeared before pricing friction.
What My Users Actually Experienced
The real flow:
- Create an account
- Land on Kinde pricing page
- Pick "Free" plan
- Get dropped into the dashboard
- See a “Create Tutor” CTA
- Start a session
- End session. Left confused about value.
They got to the dashboard, saw a grid of public tutors, and hit “Start Session”. One spoke for a minute. Another didn’t speak at all.
The problem? They didn’t know how many credits they had, what counted as usage, or what "Pro" included.
To them, it wasn’t a tool — it was just another AI demo. Disposable. Forgettable.
Where the Friction Lived
Credit system
Credits worked under the hood. I tracked voice session starts in Convex and deducted 1 credit per call, but they were too abstract.
“Wait… what are credits?”
That’s what one user emailed me.
They didn’t know that:
- 1 session = 1 credit
- Free users only got 10
- Pro gave them 100/month
I had listed it in the pricing plan.
But that wasn’t enough.
Upgrade path
There was an "Upgrade" link. But it lived on the billing page. Out of sight.
So:
- No urgency to upgrade
- No nudges
- No post-session prompt
The First Fix: Show, Don’t Just Charge
Instead of abstracting away usage, I made it visible.
UI Updates:
- Sticky credit counter in dashboard header
- "You have 9 credits left"
- After each session: "You used 1 credit"
- Under every tutor: “Pro feature” or “Free access”
I also added a more info icon that explained what credits were and how they were used during each session.
Every time a user returned to the dashboard, their remaining credits were front and center.
Friction lowered. Transparency up.
Friction Isn’t Just Technical — It's Emotional
One user DMed me:
"I wasn't sure what I was getting from Pro. It just felt like a payment wall."
They weren’t objecting to price.
They were confused about value.
I needed to:
- Show what Pro unlocked
- Trigger upgrade prompts based on actions, not page visits
- Embed a sense of ownership early
Introducing Contextual Upgrade Nudges
Changes:
- When out of credits: show a full-screen banner
- When starting a session: if Pro-only, show modal
- Added a side panel comparison: Free vs Pro
Final Flow: Conversion-Oriented from First Click
I didn’t remove the free plan.
I restructured the journey around value.
Key Abstractions That Helped
Kinde
- Hosted pricing tables
- Session-based metadata (plan, email, credits)
- Role-based UI gating
Convex
- Real-time mutation calls
- Credit count as part of user doc
- Onboarding progress per user
Vapi
- Voice session start/stop in a single call
- WebSocket updates on transcript
- Minimal logic to manage conversation state
Real Users, Real Insights
Here’s what 3 of the first 10 users told me:
“The voice is great, but I wish I had more sessions.”
“I clicked upgrade but didn’t know if it worked.”
“I liked the tutor builder. Felt custom.”
Every one of these pointed to pricing clarity, upgrade friction, and session flow.
What I Got Wrong
- Assumed users would infer value
- Delayed upgrade prompt until too late
- Hid usage until credits ran out
- Placed pricing info out of sight
What I Got Right (Eventually)
- Visible usage counters
- Contextual nudges (not modals on page load)
- Clean hosted pricing via Kinde
- Flexible backend logic in Convex
- Usage metering by action, not time
What You Can Steal From This
If you’re building an AI tool — especially one with high marginal cost — here’s the playbook:
- Use Kinde to manage plans + roles
- Store billing metadata in your backend
- Enforce usage rules via middleware
- Make credits visible and trackable
- Design upgrade flows into the core experience
If pricing is separate from usage, no one upgrades.
If usage is invisible, value is invisible. If value is invisible, no one pays.
Final Thoughts
Your first 10 users are brutally honest. They won’t give you feedback in Notion. They’ll just leave.
But every exit teaches you something:
- About your pricing
- About perceived value
- About onboarding UX
Learnflow AI now guides users with clarity.
It still offers free access. But not as a dead-end demo.
Instead:
- Usage is visible
- Pricing is obvious
- Upgrade prompts are timely
Kinde, Convex, and Vapi gave me the primitives.
But the system came together only through mistakes.
If you're building an AI app:
Don't just ask "Does it work?"
Ask: "Does the value make sense to a stranger?"
Your turn…
Have you launched an AI product with usage-based pricing?
What did your early users teach you?
Let’s trade notes in the comments.
Top comments (1)
Awesome read✨
This is where many developers miss it when building a metered, freemium, or paid solution. You could have the cleanest code, finest UI, best architecture, but if you miss out on implementing a sturdy business model for the application, well, let's just say, it's going to be crickets. Building such solutions requires one to be able to switch completely from a technical to a business mindset. The business mindset is what separates successful startup founders from other developers who have cool projects.