Last month I showed you the plumbing - a bash script that syncs customer call transcripts to my laptop so AI can search them. Nice infrastructure. But infrastructure is only as good as what you do with it.
This is the story of what happened when I used it.
In March, I sat down to design our self-serve onboarding funnel. We had traffic (323 active users/week on billabex.com), a product that worked (dozens of paying customers, 1,500+ managed accounts), and a problem: every new customer required a demo call with our sales guy. That doesn’t scale.
I thought I needed a signup form and a product tour. I ended up with something completely different. Not because I changed my mind on my own - but because AI challenged me at every step, with evidence I couldn’t ignore.
Here’s the full arc, with real prompts, real pushback, and real artifacts.
Step 1: Brainstorming - “Who is this actually for?”
I started with what I thought was a clear brief: build a self-serve onboarding funnel for our PLG motion. I had five personas in my head - the solo consultant, the agency owner, the artisan, the accountant, the SaaS founder. Five different paths through the product.
When I kicked off the brainstorm with Claude, the first pushback came fast:
Karim (artisan/BTP) has low digital maturity - “May need phone support.” If PLG means self-serve, Karim isn’t a PLG persona. He’s a sales-assist persona. You’re designing two different funnels and calling them one.
I argued back. Karim represents a real segment. But Claude kept pulling the thread:
Remy (solo consultant, 8-12 clients/year) activates on Starter at 49/month. His LTV is probably under 600/year. Your cost of acquisition through a self-serve funnel is justified, but your cost of supporting him through 5 different onboarding paths is not. How many Remys would you need to justify a dedicated onboarding path vs. letting him use Sandrine’s path?
I didn’t have a good answer. So we cut. Five personas became three plus a channel partner. Remy and Karim got dropped from the PLG funnel entirely.
What changed: The scope of who we were building for. Fewer personas meant a simpler funnel, which meant faster time to market. The instinct to serve everyone is strong - it took an outside voice to challenge it.
Step 2: Research - “Do your numbers actually work?”
With the personas narrowed, I set targets. 3-5% signup rate. 60% trial activation. Standard SaaS benchmarks. They felt right.
Then I asked Claude to challenge the targets against our actual data.
The pushback was immediate:
83% of your traffic is template-seekers from blog posts (free invoice templates, payment reminder models). They’re not product-intent visitors. 3-5% signup rate against 27,258 sessions means 800-1,350 signups in 90 days. You have dozens of customers after months of founder-led sales. Does 800 self-serve signups in a quarter sound realistic?
It didn’t. So we dug into the GA4 data together:
Total sessions (90 days): 27,258
Organic search share: 83%
Top pages: All free template/download blog posts
Homepage active users: ~1,025
Demo page active users: ~679
Avg engagement time: 38s
The picture was clear. Most of our traffic had zero product intent. The real denominator wasn’t 27,258 sessions - it was the ~700/month who visited the homepage, demo page, or pricing page.
We split the metric: global site signup rate (realistic: 0.2-0.5%) vs. product-intent signup rate (realistic: 5-8%). Both pointed to the same number: 30-60 signups in 90 days. Not 800.
Trial activation got the same treatment. 60% out of the gate? With less than 10 connectors live? We phased it: 30-40% at launch, 60% by week 12 after adding more integrations.
What changed: Our success criteria went from aspirational to grounded. We would have launched, seen 0.3% signup rate, and panicked - thinking the funnel was broken when actually it was performing exactly as expected against our real traffic mix.
Step 3: Research - “What does the data say about onboarding pain?”
This is where the 110+ transcripts earned their keep.
I asked Claude to search for onboarding-related patterns across all our customer
calls. The /ux-research skill loaded the full corpus and came back with a
finding I hadn’t expected:
54% of all agent tasks (171 out of 318) are NeedContacts - the agent can’t proceed because no contact email exists for the debtor account. 67 of the 111 closed NeedContacts tasks were resolved in under 1 minute (user adds contact via a form). This isn’t an edge case. It’s the single biggest operational blocker.
I was designing a funnel focused on “connect your accounting tool” as the key activation step. The data said the real bottleneck was downstream: even after connecting, the agent couldn’t work because client email addresses were missing.
From five onboarding sessions in January, Claude pulled consistent patterns:
- “Sync delays on first import >5 min for large account sets” caused anxiety when it relies on a silent process
- Whitelist mode (selecting accounts to include) was painful when you had 100+ accounts but only wanted 11 to be managed by the agent
- Users missed agent tasks entirely because there were neither an easy way to see it in app, nor a notification sent by email
- The help center was incomplete, blocking self-serve troubleshooting
One customer quote that redirected our thinking: “La V2 est vraiment top… c’est une machine de guerre” - but in the same call, that customer couldn’t figure out how to exclude accounts from follow-up.
What changed: The self-serve funnel may validate activation phase with a few signups but not the engagement one. We need to create a self-onboarding flow to engage new users in their free trial. Without searching 110 transcripts, I would have built a “connect your tool” step and called it done - missing the actual blocker.
Step 4: Planning - “What’s the simplest thing that proves PLG works?”
With research done, I started planning the funnel. My initial instinct: 6 steps, plan selection included, credit card on signup (like consumer apps do, even though we’re a prosumer one).
Claude pushed back on the payment gate with a pretty good question:
Claude and Gamma can gate with a credit card because their activation is instant
- you type a prompt, you get value in 3 seconds. For Billabex, real value (a client paying) takes days. If you gate with payment and get low signups, you won’t know why: was it the funnel that didn’t convince (product problem), or the payment wall that scared people (conversion problem)?
This reframed the entire funnel’s purpose. It wasn’t a conversion tool - it was a validation experiment. The question wasn’t “how do we get people to pay?” but “can users perceive value on their own?”
That distinction shaped every decision:
Payment
- My instinct: card on signup.
- What we built: no card, 30-day free trial.
- Why: isolate activation signal from conversion signal.
Plan selection
- My instinct: plan comparison grid in the funnel.
- What we built: a price simulator that recommends the right plan based on how many accounts the agent manages.
- Why: users don’t compare features - they need to know what it costs for their volume.
Demo
- My instinct: guided product tour.
- What we built: choose-your-own-adventure.
- Why: prove intelligence, not features.
Company fields
- My instinct: full company profile.
- What we built: 2 fields (name + sector).
- Why: every field kills conversion.
Agent setup
- My instinct: configuration form.
- What we built: one-click persona cards.
- Why: a fast choice beats a detailed setup.
The choose-your-own-adventure demo was the biggest departure. My original idea was a guided product tour - click here, see this screen, learn this feature. Claude argued:
A guided tour teaches the UI. But the user hasn’t seen the product yet - teaching UI before value is backwards. What if the user picks client responses and watches the agent adapt? That proves intelligence, not features.
Three turns. Nine paths. The user picks how the debtor responds (pays, stalls, disputes, goes silent) and watches the agent adapt in real time. It takes 90 seconds and shows the full collection arc: friendly reminder, adaptation, resolution or escalation.
Here’s the scenario tree:
Turn 1: Agent sends first contact email
A: Client promises payment -> Agent confirms + schedules follow-up
B: Client says never received invoice -> Agent resends + asks confirmation
C: No reply -> Agent escalates tone (5 days later)
Turn 2 (same 3 options for all paths):
A: Dispute -> Agent creates task for human review
B: Cash flow problem -> Agent proposes installment plan
C: Still no reply -> Agent sends formal notice
Three choices, three choices, automatic resolution. 3 x 3 = 9 paths, 3 resolution types. Simple enough to build in a week, rich enough to demonstrate real intelligence.
What changed: The funnel went from “sign up and explore the product” to “experience the AI agent making decisions before you commit to anything.” The demo IS the value proposition.
Step 5: The prototype (and then the prototype of the prototype)
With the plan locked, I built the first prototype. Static HTML, no backend - just enough to click through and feel the flow. Version 1 used a blue corporate palette, Nunito font, generic agent colors (blue, green, purple). It worked. It proved the flow.
The split layout (left panel sells, right panel acts) came from studying some signup pages such as Revid.ai’s one. The sticky sidebar on the demo step came from a Launchmap* pattern - CTA always visible, timeline building progressively as turns complete.
Then we iterated following some users’ feedback.
Version 2 brought the warm Billabex brand in - Outfit font, terracotta palette, agent cards with gendered colors (rose for Sophie, blue for Thomas, warm terracotta for Camille). The agents stopped feeling like generic slots and started feeling like people you’d pick to work with.
But the biggest change between v1 and v2 wasn’t visual - it was structural.
Remember that decision to keep pricing out of the funnel? We reversed it. The summary screen from the original spec (time saved + payment delay metrics) got replaced by a price simulator. A slider where you pick how many client accounts you manage, and Billabex recommends the right plan and shows you exactly what it costs - base price, overage, total.
Why the reversal? Because after clicking through v1, the gap between “wow, the agent is smart” (demo) and “what does this cost me?” (somewhere on the website) felt too wide. The user’s momentum died. Bringing pricing into the funnel - but as a personalized simulator, not a feature comparison grid - kept the flow going.
Two iterations in two days. The spec said one thing, the prototype said another. That’s the point of prototyping.
Small details that emerged from building:
- Agent emails in the demo use the exact real format (“Je suis Sophie Martin, chargée de compte chez Revoptim, mandatée par [votre entreprise]”) so there’s no disconnect between demo and reality
- Gender-aware language throughout - pick Sophie (feminine), Thomas (masculine), or Camille (neutral), and every pronoun in the interface adapts
- The CTA button stays disabled until turn 3 completes - a micro-goal that drives completion without being blocking
ICYMI:

Launchmap is one of my side projects: free distribution plan for vibe coders and indie hackers launching a project and looking for their first 100 users. Give it a try.
The gap between what I planned and what we built
Here’s a side-by-side:
Personas: 5 (Remy, Sandrine, Karim, Nathalie, Thomas) -> 3 + 1 channel (Sandrine, Thomas, Grégoire + Nathalie)
Signup target: 3-5% of all traffic -> 5-8% of product-intent traffic only
Activation target: 60% -> 30-40% at launch, 60% by week 12
Payment: Card on signup -> No card, 30-day free trial
Onboarding demo: Product tour -> 9-path choose-your-own-adventure
Pricing in funnel: Feature comparison grid -> Personalized price simulator (reversed a “no pricing in funnel” decision after prototyping)
Company fields: Full profile -> 2 fields
Agent setup: Configuration form -> One-click persona cards with gendered colors
Key blocker identified: Connector availability -> Missing contact emails (54% of all tasks)
Visual identity: Generic blue SaaS -> Warm brand palette, Outfit font, agents that feel like people
Every single dimension changed. Not because I was wrong on day 1 - my instincts were reasonable. But they were instincts. The brainstorm challenged scope. The research grounded targets in data. The planning forced every decision to justify itself.
What this means for how I work now
I run four commands in sequence for any significant product decision:
- Brainstorm - challenges the framing. “Who is this for? What are you assuming? Is that assumption backed by evidence?”
- Research - searches 110 transcripts and existing analysis for relevant customer data. Surfaces patterns and contradictions.
- Plan - forces every decision into a table with rationale. No hand-waving.
- Execute - builds the thing, with the plan as a checkpoint.
The whole cycle for the onboarding funnel took about 3 days of real work (spread across March). Without the AI pushing back, I could have shipped a generic signup form in a day - and learned nothing.
The slower path seems faster because it prevents to build the wrong thing.
Try this yourself
You don’t need 110 transcripts or custom skills to get this. The core pattern works with a blank Claude Code session:
- Before building, brainstorm the scope. Paste your brief and ask: “Challenge my assumptions. Who am I excluding? What am I over-engineering?” Don’t defend - listen.
- Ground your targets. Whatever metrics you’re planning around, paste the real data and ask: “Do these targets make sense given this data?” The gap between aspiration and reality is where the best decisions hide.
- Make every decision justify itself. Create a table: Decision | Choice | Rationale. If you can’t fill the rationale column with something specific, the decision isn’t ready.
- Build the smallest thing that answers the real question. Our funnel doesn’t convert users. It answers: “Can users perceive value without a demo call?” That’s a much cheaper question to answer than “Will users pay?”
The AI didn’t write the code. It changed what code to write or not.
Note: I strongly recommend you to install Superpowers - complete software development workflow for your coding agents, built on top of a set of composable “skills” and some initial instructions that make sure your agent uses them.
Part of a series on building an AI-powered operating system for a 3-person SaaS - see also The Day I Stopped Writing Prompts and Started Writing Commands and How I Automated Customer Research.
The funnel will be live in a few weeks. Real users will be able to hit it. I’ll share what happens.