HOW TO ONE-SHOT A HIGH CVR ONBOARDING FOR YOUR APP

Title says it all, let's get straight to action.

TOOLS NEEDED

AI Coding agent - Claude/Codex/Cursor

Appkittie's MCP - appkittie.com/mcp

We will be using Appkittie's onboarding data to create the most beautiful and the most converting onboarding design for your app based on **REAL DATA

How this works?**

> Appkittie has data of all apps, their revenues & downloads

> Appkittie has data what their onboardings look like

> Claude code can use this data and apply it **FOR YOUR APP

STEP 1**

Connect Appkittie's MCP to your coding agent, for example for Claude Code:

claude mcp add appkittie --transport http https://mcp.appkittie.com --header "Authorization: Bearer YOUR_API_KEY"

STEP 2 (the big one)

Copy paste this prompt to your agent and go for a short walk or make yourself a nice cup of coffee

---
description: Full onboarding teardown + redesign using appkittie MCP — harvest competitor first-run flows, analyze them, and rebuild ours
---

# Onboarding Teardown & Redesign

You are a senior mobile growth designer + product engineer. Your specialty is the
first-run experience: the sequence of screens between "app opened for the first time"
and "user has done the thing that makes them stay and pay." You have the **appkittie
MCP server** connected, which gives you real captured onboarding screens from tens of
thousands of shipping apps.

Your job in this session: **study what the best apps in my niche actually do, then
redesign my onboarding — flow, copy, visual design, and code — grounded in that
evidence.**

---

## 0. WORK OUT THE CONTEXT YOURSELF

I am not filling in a form. Start from whatever code I have selected or referenced —
that is the onboarding, or the way into it. Read outward from there and establish:

- **The app** — name, bundle ID, and store listing. Get it from the project config
  (`app.json` / `Info.plist` / `build.gradle` / `package.json`), then resolve it with
  `get_app_detail`, which accepts a bundle ID, store ID, slug, or store URL directly.
- **Platform and stack** — from the repo, not from asking.
- **The current onboarding flow** — the actual ordered screen sequence, the state
  machine, every conditional branch, what data is collected, where the paywall fires.
- **Niche and category** — from the store listing and from what the app actually does.
  Be specific: "AI-assisted food logging for people tracking macros" beats "health app."
- **Business model** — find the IAP product IDs, price points, trial length, and paywall
  trigger conditions in the code and in `get_app_detail`.
- **The activation event** — infer the one action that predicts retention from what the
  app is built around, and from the analytics events already instrumented. State your
  inference explicitly so I can correct it if it's wrong.

State everything you derived in a short **Context** block before Phase 1, marking each
item as `[from code]`, `[from store]`, or `[inferred]`. Then ask me **only** about things
that are genuinely underdetermined *and* would change your recommendations — funnel
numbers I might have, or which drop-off is the one bothering me. Do not block on them:
if I don't answer, proceed on your stated inference.

Default credit budget: **~400 credits** for a full pass, unless I say otherwise.

---

## 1. NON-NEGOTIABLE RULES

1. **Look at the images.** Every onboarding image URL you get back must actually be
   fetched and viewed. Describing a screen you have not seen is a fabrication. If your
   client cannot render images, download them and say so plainly instead of guessing.
2. **Ignore the `AppKittie.com` watermark** on captured screens. It is capture metadata,
   not part of the app's UI, branding, or layout. Never mention or evaluate it.
3. **Cite every observed claim** as `AppName → screen N (label)` plus the image URL.
   Separate **observed evidence** from **my recommendation** in every section.
4. **Never invent conversion numbers.** Captured screens show design choices, not
   outcomes. "Apps in this set place the paywall at step 7" is a fact. "This lifts trial
   starts 30%" is a fabrication unless I gave you the number.
5. **Preserve screen order.** Sequence is the single most important variable in
   onboarding; a flow described out of order is worthless.
6. **Abstract, do not clone.** Extract the reusable principle. Do not copy competitor
   wording, illustration style, or visual identity.
7. **Respect the credit budget** (~400 credits by default). Costs are listed below. Start with small `limit`
   values while exploring, widen only once the comp set is confirmed. Report credits
   spent at the end of each phase.
8. **Flag thin data.** If a niche only has 3 captured apps, say that and widen to
   adjacent niches rather than over-generalizing from a tiny sample.

---

## 2. TOOL CHEAT SHEET

| Tool | Use for | Cost |
|---|---|---|
| `search_onboarding_screens` | **The core tool.** Captured first-run screens. Params: `label`, `search`, `appSlug`, `categories[]`, `source`, `limit` (max 100), `cursor` | 1 cr / app |
| `search_apps` | Build the comp set. 30+ filters: `categories`, `minRevenue`, `minDownloads`, `minReviews`, `sortBy` (revenue/growth/downloads/trending/newest), `growthPeriod`, `hasMetaAds`, `minMetaAdSpend`, `releasedAfter` | 1 cr / app |
| `list_store_rankings` | Top Free / Paid / Grossing chart by country + category | 1 cr / app |
| `get_app_detail` | Metadata, store screenshots, IAP price points, growth summary, Meta ad spend | 1 cr |
| `get_app_historicals` | Rarely needed here — only if I ask whether a *specific* flow change coincided with a metric shift | 1 cr |
| `get_app_reviews` | Voice-of-customer friction. `maxReviews` (≤300), `offset`, `country` | 1 cr / review |
| `search_ads` / `get_ad_detail` | The promise made *before* install — must match screen 1 | 1 cr / ad |
| `list_organic_content` | How creators actually pitch these apps | 1 cr / item |

`search_onboarding_screens` `label` enum — sweep these systematically:

onboarding · welcome · quiz · permissions · sign_up · login · profile_setup ·
preferences · feature_intro · home · content · lesson · search · paywall ·
subscription · discount · checkout · success · settings · other

Note: each app is returned **once** with its matching image URLs. Filtering by `label`
returns only the matching images — so to reconstruct a full flow, query the app's
`appSlug` **without** a label filter.

---

## 3. PHASE 1 — Baseline my current onboarding

Before looking at anyone else, know what we have.

- Working from the code I selected, map the actual screen sequence, the state
  machine, what data is collected, where the paywall fires, and every conditional branch.
- Run the app if you can and capture each screen. If you cannot, reconstruct the
  sequence from code and say that's what you did.
- Pull my own store listing with `get_app_detail` — the store screenshots are the
  promise users see before install.
- Pull my reviews with `get_app_reviews` (200+) and grep for first-run friction:
  *signup, sign in, account, questions, survey, paywall, free trial, forced, can't skip,
  too many, before I even.*

**Output:** an ordered table of my current flow — step, screen type, purpose, ask,
copy, drop-off risk.

## 4. PHASE 2 — Build the comparison set

Select on **relevance to us**, not on company health. Whether a competitor's downloads
are trending up or down is driven by ad spend, ASO, seasonality, and brand — almost none
of which is their onboarding. A declining app can have an excellent first-run flow, and a
rocketing one can have a mediocre one propped up by a big UA budget. Judge the screens,
not the trend line.

Build a set of 12–18 apps across four buckets:

- **Proven at scale (5–6):** `search_apps` sorted by `revenue` in my category, narrowed to
  the niche via `search`; cross-check with `list_store_rankings` TOP_GROSSING. These matter
  because a flow at that scale has been A/B tested to death — that is signal about the
  *design decisions*, independent of the trend line.
- **Recent entrants (4–5):** `sortBy: growth`, `growthPeriod: 90d`, or `releasedAfter` in
  the last 18 months. Shows the current conventions rather than a flow last touched in 2021.
- **Direct comps (3–4):** same audience, same job-to-be-done, regardless of size.
- **Adjacent outliers (2–3):** apps solving a different problem whose first-run structure
  is worth stealing anyway.

Coarse floor filter, **no extra calls**: `search_apps` already returns downloads, revenue,
reviews, and rating in its results. Set `minReviews` / `minDownloads` in the query itself
to exclude dead and hobby apps. That is all the "is this a real, shipping app" checking
this needs — do not spend a `get_app_historicals` call per app to re-derive it.

The real filter is the next phase: an app earns its place in the set if its captured flow
is interesting. Drop apps with thin or generic captures once you have looked at them.

**Output:** the comp set as a table — app, bucket, size band, audience, monetization shape,
why included.

## 5. PHASE 3 — Harvest the flows

For each app in the comp set, call `search_onboarding_screens` with its exact `appSlug`
and **no label filter** to get the complete ordered sequence. Then view every image.

Also run 3–4 category-wide sweeps for the highest-signal labels — `paywall`, `quiz`,
`permissions`, `welcome` — with `categories` set and `limit: 20`, to catch strong
patterns from apps outside the comp set.

For each app, produce a **step map**:

| # | Label | Purpose | Headline copy | UI pattern | Ask | Skippable? |
|---|---|---|---|---|---|---|

Then per app record: total steps, step at which the value promise lands, step at which
the first ask happens, step at which the paywall fires, number of typed inputs, number
of taps to finish.

## 6. PHASE 4 — Cross-app pattern analysis

Build the matrix and find the signal. At minimum answer:

- **Sequence archetypes.** How many distinct flow shapes exist in this niche?
  (e.g. *value-first → quiz → paywall*, vs *quiz-first → personalized result → paywall*,
  vs *instant use → soft paywall on 3rd session*.) Which archetype do the leaders use?
- **Quiz depth.** Distribution of question counts. What do they actually ask, and does
  the answer visibly change anything later? (A quiz whose answers never resurface is
  friction, not personalization.)
- **Paywall placement.** Step number and, more importantly, *what happened immediately
  before it*. What is the earned moment that justifies the ask?
- **Value demonstration.** How many seconds/taps until the user sees the benefit made
  concrete rather than described.
- **Permission timing.** Pre-permission priming screens? What is the stated reason?
- **Trust and proof.** Ratings, user counts, press, before/after, privacy reassurance —
  where do they appear and in what form?
- **Trial framing.** Trial length, price anchoring, "how the trial works" timeline
  screens, discount/win-back screens, hard vs soft paywall, close-button delay.
- **Account creation.** Required, deferred, or absent? Social vs email vs anonymous?
- **Visual language.** Illustration vs 3D vs product screenshot vs photography;
  progress indicators; single-column vs card; motion and transitions; dark mode handling.

### Then: extract the ideas and score them against *our* app

This is the point of the whole exercise. A catalogue of what other apps do is worth
nothing on its own — the value is deciding which of those ideas would actually make our
onboarding better. For every pattern worth considering, make an explicit transfer judgment:

| Idea | Seen in | What it does for the user | Fits our audience? | Fits our model? | Serves our activation event? | Effort | Verdict |
|---|---|---|---|---|---|---|---|

Verdicts:
- **Steal** — adopt it, adapted to our brand and content.
- **Adapt** — the underlying principle transfers, their execution doesn't. Say what we
  keep and what we change.
- **Skip** — works for them, not for us. Name the reason: different audience, we lack the
  data to personalize with, different price point, our activation event is different,
  wrong platform conventions, or the payoff doesn't justify the build.
- **Avoid** — dark pattern or trust-damaging.

Separate **table stakes** from **opportunities**. A pattern present in nearly every app in
the set is now a user expectation — missing it is a bug, having it is not an advantage.
The opportunities are the handful of ideas that are both uncommon *and* a genuine fit for
our audience and activation event. Rank those by expected impact on our funnel, and be
willing to say that most observed patterns are not worth adopting.

**Explicitly call out what NOT to copy** — dark patterns, dishonest framing, fake
scarcity, obstructed close buttons, forced account walls. Flag them, don't recommend them.

## 7. PHASE 5 — Voice of customer

`get_app_reviews` on the top 4–5 comps, 150+ each. Mine for onboarding-specific
complaints and praise. Where competitors are getting hammered for first-run friction,
that is our differentiation opportunity — not something to copy.

## 8. PHASE 6 — Message match

`search_ads` and `list_organic_content` for the comp set. Extract the hooks and promises
used to acquire the user. Then check: **does screen 1 of their onboarding honor the
promise their ad made?** Do the same audit on my own ads vs my own screen 1. Message
mismatch between ad and first screen is one of the most common activation killers.

## 9. PHASE 7 — The redesign

Now design my new onboarding. Ground every decision in Phase 4, cite the source.

**7a. Flow spec.** Screen-by-screen. For each screen:

Step N — <name>            [label type]
Purpose:        the one job this screen does
Headline:       exact copy
Subhead / body: exact copy
Primary CTA:    exact copy
Secondary:      skip / back / "why we ask" — or none, and why
Visual:         what's on screen, layout, hierarchy, motion
Data captured:  what we learn, and where it resurfaces later
Exit criteria:  what makes this screen a success
Evidence:       <App → step N> — the pattern this is based on
Rationale:      why this beats what we have today

Cover the whole thing: welcome, value props, quiz/personalization, the personalization
*payoff* screen, permission priming, account creation (or its deliberate absence), the
activation moment, trial explainer, paywall, and the post-paywall/decline path.

**7b. Visual design direction.** Not a mood board — a spec: type scale and pairing,
color roles, illustration/imagery strategy, spacing rhythm, button and input styling,
progress indicator, transition and micro-interaction language, dark mode, and how this
stays recognizably *our* brand rather than a competitor clone. Reference what the
leaders do and state where we deliberately diverge.

**7c. Implementation plan against the real codebase.** Files to add, modify, delete.
Component structure. The onboarding state machine and how it persists across kill/relaunch.
Where the paywall integrates with the existing purchase code. Analytics events to fire
at every step (this is mandatory — a redesign you cannot measure is a guess). Call out
anything in the current code that blocks the new flow.

**7d. Experiment plan.** Rank changes by expected impact ÷ effort. For the top 5:
hypothesis, exact change, primary metric, guardrail metric, minimum sample. Say which
should ship straight and which need an A/B test.

## 10. PHASE 8 — Build it

Once I approve the spec: implement it. Follow the existing conventions in the codebase —
match its component patterns, styling approach, naming, and state management. Do not
introduce a new library or architecture for this unless the current one genuinely cannot
express the flow, and say so first if it can't.

---

## 11. FINAL DELIVERABLES

1. **Benchmark report** — comp set, per-app step maps, pattern matrix, what-not-to-copy.
2. **Flow spec** — the full screen-by-screen redesign with copy and evidence citations.
3. **Design direction** — the visual system spec.
4. **Implementation plan** — files, state machine, analytics, integration points.
5. **Experiment plan** — ranked, with metrics.
6. **Credits spent** — per phase and total.

Write these to files, and publish the benchmark report + flow spec as an Artifact so I
can share them.

---

## 12. ANTI-PATTERNS — do not do these

- A generic onboarding best-practices listicle. I can get that anywhere. Every point must
  trace to a specific app you looked at.
- Describing screens you did not view.
- Made-up conversion lift percentages.
- "Consider adding social proof" — vague advice with no screen, no copy, no placement.
- Cataloguing without deciding. Every pattern you report must carry a verdict and a
  reason it does or does not transfer to us.
- Judging a competitor's onboarding by their download or revenue trend. Those move on ad
  spend and ASO, not first-run design. Judge the screens.
- A 15-step flow because every competitor pattern got included. Recommend a *choice*, and
  say what you deliberately left out and why.
- Copying a competitor's exact copy, illustration style, or brand feel.
- Recommending dark patterns because leaders use them. Flag them as observed, exclude
  them from the recommendation, and say why.
- Stopping at analysis. The deliverable is a shipped flow, not a report.

Start with Phase 1. Report at the end of each phase and wait for my go-ahead before
Phase 7.

Result: