Should I vibe code
No-code multi-step forms, calculators, landing flows, and analytics
An unauthenticated endpoint that sends an SMS is not a form. It is a toll-fraud faucet with your card behind it.
?
Their verdict, the Growth price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A multi-step form is not a long form with pagination, and the difference is where the trouble lives. Because drop-off analytics are the entire selling point, every step writes as the visitor completes it — which means the moment you build this properly you are holding partial answers from people who looked at step four and deliberately left. Then look at what Heyflow puts on its feature list: phone validation with SMS one-time codes, payment collection, WhatsApp replies. Each of those is an unauthenticated endpoint on a public page that spends real money when a stranger touches it, and the SMS one is not theoretical — sending a code to an attacker-chosen number is a known revenue-share fraud that arrives as a five-figure telecom invoice rather than as an error. Add conditional branching, whose bugs disqualify genuine leads without producing a single log line, and you have a build where nothing fails loudly and the people paying are somebody else's prospects.
What actually breaks
not "if". the specific failures.
- The SMS verification step, the week a script finds it — codes get pumped to premium-rate ranges the attacker earns a share of, and because each individual send succeeds there is no error anywhere until the carrier invoice arrives
- Partial submissions, which you now hold whether or not you meant to: name, phone and income band from someone who read step five and closed the tab, sitting in a table with no consent record and no expiry
- Conditional branching, silently — one wrong comparison sends the qualified applicant down the "not eligible" path, and a routing bug produces a polite dead end rather than a stack trace
- The calculator, whose arithmetic is now a quote you gave someone: a rounding rule or a stale rate table means the number on the screen is not the number you will honour
- Resume-by-link, if you add it, because a guessable token is a URL that hands a stranger's half-finished application to anyone who increments it
- The payment step, which drags card handling into a side project unless it is a redirect to a hosted checkout you did not write
- Field validation on phone numbers, addresses and dates, which is where every international visitor discovers your form assumes one country
The funnel has been live for two weeks and the phone-verification step works beautifully in testing. On a Saturday a script starts posting to the step-three endpoint with numbers in a range nobody in your market would ever use, four or five a second, each one triggering a real SMS through your provider. Every send returns success, so no alarm fires; the dashboard shows an encouraging spike in step-three starts and a strange collapse in completion rate, which reads like a UX problem. You notice on Monday, from the provider's billing page rather than from anything you built, and the amount is somewhere between a good laptop and a used car. The numbers belonged to a range that pays a revenue share to whoever terminates traffic on it, which is the entire point of the exercise, and your provider's position is that the messages were requested by your application and delivered as instructed.
Is that you?
the verdict is a default, not a law
- The flow posts straight into a hosted form service and your code never stores a submission
- There is no SMS, no payment and no outbound message anywhere in the funnel
- Nothing is written until the visitor reaches the final step and presses submit, and you have decided on purpose not to keep drop-off data
- It is your own project, your own traffic, and the worst case is that you lose your own leads
- Any step in the flow sends an SMS, a WhatsApp message or an email to a number or address the visitor just typed in
- You are storing step-by-step progress and cannot say what lawful basis covers the people who never finished
- The funnel qualifies people for finance, insurance, energy or health products, because the answers are far more sensitive than a contact form's
- It is a client's funnel, so the people in the table have no relationship with you at all
- There is no alert on completion rate and no second copy of a completed submission anywhere
If you build it anyway
the checklist, then the prompt that enforces it
- Treat any step that sends an SMS or a message as a money-spending endpoint, because it is. Rate-limit per IP and per number, cap sends per hour globally with a hard stop rather than a warning, block the country ranges you do not sell into, and put a challenge in front of it before launch. The correct alarm is on spend, not on errors.
- Decide deliberately whether partial answers are stored at all. If they are, keep them in a separate table with a short automatic expiry and a documented lawful basis, and never let them flow into the CRM or the follow-up sequence that completed submissions do.
- Test the branching as data, not by clicking. Write a table of input combinations and expected destination step, run it in CI, and treat an unreachable branch as a build failure — this is the failure with no error message.
- Never touch card details. If the flow takes money, redirect to a hosted checkout and store only the reference you get back.
- Make resume links unguessable and short-lived — a signed token with an expiry, not a sequential id — and confirm they expire by testing an old one.
- Write every completed submission to a second, independent sink you do not maintain, and alert when completions fall to zero on a live funnel. Absence of errors is not evidence of submissions.
- Put a real identity provider in front of the responses view, and log an id and an outcome rather than the body. A funnel table holds phone numbers, addresses and income bands, which is a very different object from a mailing list.
I am building a multi-step form funnel that collects answers step by step and
may verify a phone number. Two things here spend money or hurt people without
raising an error: an SMS endpoint anyone can hit, and partial data from people
who chose not to finish. Handle both before any design work.
1. If I ask for SMS or WhatsApp verification, build the abuse controls in the
same commit as the send: per-IP and per-number rate limits, a global hourly
cap with a hard stop, a country allowlist, and a challenge in front of the
endpoint. Tell me plainly that SMS pumping is revenue-share fraud and shows
up as a bill, never as an exception.
2. Alert on spend and on send volume, not on error rate. Every individual
fraudulent send succeeds.
3. Ask me whether partial answers should be stored at all. If yes, put them in
their own table with an automatic expiry, keep them out of the CRM and the
follow-up sequence, and record what wording the visitor was shown at the
step where their data was first written.
4. Express conditional routing as a data table of input combinations to
expected destination, and generate tests from it. An unreachable or
ambiguous branch fails the build. Do not hand-wire if-statements per step.
5. Never handle card details. Payments redirect to a hosted checkout; store the
reference only.
6. Resume links are signed, expiring tokens. Never sequential ids, and never a
raw submission id in a URL.
7. Write every completed submission to a second sink I do not control, and page
me when completions hit zero on a live funnel.
8. Put an established identity provider in front of any view that lists
responses. Log ids and outcomes, never field values.
9. Build export and single-record deletion before the second funnel exists.
10. Out of scope, and say so: A/B testing, funnel analytics, integrations. If I
want those plus verification, tell me Heyflow's Growth plan is $149 a month
month-to-month and that the abuse controls alone are worth it.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as a phone number, a payment or a client's name is involved. A hundred and forty-nine dollars a month is under a day of the ad spend a funnel like this usually sits behind, and what it buys is the abuse controls on the SMS endpoint, a branching engine that has been wrong in public before, and the compliance paperwork that comes with holding other people's answers. One weekend of pumped SMS costs more than the year does.
$149/mo is cheaper than your weekend.
The funnels are throwaway and the responses are not, so keep responses in your own store with the flow version, the step wording shown and the timestamp on every record, and export as CSV from day one. Keep partials physically separate from completions — they have different retention, different lawful basis and different value — so that deleting the partials is a table truncation rather than a query you have to reason about. If you migrate to a real platform later, the completions import cleanly and the partials are something you can honestly say you no longer hold.
Open-source conversational form builder with branching logic and result storage; the closest structural match.
Open-source surveys with response storage, partial-response handling and self-hosting.
Open-source form builder and collection backend, unrelated to Heyflow despite the name.
Questions
How is this different from the Leadpages verdict?
Leadpages is about one form on one page and the way a swallowed exception makes a weekend of leads vanish. Heyflow's shape is different in two ways that matter. The data arrives in pieces, so you hold answers from people who abandoned deliberately, and the flow can act — verify a number, take a payment, send a message — which turns a public page into an endpoint that spends money when a stranger touches it.
Is SMS pumping really something a side project needs to worry about?
It is one of the most reliably exploited endpoints on the internet, precisely because it is usually built by someone thinking about conversion rather than about abuse. The mechanics are dull: some number ranges pay a share of termination revenue to whoever sends traffic to them, so a script that can make your server send messages to those ranges is a slow money transfer from you. It never raises an exception, because every send works exactly as designed.
Why are partial answers a bigger deal than completed ones?
Because a completed submission comes with an act of consent you can point at, and a partial one comes with the opposite — the person saw the rest of the form and chose to stop. You still have their name, phone and whatever step three asked, stored because your drop-off funnel needed it. Keeping that indefinitely, or letting it reach a follow-up sequence, is the part that is genuinely hard to defend, and it is invisible in the UI.
Can I not just skip the analytics and store on submit?
Yes, and it is a good trade. You lose the drop-off chart, which is the feature that sells this category, and you delete an entire class of obligation. If the funnel is yours, the traffic is yours and nothing sends, that version is close to the SHIP IT case. The verdict is for the one people actually build, with verification, branching and a client's logo on it.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 6 — lawfulness of processing
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Everything else here is judged on what it stores. A calculator is judged on the number it told a stranger.
A form that emails a result to whatever address it is handed is an open relay with your logo on it.
Youform's free plan is unlimited. Cloning it buys you nothing but an open upload endpoint on your own bucket.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice