Figure out what you're building before you build it
Web2app funnels almost always follow the same structure: ad → landing page → quiz → offer → paywall → payment. Building that is the easy part.
The hard part is what goes inside: what to ask in the quiz, what to offer, how to price it, how to lay out the plans on the paywall. You can figure all that out from scratch, or you can start from what already works.
The catch is that the web funnel market is opaque. An app can be making millions, and you won't see it anywhere directly. No hard numbers, but enough clues to tell who's doing what.
Where to find competitor funnels
Meta Ad Library
TikTok Creative Center
Trustpilot
Instagram
Market Radar- Ad libraries. Meta Ad Library and TikTok Creative Center — open a competitor's ad, click through, and you're in their live funnel. TikTok's library is the better one: filters by geo and industry, plus sorting by reach over the last 7 and 30 days.
- Trustpilot. Not obvious, but it works. If a competitor runs traffic in the US and Europe, some of their users leave reviews there, and the more traffic a product gets, the more reviews pile up. Search by category, sort by review count, and check the "similar companies" block for a ready-made list of players in your niche.
- Your own feed. Go through a few competitor funnels, then scroll Instagram — the algorithm starts serving you similar ads, and you'll collect more funnels in the same category.
- Ad spy tools — if you want volume and don't mind paying for it.
How to tell which funnels are working
You can't see anyone's revenue directly, so you can't tell what's working at a glance. Go by indirect signs:
Libraries show the launch date. An ad that’s been live for weeks or months wouldn’t be kept running at a loss — so the funnel is paying off.
Lots of variants on one offer means the product is investing in that funnel, and products invest in what pays.
Reviews don’t write themselves. A growing review count is an indirect sign of growing traffic.
That’s a proven pattern, not a coincidence.
It's also worth looking beyond your own niche into adjacent ones, even unexpected ones like astrology, religion, or health scanners. Mechanics from there often carry over to places no one's tried them yet.
What to look at inside
After a dozen funnels, you'll know what to note: offer structure, prices, trials, upsells. It gets more interesting once you've got a lot of them and can't hold the pattern in your head anymore — that's where AI comes in.
Drop everything you've collected into it and ask it to pull the pattern: what shows up most across the niche, and what almost no one is doing. The first is a proven base to start from. The second is open space to try something of your own.
Just don't count on a copy of someone's funnel working one-for-one. The details holding it together don't show from the outside, so take the structure and pricing as a starting point, not a template.
Set up your workspace
There are two ways to vibecode a funnel:
- All-in-one. A tool like Lovable or Bolt writes the funnel and stands up everything under it — database, hosting, payments. Fast, but your code and data live on their platform, and getting them out later is hard.
- Piece by piece. An agent writes the funnel, and you connect the infrastructure yourself from separate services. More steps, but you own the code, and you can swap or scale any part however you want.
This guide takes the second path as it's more flexible and shows you how everything fits together. If you're on an all-in-one tool, some of these steps are already handled behind the scenes, and we'll point that out as we go.
So, before you build, you'll set up a few accounts. Here's each one and what it's for.
| Service | What's it for | Examples |
|---|---|---|
| AI agent | Your developer. Writes and edits code, creates files, runs the project. You give it tasks in plain words — it does them. | C  Claude CodeC CursorCCodex |
| Code storage | Keeps the current version of your project and the edit history. If something breaks, you roll back. | G  GitHubG GitLabB Bitbucket |
| Hosting | Puts your site on the internet and updates it whenever the code changes. | V  VercelN NetlifyC Cloudflare Pages |
| Database | Stores users, quiz answers, and subscriptions — everything the funnel needs to remember. | S  SupabaseF FirebaseN Neon |
Set up all four now so you're not stopping to do it later. The AI handles the setup and wiring between them — we'll get to how as we go.
Build the funnel screens
Connect your code storage first — GitHub, say. Tell the agent to link the project to your repo and commit code as it works. From then on, every change is saved with history — if the agent breaks something, you roll back to a working version.
Now the funnel itself. You won't build it by hand — you'll build it in words, by giving tasks to the agent. So first, how to give those tasks.
How to talk to the agent
You're not coding. You're briefing someone — and what you get back depends on how clearly you brief. Four rules that separate a prompt that works from a prompt that returns junk.
Then you go screen by screen, applying these on each one.
The screens, in order
Build them in the order the user hits them. After each one, open it and check before moving on.
Set up personalization
You can click through the funnel, but the offer is the same for everyone as it doesn't read the quiz answers. In this step you connect the quiz to the offer: the user states a goal in the quiz and sees it in the offer.
One thing up front: the offer can stay a single offer. The product, tiers, and price can be the same for everyone. Only the wording around it changes, and that's what makes it read as personal. This runs on state — the funnel's temporary memory in the browser, for the length of one session.
Two moves, both through the agent.
1. The quiz saves answers to state.
When you build the quiz, add this to the task: save each answer you need to state under a clear name — goal as goal, level as level. Not every answer, just the ones you'll repeat in the offer.
goal: "5k", the answers are being saved.2. The offer branches on the answers.
When you build the offer, give the agent a rule for what to show based on the saved answer. Write it out as a ready rule, for example:
if goal = "5k" → headline "Your plan to run a 5K" if goal = "10k" → headline "Your plan to run a 10K" if goal = "marathon" → headline "Your plan to run a marathon"
Conditions and variants are yours to set. A default is required: no answer in state → the offer shows the default, not a blank.
Tell the agent directly: only text and images fall under the rule. Tiers, prices, product stay outside it, the same across every branch.
Check the offer
Run it with one answer — the offer shows the right variant. Run it with another — the variant changes. Skip the question — the offer shows the default instead of breaking. Tiers stay the same across all runs. If that holds, you're done.
Publish the funnel
Right now the funnel only exists on your machine. For traffic to reach it, it needs a public address. We publish now, before payments: payment systems send payment notifications to a real address, and you can't test that on a local funnel.
Your code is already in storage from the start of the build. Now connect hosting — the service that puts the funnel on the internet and updates it on every change. Vercel, Netlify, or Cloudflare Pages, for example. Tell the agent to connect the project to hosting — it'll link it to your repo and walk you through the steps.
One heads-up for later: as you connect services down the line (database, payments), each comes with access keys. They don't carry over to hosting on their own — you have to add them in its settings each time (environment variables). If a funnel opens to a blank white screen after you connect a service, this is almost always why: tell the agent to check the environment variables.
Connect the database
The database is permanent memory: users, their answers, and payment status all go here.
You need it for what comes next, not for its own sake. Without a database there's nowhere to record who paid, nothing to show analytics, and nothing to pass to the app. Everything after the offer relies on saved data.
Your database account — Supabase, let's say — is already set up from step one. Now you connect it to the funnel and tell it what to store.
Connect payments
The funnel reaches checkout, but the pay button doesn't do anything yet. In this step you connect a payment provider, and the funnel starts taking money.
A provider is the service that runs the payment: it charges the card and creates the subscription. The most common one is Stripe; there are others (Paddle, Adyen). You set up a separate account with it for taking payments.
For a start, that's enough — the payment goes through, the money comes in. But it's worth knowing up front that there are already risks here, and as you grow they turn into lost money — the bigger you scale, the bigger the losses.
Right now: everything rides on one provider. The same provider that runs your payments can limit or ban your account in a day — over a share of chargebacks or activity it finds suspicious. And then payments stop entirely: there's no backup route.
Link the user to their purchase and grant access
For a paying user to get access afterward, the funnel has to connect three things: who they are, what they bought, and how to let that specific person in. In web2app this usually runs on an identifier and an access token.
Identifier and token
- The identifier is the email. The one the user left in the funnel becomes their key: in the database, their quiz answers and — after payment — the purchase itself attach to it. Tell the agent to set up the logic: on a confirmed payment, create a database record of "email → what was bought → status." You already have part of this from the database step; here you're completing the link to the purchase.
- Access runs on a token, not a login. Tell the agent to add token generation to the funnel's code: on each payment, a short-lived token is created — a unique key tied to the user's record in the database (their email and what they bought). The token goes into an access link; the user follows it, the system finds their record by the token, and opens access to what they paid for. The agent writes this code once — after that it runs on its own with every payment.
How to deliver access
The token exists — now you deliver the access to the user. How exactly depends on how seamless you want it. Three ways, from simple to seamless:
For a start, the first option is enough. The second and third cut out taps when you want it more seamless.
Since you're collecting personal data, it's on you — the exact requirements depend on which countries you run traffic in (the EU is strictest, that's GDPR). But the basic minimum is worth setting up either way: tell the user what data you collect and why (a privacy policy), get consent before collecting, and make it possible to delete a user's data on request.
Don't have the agent write the policy text — it's a legal document, and invented text may not match reality. Take a ready one (privacy-policy generators, a template for your region, or a lawyer) and ask the agent to place it in the funnel and add a consent banner before data collection. The text is yours; the technical part — placement and banner — the agent handles on request.
Connect analytics
The funnel works and takes money. But you can't see what's happening inside it: how many people reach the paywall, where they drop off, which ads bring in payers. Without that you can't improve the funnel or run traffic with any sense — you'd be spending blind. So analytics go in before ads.
Analytics in web2app come in three layers, and they vary a lot in difficulty.
Shows the funnel step by step: how many reached the quiz, the paywall, payment, where they fell off. The service — PostHog, Mixpanel, Amplitude. Set up an account, tell the agent to connect it and send events at the key steps (quiz steps, paywall view, purchase). The key comes from the service's dashboard, and the agent will tell you where it goes.
For ads to optimize for payers instead of clicks, the platform needs events back — that someone bought, not just showed up. That's the pixel (Meta Pixel and similar). Grab the pixel ID from your ad account, tell the agent to add it and send the same key events. The agent does this fully — it's browser-side code.
The browser pixel loses some of the data — after the paywall, in mobile browsers, under ad blockers. By some estimates, a third to a half of conversions go missing this way. Tolerable at the start, but once you're spending real budget, ads optimize on a leaky signal. The fix is sending events from the server too, straight to the ad platform (CAPI on Meta).
Two paths, pick by how much accuracy you need:
event_id — the browser pixel and the server event have to carry the same event_id, or the platform counts one purchase twice and skews the optimization. This is the step people most often miss.You've gone the whole way, from an empty screen to a funnel that takes money and moves users into the product. Here's what's behind that:
Every screen, start to finish
Services piled up over the course of the guide:
| Layer | What for | Examples |
|---|---|---|
| AI agent | Writes and edits the funnel’s code | C Claude CodeCCursorCCodex |
| Code storage | Keeps the project and edit history | G GitHubGGitLabBBitbucket |
| Hosting | Puts the funnel on the internet | V VercelNNetlifyCCloudflare Pages |
| Database | Stores users, answers, payments | S SupabaseFFirebaseNNeon |
| Payments | Takes payments, runs subscriptions | S  StripeP PaddleA Adyen |
| Email service | Post-payment emails, magic links | R  ResendPPostmarkSSendGrid |
| Deep links | Carries the purchase into the mobile app | B Firebase |
| Analytics | Shows where people drop off | P  PostHogM MixpanelA |
That's the stack a working web2app funnel runs on. Every layer is one more thing to wire up, keep alive, and pay for — which is exactly the part FunnelFox takes off your hands.
Or skip the whole stack
FunnelFox gets you a converting funnel in a few clicks, plus flexible payment infrastructure built to grow, protect, and recover revenue.