82% Activation: The 10-Min Onboarding Claude Code Built

By Lazar Milicevic · Published July 3, 2026 · 8 min read

Most SaaS founders spend three months on the product and forty minutes on the onboarding. Then activation sits at 50%, week-one churn is brutal, and they blame the market. The uncomfortable part: the product works, the signup form works, payment works — users just vanish between account creation and the first real action. Here's the exact four-step flow I built with Claude Code for a live invoicing product. Time to first invoice: 8 minutes. Activation: 82%. Week-one churn: under 5%.

Define activation as one concrete action, not a checklist

Activation is the single action that means this user got value — not signup, not profile completed, not "tutorial finished." For an invoicing SaaS, activation is first invoice sent to a real recipient email. Everything upstream of that is design debt. Everything downstream is retention.

Most founders skip this because it feels like a semantic argument. It isn't. If you define activation as "profile completed," you'll optimize a wizard that produces zombie accounts. If you define it as "first invoice sent," the whole flow rearranges itself.

The prompt I gave Claude Code:

The activated state for this user is: first invoice sent
to a real recipient email (not a test address).

Design the shortest possible path from account creation
to that state. Assumptions:
- User has never used invoicing software before
- User will abandon if any single screen takes >90s
- Anything not legally required on the invoice gets defaulted

Before you write code, ask me anything ambiguous.

Claude Code didn't jump to UI. It came back with questions: which fields are legally required on an invoice for a US LLC vs sole prop, what data can we auto-fetch vs. must we ask, what does the user already know vs. what do we have to teach. That back-and-forth is where the design actually happens. If your prompt is "build me an onboarding," you get a generic five-tab settings page. If your prompt names the activation event, you get a wizard that deletes screens.

Four screens, one primary action each, resume on close

Screen count matters less than decisions per screen. Each screen gets one primary action, one dropdown or two inputs max, and a skip option only if it's legally allowed. Here's the exact layout:

No dashboard tour. No feature tooltips. No welcome video. If a user needs a tour to send their first invoice, the wizard is wrong.

The prompt I pasted into Claude Code:

Generate a four-step wizard component (Next.js + shadcn) where:
- Each step has ONE primary action button
- Skip option only if the underlying field is not legally required
- Progress indicator shows steps remaining (not %)
- Persist partial state on every field blur to Postgres
  (table: onboarding_state, keyed by user_id)
- If the user closes the tab and returns, resume at the last
  incomplete step with all prior values pre-filled
- No modals, no toasts, no confetti

Claude Code produced the components, the Zustand store, the blur-triggered mutation, and the resume logic in one pass. I pushed back on two things: it wanted to auto-advance on Enter (bad — one accidental keystroke skips a step), and it originally stored partial state in localStorage (bad — dies when a user opens on mobile after starting on desktop). Both were one-line fixes. It shipped that afternoon.

What made the wizard fast in practice

• Field-level validation only on blur, never on keystroke
• Government registry lookup fires on tax ID blur, non-blocking — user can proceed while it resolves
• "Send" on step 4 is optimistic: invoice queues immediately, PDF renders async

The measurement layer nobody builds (this is where 32 points came from)

This is the step that moved activation from 50% to 82%. Drop-off logging on every wizard screen. It's boring, it's the reason it works, and Claude Code will add it for free if you ask.

Every step fires timestamped events into a single table:

CREATE TABLE onboarding_events (
  id           bigserial PRIMARY KEY,
  user_id      uuid NOT NULL,
  event_type   text NOT NULL,  -- step_started, step_completed,
                                -- step_abandoned, field_focused,
                                -- field_blurred, validation_error
  step         int,
  field_name   text,
  error_msg    text,
  created_at   timestamptz DEFAULT now()
);
CREATE INDEX ON onboarding_events (user_id, created_at);
CREATE INDEX ON onboarding_events (event_type, created_at);

Then the funnel query:

WITH step_reach AS (
  SELECT step,
         COUNT(DISTINCT user_id) FILTER (
           WHERE event_type = 'step_started') AS started,
         COUNT(DISTINCT user_id) FILTER (
           WHERE event_type = 'step_completed') AS completed
  FROM onboarding_events
  WHERE created_at > now() - interval '30 days'
  GROUP BY step
)
SELECT step,
       started,
       completed,
       ROUND(100.0 * completed / NULLIF(started,0), 1) AS pct_pass
FROM step_reach
ORDER BY step;

The first time I ran that on the invoicing product, two screens screamed. One asked for billing address before the first invoice — 40% died there. Another asked users to pick an invoice template — 30% bounced. I deleted both. Activation climbed 11 points in a week.

The prompt to add the whole measurement layer was one line:

Add event logging to every wizard step (start, complete, abandon,
field-level focus/blur, validation errors). Write it to
onboarding_events. Give me a SQL funnel query for the last 30 days.

You cannot fix what you don't measure. Most founders ship the wizard, look at the aggregate activation number, feel bad, and start rebuilding features. The funnel query tells you the exact screen to kill.

The rescue job that pulls back 12% of dead signups

Even with a clean wizard, some users sign up, get interrupted by a phone call or a Slack ping, and never come back. The rescue job runs hourly and pulls roughly 12% of them back.

The rules are strict: it's not a marketing email, it's not a drip sequence, it's one plain-text message from a real reply-to address. If it looks like a template, it's ignored. If it looks like a human noticed, they reply.

# runs hourly via cron
import psycopg
from datetime import datetime, timedelta
from postmark import send_plain

STUCK_SQL = """
SELECT u.id, u.email, u.first_name
FROM users u
LEFT JOIN onboarding_events e
  ON e.user_id = u.id AND e.event_type = 'activated'
LEFT JOIN rescue_emails r
  ON r.user_id = u.id
WHERE u.created_at < now() - interval '24 hours'
  AND u.created_at > now() - interval '7 days'
  AND e.user_id IS NULL       -- never activated
  AND r.user_id IS NULL       -- never rescued
LIMIT 200;
"""

BODY = """Hey {name},

Noticed you started setting up your account yesterday but didn't
finish sending your first invoice. Anything blocking you? Happy
to help — just reply to this email.

- Lazar
"""

with psycopg.connect(DSN) as conn:
    for uid, email, name in conn.execute(STUCK_SQL):
        send_plain(
            to=email,
            reply_to="lazar@invoicingapp.com",
            subject="Stuck setting up?",
            body=BODY.format(name=name or "there"),
        )
        conn.execute(
            "INSERT INTO rescue_emails (user_id, sent_at) VALUES (%s, %s)",
            (uid, datetime.utcnow()),
        )

Three details matter. It runs from a real inbox that a human reads — replies actually get answered. It logs sends so nobody gets emailed twice. It only fires between 24 hours and 7 days after signup — earlier is pushy, later is dead lead.

The prompt to build it:

Write a scheduled job that identifies users who signed up but did
not reach the activated event within 24 hours. Send a plain-text
email from a reply-to address I read. Log the send so we never
send twice. Skip anyone older than 7 days.

What the full loop looks like when it's running

Once all four pieces ship, the activation number stops being a mystery. You know which screen kills users, you know which rescue copy pulls them back, and every time you change the flow the funnel query tells you whether you helped or hurt. Compare that to the default state most solo SaaS founders live in:

The whole thing — wizard, event logging, funnel dashboard, rescue job — took me two afternoons with Claude Code. Not because I'm fast, because the prompts above name the activation event explicitly and force the tool to design backward from it. If your prompt is "build onboarding," you'll get a generic settings page. If your prompt says "the activated state is X, design the shortest path to X, and log every step," you get a system.

If you're a solo founder and you haven't defined your activation event in one sentence yet, do that first. Everything else in this post is downstream of that one decision.

Why bizflowai.io helps with this

The onboarding-plus-measurement-plus-rescue loop above is the same shape we ship for clients on bizflowai.io — the wizard, the events table, the funnel query, and the stuck-user rescue job wired into whatever email provider the client already uses. If you already have a working SaaS but activation is stuck below 60%, this is usually a two-week engagement, not a rebuild. We instrument what you have, kill the screens the funnel indicts, and ship the rescue job.

Related reads on the same stack:

• What is Claude Code? It Refactored 1,847 Lines I Feared
• The Claude Code Intake Layer That Kills 60% of Bad Leads
• AI Agents Die Without Context. Here's Where.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.