DEV Community: Manveer

Mobile App, PWA or Just a Website? A 10-Point Scorecard

Manveer — Fri, 16 Oct 2026 17:50:53 +0000

A customer tells you, "You should have an app." A developer friend says, "Just make the website installable." An agency sends a proposal for iOS and Android. All three could be right, and all three could waste a year of your budget.

Whether you need a mobile app or a website for a small business comes down to how your customers behave, not to what looks impressive. And the choice isn't really two-way. There's a middle option most comparisons skip: a progressive web app (PWA), a website that can be installed on a phone's home screen, send notifications and work partly offline.

Below is a 10-question scorecard you can fill in over a coffee. Every platform claim was checked against Apple, Google, web.dev, MDN and WebKit documentation on 16 October 2026.

TL;DR

Many small businesses score into "website" or "PWA". A native or cross-platform app pays off when customers use you weekly or more, or when you need hardware and background features the web can't reliably reach.
iPhone is the deciding constraint for PWAs. Web push on iOS works only after the user adds your site to their Home Screen, so if you need time-critical alerts and your customers won't do that, a PWA isn't enough.
An app adds gatekeepers and ongoing admin. Apple charges 99 USD a year, Google Play has a one-time 25 USD fee, both review your releases, and Apple rejects apps that are little more than "a repackaged website".

Website, PWA or app: what's actually different

All three can look identical on a phone screen. The differences show up in four places: how people get it, how you reach them, what it can do on the device, and who has to approve your changes.

	Website	PWA	Native or cross-platform app
How users get it	Search, link, QR code	Same, plus "install" to home screen	App Store / Google Play download
Push on iPhone	No	Yes, only once added to Home Screen (iOS 16.4+)	Yes
Offline	No	Partial: cached pages and data	Full, if you build it
Device hardware	Camera, location (with permission)	Same as website	Full access, including Bluetooth and background tasks
App store listing	No	No (by default)	Yes
Release approval	None, you publish	None, you publish	Store review on every release
Platform fees	Hosting only	Hosting only	Apple 99 USD/year; Google 25 USD once

A few rows need context, because they're where most outdated advice goes wrong.

PWAs on iPhone are better than their reputation. Since iOS and iPadOS 16.4, a web app added to the Home Screen can ask for push notifications and set a badge count on its icon (WebKit). Since iOS 18.4, Declarative Web Push lets those web apps show notifications without a service worker (WebKit, Safari 18.4; Meet Declarative Web Push). And in iOS 26, "by default, every website added to the Home Screen opens as a web app", with or without a manifest file (WebKit, Safari 26).

The catch is the install step. On iPhone, notification permission comes after the user has added your site through the Share menu, and the request has to follow a direct tap, such as a "subscribe" button (WebKit). There's no automatic install prompt to lean on. Many customers will never find that menu without help.

Android is more forgiving. Chrome offers an install prompt when the site is served over HTTPS, has a manifest with a name, 192px and 512px icons, a start_url and a standalone-style display mode, and the user has tapped the page and spent at least 30 seconds on it (web.dev). Here's the minimum manifest:

{
  "name": "Riverside Yoga",
  "short_name": "Riverside",
  "start_url": "/",
  "display": "standalone",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

EU iPhones still get web apps. In early 2024 Apple said iOS 17.4 would drop Home Screen web apps in the EU, then reversed: "we will continue to offer the existing Home Screen web apps capability in the EU" (Apple's statement, via 9to5Mac). We found no later Apple notice changing that, and WebKit's iOS 26 web-app changes carry no regional exception.

Hardware is where the web still falls short. MDN marks Web Bluetooth as experimental and "not Baseline because it does not work in some of the most widely-used browsers" (MDN). The same applies to Background Sync, the API that lets a web app finish a task once the connection returns (MDN). If your idea depends on either, plan for an app.

The 10-point scorecard: mobile app or website for a small business?

Score each question 0, 1 or 2. Answer for your typical customer, not your most enthusiastic one. Higher scores point towards an app.

1. How often does a typical customer use you?
0 = a few times a year. 1 = about monthly. 2 = weekly or more.

2. Do customers need an account?
0 = no, they browse, call or enquire. 1 = it's useful (order history, saved details). 2 = it's the core of the relationship (memberships, loyalty, bookings).

3. How important are notifications?
0 = email or SMS is fine. 1 = push would help, and you can ask customers to add you to their Home Screen. 2 = time-critical alerts are central ("your order is ready", "your driver is outside") and you can't count on iPhone users installing a web app.

4. Does it need to work offline?
0 = no. 1 = showing cached information is enough (a menu, a schedule, last order). 2 = people must complete real work offline and sync later, like a field team logging jobs in a basement.

5. What device features do you need?
0 = none, or photo upload. 1 = camera or location while the screen is open. 2 = Bluetooth, NFC, background location or other deep device access.

6. Will the app do more than your website already does?
0 = it's mostly the same content. 1 = it adds some interactive features. 2 = it's a distinct tool your website can't be. This matters because Apple's guidelines say an app should "elevate it beyond a repackaged website", and that apps shouldn't primarily be "marketing materials, advertisements, web clippings" (App Review Guidelines 4.2).

7. Do your customers expect to find you in an app store?
0 = they find you on Google or Maps. 1 = some ask for an app. 2 = an app store listing is standard in your category and customers search there.

8. Can you fund upkeep after launch?
0 = no one is budgeted to maintain it. 1 = a few hours a month. 2 = a planned budget for updates, OS changes and store admin, including Apple's 99 USD per membership year (Apple) and Google's 25 USD one-time registration (Play Console Help).

9. Can you live with release gatekeepers?
0 = you need to ship fixes the same day without anyone's approval. 1 = a day or two of delay is fine. 2 = you can plan around store review. Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 (Apple). Google says some reviews take "up to seven days or longer in exceptional cases" (Play Console Help). New personal Play accounts created after 13 November 2023 also need "a minimum of 12 testers who have been opted in continuously for at least 14 days" before going to production (Play Console Help).

10. Do you have evidence customers will use it?
0 = it's a hunch. 1 = people already use your online booking or ordering repeatedly. 2 = you have repeat digital users and they're asking for an app.

What your score means

Score	Build	What that looks like
0–7	Website	A fast, mobile-friendly site with clear calls to action, online booking or enquiry forms, and good local SEO. Email and SMS handle reminders.
8–13	PWA	Your website plus an install option, push for customers who add it to their Home Screen, and cached pages for patchy signal. One codebase, no store review.
14–20	App	A cross-platform iOS and Android app (one codebase for both), usually alongside a website that still handles discovery and SEO.

Two override checks, because a total can hide a deal-breaker:

Scored 2 on Q4 or Q5? The web can't reliably deliver full offline work or deep hardware access today. Treat an app as the default and check the specific features before ruling it out.
Scored 0 on Q8 or Q9? You're not ready to run an app, whatever your total. Start with a PWA and revisit in six months.

The decision in one flow

If you'd rather not add up numbers, four yes/no questions in order get you to the same answer: stop at the first "yes" and build that.

Do you need Bluetooth, NFC, background tasks or full offline work? App.
Do customers use you weekly and need time-critical alerts on iPhone? App.
Do you have repeat, logged-in customers who'd benefit from install, push or offline caching? PWA.
None of the above? Website.

The order matters: hardware and offline limits are technical walls, while usage frequency is a judgment call.

A worked example (hypothetical)

Illustrative only. This is not a Banxal client and the numbers are made up for the exercise.

"Riverside Yoga" is an independent studio with about 400 members. The owner has been quoted for an iOS and Android app with class booking, a membership card and a waitlist. Here's how they score:

Question	Score	Reasoning
1. Frequency	2	Members come twice a week.
2. Accounts	2	Bookings and memberships are the business.
3. Notifications	1	"A spot opened on the waitlist" helps, but email and SMS already work.
4. Offline	0	Booking needs a connection anyway.
5. Device features	0	A QR check-in on the front-desk tablet covers it.
6. Beyond the website	1	Booking and a membership card are interactive, but not unique.
7. App store expectation	0	New members find the studio on Google Maps.
8. Upkeep budget	1	The owner can fund a few hours a month.
9. Release gatekeepers	1	Timetable changes are content, not releases, so a day's review delay is fine.
10. Evidence	1	Members book online weekly, but nobody has asked for an app.
Total	9	PWA

No override checks fire. The studio's next step is to make its existing booking site installable, add a "Get waitlist alerts" button that walks iPhone users through Add to Home Screen, and cache the timetable so it loads on patchy signal.

What would change the answer? A feature that needs Bluetooth, such as syncing heart-rate monitors, pushes Q5 to 2 and fires the override. Even then the PWA isn't wasted: its booking logic and backend carry over to an app.

Mistakes we see in this decision

Building an app to get "found". If Q7 scored 0, your customers find you through search and maps, so your website's SEO matters more than a store listing.
Wrapping the website in an app shell. It's a common shortcut into the stores, and exactly what Apple's minimum-functionality rule (4.2) is written to catch.
Planning for launch, not year two. Apps need updates when iOS and Android change, a renewed Apple membership and a store review for every fix. That's why Q8 exists.
Assuming PWAs can't do push on iPhone. That stopped being true with iOS 16.4. The real limit is the install step, so design it rather than waiting for a prompt.
Skipping the scope step. Whatever you build, write down what's out of scope first. Our MVP spec template starts there.

What it costs, without the made-up ranges

You'll find plenty of "an app costs $X to $Y" tables online. We won't add another, because cost depends on scope and your score doesn't change that. What the score does change is the shape of the cost:

Website and PWA: one codebase, hosting, no platform fees, no review queue.
App: Apple's 99 USD a year and Google's 25 USD one-off (Apple; Google), store listings to maintain, and release testing on two platforms. If you sell digital goods inside an iOS app, Apple's Small Business Program rate is 15% for developers under 1 million USD in annual proceeds (Apple). Check the current terms for your region before you build a pricing plan around it.

If you're tempted to start on a no-code builder, check what you can export first. Our FlutterFlow handoff guide compares export options across mobile builders. And if your "app" is really about automating bookings or reminders, the problem is sometimes solved behind the scenes, with no new screen for customers at all.

FAQ

Can a PWA be listed in the App Store or Google Play?
Not by default. A PWA is installed from the browser. Wrapping one in an app shell for the stores turns it into an app with an app's review process, and Apple may reject it under guideline 4.2 if it adds little beyond your website (Apple).

Do PWAs send push notifications on iPhone?
Yes, from iOS 16.4, once the user has added the web app to their Home Screen and tapped to allow notifications (WebKit).

Do PWAs still work on iPhones in the EU?
Yes. Apple reversed its plan to remove Home Screen web apps in the EU in March 2024 (9to5Mac), and we found no later change as of 16 October 2026.

If I start with a PWA, do I throw it away when I need an app?
Usually not. Your backend, database and business logic carry over. The screens get rebuilt for the app.

Next step

Score yourself honestly, then look at which questions you scored 2 on, because they tell you which features matter most. Banxal builds websites, web apps and cross-platform mobile apps. If your score sits on a band boundary, or an override fired and you want a second opinion before committing, get in touch and send us your ten answers.

What did you score, and did it match what you were planning to build? Tell us in the comments.

Originally published on banxal.com.

Hand Off a FlutterFlow App to a Developer: What to Prepare

Manveer — Mon, 12 Oct 2026 04:11:49 +0000

Your FlutterFlow app is on TestFlight, maybe live in the stores, and real people use it. You've found a developer to take it further, and their first message is: "Can you share the code and give me access?"

On mobile, that one request covers six or seven things: the FlutterFlow project, a GitHub repo, a Firebase or Supabase backend, Apple and Google developer accounts, push-notification keys and every third-party API the app calls. Hand off a FlutterFlow app to a developer without mapping those, and you'll either pay them to dig through your setup or give away something you can't get back.

This guide covers what you can export, what to share instead of transfer, and what to write down first.

TL;DR

FlutterFlow gives you real code. Most mobile no-code tools don't. Code download starts on the Basic plan and GitHub push on Growth. Adalo and Glide have no code export, and Bubble apps only run on Bubble.
Share access, keep ownership. Invite the developer to FlutterFlow, Firebase, GitHub, App Store Connect and Play Console under their own login. A FlutterFlow ownership transfer "can not be undone."
Check secrets and security rules before anyone forks the code. Private keys can end up in FlutterFlow's generated cloud function files, and one of its rule options is "Everyone".

Why mobile no-code handoffs are trickier than web ones

A web handoff is mostly code, database and domain. Mobile adds three complications.

The stores are separate accounts. Your listing, reviews and release history live in Apple's and Google's consoles, not in FlutterFlow.

Some keys only download once. For Apple's push notification key (the .p8 file), "the key is not saved in your developer account and you won't be able to download it again" (Apple Developer). If a past freelancer kept the only copy, you'll have to create a new key.

Old versions stay installed. Web users get your latest version on their next visit, but mobile users keep whatever build they installed until they update — so a careless database change can break the version people already have, even when the new build works fine.

Coming from a web builder? Our Lovable and Bolt handoff guide covers that side.

Export reality: what you can actually take with you

Before hiring, work out what you're handing over: either code a developer can open, or a project that only exists inside the builder. Here's what each builder's docs said when we checked on 12 October 2026.

FlutterFlow. Download Code gives you "the entire codebase of the app generated by FlutterFlow" (toolbar docs), and that code runs "as a normal Flutter app without requiring FlutterFlow" (FlutterFlow projects). Code Download is on Basic and up, and exporting FlutterFlow to GitHub (Push to GitHub) needs Growth and up (plan comparison). On 12 October 2026, Basic was listed at $39/month and Growth at $80/month for the first seat (pricing). Check the page again before you upgrade.
Adalo. Adalo staff wrote in August 2025 that "it is not possible to download the source code of the app at the moment" (Adalo forum) — an Adalo app's no-export lock-in. You can still export data as CSV, one collection at a time; details from the "many" side of a relationship are left out (Adalo help).
Glide. Glide apps "are Progressive Web Apps (PWAs), and publishing directly to the App Store or Google Play is not supported" (Glide help). On Glide's community forum, the answer to "can I export my source code?" is "there is no source code for your apps" (Glide community).
Bubble. Bubble is no longer web-only. It now publishes native apps built on React Native (Bubble native mobile). The code still stays with Bubble, though: "there's no way of exporting your application as code," and leaving means you "have to rebuild the application logic" (Bubble ownership).

On Adalo, Glide or Bubble, a developer either keeps building inside the tool or rebuilds from scratch. FlutterFlow adds a third option: export the code and carry on from there.

The 10-minute export self-check

Do this before your first call with a developer. You don't need to be technical.

FlutterFlow Developer Menu: can you click Download Code? If it's locked, you're on the free plan.
Download the ZIP and store it outside FlutterFlow as a dated snapshot.
Settings > Integrations > GitHub: is a repo connected, and whose account or organisation owns it?
Log into Firebase or Supabase yourself. If you can't, find out who can.
Log into App Store Connect and Play Console. Confirm that you, not a former freelancer, are Apple's Account Holder and Google's account owner.
Find the .p8 push key. Do you have it, or know who does?
List your custom code: every Custom Action, Widget and Function.

If steps 4 to 6 end in "I don't know", fix that before hiring. Those accounts are the hardest to recover.

How to hand off a FlutterFlow app to a developer: share access, don't transfer ownership

The developer gets their own login with scoped access, and you keep the owner seat. When the work ends, you remove one person and nothing else breaks.

Account	Give the developer	Watch out for
FlutterFlow	Editor access as a collaborator	Ownership transfer "can not be undone". To get it back, the new owner has to transfer it to you (collaboration docs)
Firebase	A role under Users and permissions, using "least privilege" (Firebase IAM)	FlutterFlow is already an Editor on your project (FlutterFlow + Firebase). Never share your Google login
Supabase	Developer role, which can't change project settings or API keys (Supabase access control)	Invites expire after 24 hours
GitHub	Collaborator on a repo you own	Check the repo isn't on a past freelancer's account
App Store Connect	Developer or App Manager role, limited to this app (Apple)	Individual memberships have a catch (below)
Play Console	App-level permissions with an access expiry date (Play Console Help)	They must sign in with the exact email you invited
Push keys, Stripe, AI APIs	Shared through a password manager vault	Rotate anything pasted into chat or email

Apple individual memberships. If you enrolled as an individual, Apple says users you add "only access App Store Connect" and aren't part of your team (Apple). Managing keys needs the Account Holder or Admin role (Apple keys), so expect to do those steps yourself.

Android's two keys. With Play App Signing, Google holds the app signing key and you hold the upload key. If the upload key is lost, you can request a reset (Play App Signing) — but know where it lives.

Document what you built

The developer can read your code, but not the reasoning behind it. This FlutterFlow app takeover checklist covers what to write down before they start.

[ ] Data model: each Firestore collection or Supabase table, what it holds, and which hold personal or payment data.
[ ] Custom code: each Custom Action, Widget and Function, what it does, and any packages added. In the export, these live in lib/custom_code/ (project structure).
[ ] Navigation: the main screens and the three flows that matter most (signup, core action, payment).
[ ] Auth and rules: your sign-in methods and the rule setting on every collection.
[ ] Environments: if you use Development Environments, which one is production and which database each points to (dev environments).
[ ] Outside FlutterFlow: Cloud Functions, webhooks, scheduled jobs and anything else configured by hand.
[ ] Live build number and known bugs.

FlutterFlow-specific traps

FlutterFlow's visual builder hides a few gotchas that surface only once code is exported or pushed to GitHub. Check each before a developer forks the project.

Secrets in generated cloud functions. "Make Private" sends an API call through Firebase Cloud Functions, so your tokens stay out of the app (API calls). But FlutterFlow warns that a private value used this way "may appear in the cloud function's code." It also says you "must review and manage these cloud function files" before exporting or pushing to GitHub (dev environments). Then check your Custom Actions for hardcoded keys; custom Dart code ships inside the app.

Unreviewed Firestore rules. Rule options run from "Everyone" (signed in or not) to "No One". FlutterFlow warns that defaults can be too open: a new collection everyone can read when only its creator should (Firestore rules). Your screens only show people their own data; the database still answers anyone who asks directly. Our post on backend validation explains why that gap is now easier for attackers to find.

The flutterflow branch gets overwritten. FlutterFlow "always pushes changes to a branch named flutterflow," and direct edits "will be overwritten by the next push" (GitHub docs). The documented pattern: the developer works on their own branch and merges FlutterFlow's updates in through pull requests. Agree on this on day one.

Decide where the visual editor stops. Code a developer edits in Git doesn't flow back into FlutterFlow's canvas. The VS Code extension syncs custom code files in both directions, but only on Growth and up (VS Code extension). Decide whether you'll keep building visually or hand the codebase over fully.

Generated code may need restructuring. Every page gets its own widget and model file, and utilities sit in lib/flutter_flow/ (project structure). The code works, but a developer may want to reorganise it before adding large features.

A worked example (hypothetical)

Illustrative only, not a Banxal client.

A founder runs a FlutterFlow booking app on the Basic plan, using Firebase, live in both stores. They've hired a Flutter developer to add payments and a tutor dashboard.

Self-check. Download Code works, but there's no GitHub connection (that needs Growth). The Apple membership is individual, and a freelancer created the .p8 key last year — nobody can find it now.
Code. The founder sends the ZIP; the developer sets up the repo in a GitHub organisation the founder owns.
Access. The developer gets a scoped Firebase role, an App Manager role in App Store Connect limited to this app, and a 90-day Play Console invite.
Keys. The founder revokes the lost key, creates a new one, and stores it in a shared vault.
Rules. The developer's first job: lock the bookings collection so tutors only see their own sessions.

It takes the founder an afternoon, and the developer starts on features right away.

When to rebuild instead

A handoff only makes sense if the foundations are worth keeping. On Adalo or Glide, getting code you own means a rebuild: your data comes with you, but the screens and logic don't. On FlutterFlow, the deciding question is the data model. If your collections still match how the business works, harden what you have; if they don't, every new feature will fight it. Our fix-or-rebuild self-test takes 30 minutes.

Choosing who takes over

Look for someone who reads Dart comfortably, has shipped Flutter apps through both stores, and has an opinion on FlutterFlow's generated code. Good candidates ask to be invited, not for your passwords, and bring up the flutterflow branch before you do. Our guide to vetting a developer has interview questions and red-flag answers that carry over to mobile.

FAQ

Can I export a FlutterFlow app and keep editing it in FlutterFlow?
Yes. FlutterFlow pushes to its flutterflow branch, and you merge that into your own branch. Changes the developer makes to generated code don't come back into the editor (GitHub docs).

Do I need the Growth plan to hand off?
No. Code Download is available on Basic, so you can send a ZIP. Push to GitHub and real-time collaboration need Growth or higher (plan comparison).

Should I give the developer my Apple or Google login?
No. Both stores let you add users with limited roles, and Google lets you set an expiry date. Shared logins mean you can't remove one person later.

I built on Adalo. Can I get the code?
Not today. Adalo staff confirmed in August 2025 that it isn't possible (Adalo forum). Export your collections as CSV and plan a move to code as a rebuild.

Next step

Most of a mobile handoff is admin, but some of it can't be undone. Banxal builds cross-platform iOS and Android apps, and our product maintenance and growth work covers apps other people started too. Want a second opinion on your export, access and security rules before you commit to a developer? Get in touch and tell us what you've built.

What worries you most about handing over a no-code app: the code, the store accounts or the data? Let us know in the comments.

Originally published on banxal.com.

Backend Validation: AI Will Find the Gaps Your UI Hides

Manveer — Sun, 11 Oct 2026 15:56:01 +0000

Your checkout page has a discount field: type a code, the price drops 10%; type a wrong one, the button greys out. You tested it and it works — what you probably didn't test is the backend validation behind it.

Now look at what the browser actually sends on "Pay": the cart, the code, and in a surprising number of apps, a total the page worked out for itself. If the server accepts that number as-is, the only thing stopping a 100% discount is JavaScript running in a browser the customer controls.

That's a hypothetical, not a client. But OWASP uses the same pattern in its own examples: a booking API that let hosts change a total_stay_price field they should never have been able to touch (OWASP API3).

Gaps like this used to stay hidden because finding them took a patient human with developer tools open — not anymore. Backend validation, enforcing every rule on the server and not just the page, is now the minimum for any live app, because AI has made hunting for these gaps cheap, fast and tireless. This post covers why, the gaps AI finds first, a checklist, and a 15-minute self-check for you and your developer.

TL;DR

Your frontend is a suggestion. Anyone can skip a browser-only rule by sending requests directly, and AI tools now do this at machine speed.
It's not only attackers. Browser agents, AI assistants and MCP tools use your app in ways your UI never planned for — treat every request as if it didn't come from your page.
Fix it on the server. Validate every input, check ownership on every record, accept only expected fields, recalculate prices and states yourself, rate-limit, and keep error messages boring.

Why AI changes the economics of finding loopholes

Probing an app was always possible — what's changed is the cost, and the evidence is piling up:

Exploiting known weaknesses. In a 2024 University of Illinois study, a GPT-4 agent exploited 87% of 15 real-world "one-day" vulnerabilities when given the public description — every other model and the open-source scanners tested managed 0% (Fang et al., 2024). Without the description, success fell to 7%: agents are far better at exploiting known classes of weakness than at finding new ones.
Finding what fuzzing missed. Google's Big Sleep agent found a SQLite bug that "remained undiscovered after 150 CPU-hours of fuzzing" — Google calls it "the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software" (Project Zero).
Doing it at scale, cheaply. In DARPA's AI Cyber Challenge final, the teams' systems analysed over 54 million lines of code, found 86% of the planted vulnerabilities, turned up 18 real ones nobody had planted, and cost "about $152" per task (DARPA).
Attackers are already using it. Anthropic reported a campaign where a threat actor used AI for "80-90% of the campaign", making "thousands of requests, often multiple per second", though the AI "occasionally hallucinated credentials" (Anthropic) — it isn't magic, but it doesn't get tired.

What does that mean for a normal web app? The gaps in your app aren't famous CVEs — they're the same documented API security weakness classes OWASP has tracked for years. An AI-assisted tester reads your JavaScript bundle for every route your frontend knows, checks every field in every API response your UI hides, and tries the combinations a human would get bored of: every ID, every optional parameter, every out-of-range value. None of that takes cleverness — just patience, which now costs almost nothing.

Even friendly AI uses your backend differently

There's a second shift that gets less attention in most server-side validation advice: AI acting for your real users.

Computer-use agents can "take screenshots, control the mouse, and type on the keyboard" (Anthropic docs), and the Model Context Protocol lets assistants like Claude or ChatGPT connect to tools and "perform tasks" (MCP). An honest customer's assistant might skip a step, retry a payment, enter a value your dropdown would never offer, or call your API through an integration someone else built — no harm meant, but it still breaks the "form only allows 1 to 10" assumption.

OWASP's own advice for protecting sensitive business flows includes "denying service to unexpected client devices (e.g headless browsers)" (OWASP API6). That helps, but as agents become an ordinary way to use the web, blocking anything that isn't "a human in Chrome" turns away more real traffic. The defence that lasts is making every request safe on its own merits — valid, authorised and within limits, whoever or whatever sent it. The same goes for your own AI features: OWASP's guidance for LLM apps is blunt — "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not" (OWASP LLM06).

What AI will poke at first: 8 common gaps

These are classes of weakness, not attack recipes. Each comes with the fix.

1. Missing ownership checks (BOLA / IDOR)

Your invoice page loads /api/invoices/1042. What happens if a logged-in user asks for 1043? OWASP ranks this #1 in its API Top 10, calling it "extremely common in API-based applications" with widespread prevalence (OWASP API1).
Fix: every function loading a record by a client-supplied ID must check the current user can access that record.

2. Hidden fields the server trusts (mass assignment)

Your profile form sends name and email, but the user record also has role, plan or isAdmin. If the server copies the whole request body into the record, those extra fields go through too — OWASP's cheat sheet uses exactly this isAdmin example (OWASP).
Fix: allowlist the fields each endpoint accepts — denylisting fails when next month's new column isn't on the list.

3. Responses that say too much

The UI shows a user's first name, but the API sends back the whole user object. OWASP's own example: a dating app's report feature that exposed a user's full name and recent location (OWASP API3).
Fix: return only the minimum each screen needs — OWASP advises avoiding generic serialisers such as to_json().

4. Prices, totals and quantities worked out in the browser

The discount example above. Watch too for negative quantities, zero-priced add-ons and overused discount codes.
Fix: the server calculates every amount itself, and checks discount codes and their usage limits.

5. Skipped steps and impossible state changes

An order jumps from pending straight to shipped, sign-up step 3 arrives without step 2, or a booking ends before it starts. OWASP calls this semantic validation — checking "whether the value makes sense for the operation", not just its format (OWASP Input Validation).
Fix: define the allowed transitions on the server, and reject everything else.

6. Inputs outside what the form allows

Your form caps a message at 500 characters, but the API accepts 5 MB. A pageSize of 100,000 returns your whole customer table. OWASP's advice: "define and enforce a maximum size of data on all incoming parameters and payloads" (OWASP API4).
Fix: check type, length, range and format for every field against an allowlist.

7. No limits on expensive or sensitive actions

Sign-up, one-time codes, password resets, booking slots, and AI features billed per call. OWASP's examples: buying up all stock to resell, or reserving every available slot (OWASP API6).
Fix: rate-limit each user and action, and "configure spending limits for all service providers/API integrations" or at least set billing alerts (OWASP API4).

8. Forgotten endpoints, weak admin checks and chatty errors

Old /v1 routes, debug endpoints, and admin routes that check login but not role. The OWASP Top 10 lists both broken function-level authorization and improper inventory management, noting that APIs "tend to expose more endpoints than traditional web applications" (OWASP API Top 10). Detailed error messages tell a prober exactly what to try next.
Fix: keep a list of every live endpoint, delete the ones you don't use, check roles on every admin action, and return generic errors while logging the details on the server.

The backend validation checklist

Work through these five groups with your developer — each line is a yes/no check, not a project.

Input

[ ] Every endpoint checks its request against a schema: types, lengths, ranges, formats.
[ ] Unknown fields are rejected, not silently ignored or saved.
[ ] Choices (country, plan, status) are checked against an allowlist.

Authorization

[ ] The user's identity comes from the session or token, never from the request body.
[ ] Every record lookup checks ownership or permission.
[ ] Admin and staff actions check the role on the server every time.
[ ] If your frontend talks directly to the database (common in Supabase apps), row-level security is on for every table — Supabase: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it" (Supabase).

Business rules

[ ] Prices, totals, discounts and credits are calculated on the server.
[ ] State changes follow an allowed list.
[ ] One-time things (codes, trials, referrals) are enforced as one-time in the database.

Limits

[ ] Rate limits on login, sign-up, codes, resets and anything that costs you money.
[ ] Maximum page sizes, upload sizes and request sizes.
[ ] Spending caps or alerts on third-party and AI APIs.

Output and errors

[ ] Responses include only the fields that screen needs.
[ ] Errors are generic to the user and detailed in your logs.
[ ] Unused endpoints are removed, not just hidden from the UI.

Here's the shape of it in code. This is a TypeScript example using the Zod validation library; every framework has an equivalent:

// Only these fields are accepted. Anything else (role, plan, isAdmin) is rejected.
const UpdateProfile = z.object({
  displayName: z.string().trim().min(1).max(80),
  timezone: z.enum(ALLOWED_TIMEZONES),
}).strict();

app.patch("/api/profile", requireUser, async (req, res) => {
  const parsed = UpdateProfile.safeParse(req.body);
  if (!parsed.success) return res.status(400).json({ error: "Invalid input" });

  // Who is being updated comes from the session, never from the request.
  await db.user.update({ where: { id: req.user.id }, data: parsed.data });
  res.status(204).end();
});

Keep your client-side checks — OWASP's position is that client-side validation "is bypassable; use it for immediate feedback" (OWASP Input Validation). It's for user experience, not security.

A 15-minute self-check for founders

You don't need to be technical for this. Only test your own app, using accounts you own.

The two-account test. Log in as user A, copy the URL of one of A's records (order, invoice or project). In a private window, log in as user B and paste it — you should get "not found" or "forbidden", never A's data.
Look at one response. In Chrome, open DevTools → Network, reload your profile page, and read the API response. Is there anything the screen doesn't show — other people's emails, internal flags, password fields?
Ask your developer five questions:
- "Where is the price calculated — browser or server?"
- "If a request included role: admin, what would happen?"
- "What stops 10,000 calls to sign-up, password reset or our AI feature?"
- "Do we have a list of every live endpoint, with old ones removed?"
- "If we use Supabase or Firebase, is row-level security on for every table?"

Confident, specific answers are a good sign; "the frontend handles that" means you have work to do. Built with Lovable, Bolt or similar? Our fix-or-rebuild self-test sizes the work, and our handoff guide covers rotating secrets before a developer starts. Hiring someone to fix it? These vetting questions show who actually understands this — and if you're adding a chatbot, the data-readiness checklist keeps private data out of its reach.

Want a second pair of eyes on your backend?

Banxal's product maintenance & growth work covers ongoing improvements to products we or others built — including apps whose rules live only in the frontend. Planning something new? Our web applications & SaaS builds include auth, payments and admin from day one. Tell us what your app does and how it's built and we'll tell you plainly where we'd look first.

FAQ

Is client-side validation useless, then?

No — but client-side validation is not enough on its own. It gives users instant feedback and saves pointless round trips; it just isn't security, since anyone who sends requests directly can skip it. Do both, and treat the server as the one that counts.

What's the difference between backend validation and authorization?

Validation asks "is this request well-formed and sensible?" Authorization asks "is this user allowed to do this to this record?" Most serious API problems in the OWASP Top 10 are authorization failures — a request can pass validation and still be dangerous.

Do I need a penetration test?

Work through the checklist first — paying a tester to find a missing ownership check you could catch yourself with two accounts in five minutes is expensive. Once the basics are in place, a professional test is worth it, especially if you handle payments, health data or other sensitive personal data.

Can I use AI to find these gaps before someone else does?

Yes — that's the other half of the story. DARPA says all seven AIxCC finalist systems "will be made available as open-source software" (DARPA), and AI code review can flag missing checks. Treat what it finds as leads to verify, not a clean bill of health.

Which rule in your app do you suspect lives only in the frontend: a price, a role, a limit? Tell us in the comments.

Originally published on banxal.com.

Chatbot Trained on Your Own Data? A Readiness Checklist

Manveer — Fri, 09 Oct 2026 07:05:50 +0000

A customer asks the chatbot on your website if you're open on the bank holiday Monday. It answers straight away and politely: yes, 9am to 5pm.

You're closed. The bot found its answer in an old opening-hours PDF that nobody remembered was still in the shared folder.

The AI did its job. The data was the problem. Most guides to building a chatbot trained on your own data stop at the upload button. This post covers what comes before it: how these chatbots work in plain English, a data-readiness checklist, a hypothetical worked example, and an honest test of whether you need one at all.

TL;DR

It isn't really "trained" on your data. Most of these chatbots use RAG (retrieval-augmented generation). When someone asks a question, the system looks up matching passages in your documents and answers from them. The AI model itself never changes.
Your documents decide the quality. If a file is outdated, contradicts another file or contains private details, the bot will repeat it to customers, and it will sound sure of itself.
Try the simple option first. If customers mostly ask the same short list of questions, an FAQ widget may be enough. If all your material is small, you can often give the AI the whole lot at once and skip RAG.

Do you actually need a RAG chatbot — or will an FAQ widget do?

Often you don't — there are three options, each more work to run well than the last.

1. An FAQ widget or help-centre search. You write the answers; the widget shows them. Nothing is generated, so nothing is made up. If most questions are repeats ("Do you deliver to…?", "What's your returns window?"), this is predictable and cheap.

2. An AI assistant that reads everything, every time. If your material is small, skip retrieval and give the AI all of it with each question. Anthropic: "If your knowledge base is smaller than 200,000 tokens (about 500 pages of material), you can just include the entire knowledge base in the prompt" (Anthropic). The trade-off is that you pay for reading it on every message. Our guide to AI agent cost per month shows how to work that out.

3. A RAG chatbot. Worth it when your material is too big for one prompt, changes often (stock, prices, policies), needs to be shown to some people and hidden from others, or answers must cite their source.

One more check: if answering means looking something up in a live system ("Where's my order?", "Is Tuesday at 3pm free?"), you're not dealing with a document problem. You need an integration or an agent. See Zapier, n8n or an AI agent.

How a chatbot trained on your own data actually works

A correction first: for most of these tools, "trained on your own data" isn't quite accurate. AWS describes RAG as having a model reference "an authoritative knowledge base outside of its training data sources before generating a response", "all without the need to retrain the model" (AWS). IBM draws the same line: "RAG lets an LLM query an external data source while fine-tuning trains an LLM on domain-specific data" (IBM).

Think of a capable new hire with a filing cabinet. They don't memorise it; when a question comes in, they pull the right folder and answer from that page. Updating is cheap (swap the page), and the cabinet is the weak point (a bad page means a bad answer).

Here's the pipeline behind that picture.

Documents. Gather your source material and clean it up. Pinecone's walkthrough describes cleaning the data before anything else happens (Pinecone).
Chunks. Long documents are split into short passages. OpenAI's hosted version, for example, splits files into 800-token pieces (a token is roughly a word or part of a word) with a 400-token overlap by default (OpenAI).
Embeddings. Each chunk is turned into a list of numbers, "a numerical representation of the data's meaning" (Pinecone), and stored in a vector database (AWS).
Retrieval. The customer's question is turned into numbers the same way and matched against the stored chunks. This is how "Can I bring my dog?" can find a passage titled "Pet policy" even though the words barely overlap. OpenAI notes that semantic search surfaces similar results "even when they match few or no keywords" (OpenAI).
Grounded answer. The question and the matching passages go to the AI model, which writes the answer from them. Both AWS and IBM point out that RAG systems can cite their sources, so you and your customers can check them.

Two things that trip up real chatbots

Chunks lose their context. Anthropic's example is a passage that reads, on its own, "The company's revenue grew by 3% over the previous quarter." Which company? Which quarter? (Anthropic). The small-business version: a price-list line saying "£60, includes follow-up" whose heading got split off. Anthropic's fix was to add context to each chunk before storing it and pair meaning-based search with keyword search. In their tests that cut failed retrievals by 49% (67% with an extra re-ranking step). You can do a version of this yourself in how you write your documents.

Exact codes need exact matching. Search by meaning can miss precise identifiers. Anthropic's example is "Error code TS-999", which keyword matching finds reliably. If customers ask about SKUs, part numbers or plan names, add keyword search too.

The data-readiness checklist

This decides whether your chatbot gives good answers, whichever tool you choose. Go through it before you upload anything.

1. Source-of-truth content

[ ] List every place answers live today: website pages, help docs, PDFs, policy documents, saved email replies, and the things only staff know.
[ ] Choose one current version for each topic: prices, hours, returns, delivery, service descriptions.
[ ] Exclude old versions, drafts and "v2-final-FINAL" duplicates. If two documents disagree, the bot may quote either one.

2. Freshness and ownership

[ ] Give every document an owner and a "last reviewed" date.
[ ] Decide how changes reach the bot. AWS describes keeping RAG data current by updating the documents and their embeddings "through automated real-time processes or periodic batch processing" (AWS). Either works; having no process doesn't. As IBM puts it, "Knowledge bases must be continually updated" (IBM).
[ ] Flag anything seasonal or time-limited, such as holiday hours, promotions and price changes. These cause the most embarrassing wrong answers.

3. Sensitive data and permissions

[ ] Assume that anything in the knowledge base can be shown to anyone who can talk to the bot, unless your setup deliberately filters it.
[ ] Remove customer records, staff details, internal pricing or margins, contracts, and anything with passwords or account numbers.
[ ] If you want a staff-only assistant as well as a public one, keep them in separate collections, or use a setup that filters by tags. OpenAI's version, for example, lets you tag files and filter searches "by user, region, date" and similar (OpenAI).
[ ] Protect the vector database as carefully as the original files. IBM warns that if it's breached, "attackers can reverse the vector embedding process and access the original data" (IBM).

4. FAQ gap-check

[ ] Pull together a few weeks of real customer questions from your inbox, chat logs, contact form and phone notes.
[ ] For each question, find the document that answers it. Mark the ones with no answer.
[ ] Write the missing answers. A bot can't retrieve what doesn't exist, and without a source AWS notes models can present "false information when it does not have the answer" (AWS).
[ ] Decide what the bot does when it doesn't know: offer a contact form, phone number or hand-off to a person.

5. Format cleanup

[ ] Use real text. Common formats like PDF, Word, plain text and Markdown are widely supported (OpenAI). Quick test: if you can't select the text in a PDF, assume the chatbot can't read it either.
[ ] Make each section make sense on its own. Name the service, product or location in the passage, not just in a heading three pages up. This is the do-it-yourself version of the context fix above.
[ ] Turn complicated tables into plain sentences where you can ("Hygiene appointment at the Northside clinic: 30 minutes, £X").
[ ] Write product codes, plan names and policy names the same way every time.

Worked example (hypothetical): a small dental practice

An illustrative scenario, not a client. Imagine a small dental practice with two clinics. The front desk spends much of the day answering the same calls about prices, opening hours, accepted insurers and how to prepare for a procedure. The owner wants "a chatbot trained on our website and leaflets."

The gate. Questions repeat, but answers depend on the clinic and the treatment, so a fixed FAQ feels stiff. Booking questions need the live diary, so they route to the existing booking link instead. Everything else (website pages, a price list, a dozen leaflets) is well under 500 pages, so no RAG yet — an assistant with the whole knowledge base in the prompt will do for version one.

The checklist turns up the real work:

Source of truth: there are two price lists in the shared drive, last year's and this year's. The old one is removed.
Freshness: the practice manager becomes the owner of the price list and opening hours, and reviews them each quarter and before every bank holiday.
Sensitive data: the staff handbook was in the "upload" folder. It contains staff mobile numbers and internal procedures, so it comes out.
Gap-check: going through a few weeks of phone notes shows "Do you take my insurance?" is one of the most common questions, and no document answers it. The team writes a one-page insurer list.
Format: the aftercare leaflets turn out to be scanned images. They're retyped as text, and each one names the procedure in its first line.

None of this needed an engineer, though skipping it would have produced wrong answers. If the practice later adds clinics or a staff-only assistant, the cleaned-up content moves straight into a RAG setup.

Platform vs. custom build: what changes once your data is ready

Once your data is ready, picking the tool is the easier decision — the work above carries over whichever you choose.

	No-code chatbot platform	Hosted retrieval API (e.g. OpenAI file search)	Custom RAG build
Setup	Upload files, paste a snippet on your site	A developer connects files to a model	Designed around your systems
Chunking & search	Fixed by the vendor	Adjustable. OpenAI allows 100–4,096-token chunks (OpenAI)	Fully controllable, incl. keyword + meaning-based search
Permissions	Usually one bot = one set of files	Tag-based filtering	Per-user access tied to your logins
Live data	Rarely	With extra development	Yes, via integrations
Best for	Public FAQ-style content	Small teams with a developer	Multiple sources, staff + customer bots, citations

Running costs: storing the documents is usually the small part. OpenAI's vector storage, for instance, is free up to 1 GB and $0.10 per GB per day after that (OpenAI). The model's cost per conversation usually matters more, which is what our cost-per-month guide works through.

A platform is probably enough for public content and simple questions. You've outgrown it when you need per-user answers, live system data, reliable exact-code lookups, or a way to test answer quality before customers see it.

Want a second opinion before you build?

Worked through the checklist and still unsure whether you need an FAQ widget, a simple assistant or a full RAG chatbot? Our AI integration & agents team builds chatbots and assistants on your own data, and we'll tell you plainly if a simpler option will do. Tell us what your customers keep asking.

FAQ

Can I train ChatGPT on my own business data?

You usually don't need to. Most "own data" chatbots use RAG: they look up your documents at question time and leave the model unchanged. Fine-tuning, which does change the model, is "computationally expensive and resource-intensive" (IBM) and rarely a small business's first step.

How much data do I need for a chatbot trained on my own data?

Less than you'd think, but it must be current, consistent and cover the questions people actually ask. Under about 500 pages, Anthropic suggests skipping retrieval and putting it all in the prompt (Anthropic).

Is it safe to put customer data into an AI chatbot?

Keep customer and staff data out of a public bot's knowledge base entirely. Anything in it can end up shown to anyone. Give staff assistants a separate, access-controlled collection.

How do I stop the chatbot making things up?

Fill the gaps, remove outdated and conflicting documents, have the bot cite sources, and hand over to a person when it can't find an answer. RAG gives the model real material to work from. It can't fix missing or wrong material.

What's the one question your customers ask that you'd most like a chatbot to answer, and is it actually written down anywhere yet? Tell us in the comments.

If you've tried a chatbot on your own documents, what tripped it up first: outdated files, missing answers, or something else? Tell us in the comments.

Originally published on banxal.com.

Automation Failing Silently in Zapier, n8n or Make?

Manveer — Thu, 08 Oct 2026 17:41:51 +0000

It's Monday morning. Your sales lead asks why there have been no new website leads since Thursday. The form has dozens of submissions. The Zap, scenario or workflow that copies them into the CRM is on, and its last run says "success" — but the CRM has nothing new since Thursday.

Nobody got an email. Nothing turned red. Four days of leads sat in a form inbox nobody reads.

That's an automation failing silently — in Zapier, n8n or Make alike. Below: why "successful" runs can still be broken, the four failure modes behind it, free alert settings for each platform (checked against the official docs), and a monthly health check that needs no monitoring tool.

TL;DR

Native alerts only catch errors. A run that "succeeds" with blank data, or a trigger that stops firing, won't alert you on Zapier, n8n or Make.
Turn on the free alerts today anyway. Zapier notification settings, an n8n error workflow and Make's email preferences catch expired logins and API errors. Each takes about five minutes.
Add one "is anything arriving?" check. A daily scheduled count of new records, with an alert when it hits zero, catches the failures alerts can't see.

Why "it ran successfully" doesn't mean it worked

Automation platforms judge success at the step level: did each API call return without an error? They don't know what should have happened in your business.

So "success" can mean any of these:

A CRM contact was created, but the email field was blank because the form tool renamed email to email_address.
A filter step stopped every run because a dropdown value changed from "Yes" to "yes". The filter did its job, so nothing was flagged.
The trigger hasn't fired since Thursday. There's no failed run, because there's no run at all.

The first two look normal in your run history. The third doesn't show up anywhere. Built-in alerts catch loud failures and miss quiet ones.

Four ways an automation ends up failing silently in Zapier, n8n or Make

Most silent failures trace back to one of four causes: an expired login, an upstream field change, an empty-data edge case, or a rate limit. Here's what each looks like and whether native alerts catch it.

1. Expired or revoked logins (auth tokens)

Every app connection is a stored login, and logins expire. Zapier says connections "expire after a given time, such as after a year" (Zapier). Google's refresh tokens stop working after six months unused, or when a password change touches Gmail-scoped tokens. Self-hosted n8n with a Google Cloud app left in "Testing" status expires tokens in 7 days (Google).

Common trigger: the person who connected the account leaves, and their login gets disabled.

Is it loud? Usually, as an authentication error — but an authentication failure (AccountValidationError) can't be caught by a Make error handler, and after your set number of consecutive errors Make disables the scenario's scheduling (Make), and Zapier can turn off a Zap that "errored too many times" (Zapier). If that error email went to an unwatched inbox, you're left with a switched-off automation and no further warning.

2. API and field changes

Apps rename fields, change dropdown options and retire endpoints. Sometimes that throws an error; often the field mapping just comes through empty. Zapier's troubleshooting guide flags a related trap: "Dropdown menus understand IDs, not text" (Zapier) — a label change upstream can quietly break a mapping.

Is it loud? Only if the receiving app rejects the data. Make calls this a DataError or BundleValidationError when it does (Make). If the receiving app accepts a blank value, the run succeeds.

3. Empty-data edge cases

A search step finds no matching customer and the workflow carries on with nothing. A webhook arrives with an empty body. A spreadsheet trigger watches a tab someone renamed. None of these is technically an error.

Is it loud? Almost never. Platform settings alone won't catch it.

4. Rate limits and timeouts

Send a burst of records (a bulk import, a busy sale day) and the receiving API starts refusing requests. Make labels these RateLimitError (HTTP 429) and ModuleTimeoutError for runs past its 40–60 second limit (Make); n8n's "Timeout Workflow" setting cancels a run after a set time (n8n).

Is it loud? Partly. The failed run errors, but the damage is often a half-finished run: the invoice was created, the welcome email wasn't. Retries can also create duplicates.

Failure mode	What you typically see	Does the native alert fire?	How you catch it
Expired login	Auth errors, then the automation switched off	Usually, if alerts are on and someone reads them	Native alerts + monthly connection review
API / field change	"Successful" runs with blank or wrong fields	Sometimes	Spot-check real output records
Empty data	Runs that do nothing, or no runs at all	Rarely	Daily "is anything arriving?" count
Rate limit / timeout	Some runs fail, some half-finish	Partly	Native alerts + check for duplicates

The 10-minute self-check

Do this now for the automations that would hurt most if they stopped — usually lead capture, payments or invoicing, and customer onboarding.

Open the run history (Zapier: Zap history; n8n: executions; Make: scenario history). Is the last run as recent as it should be? Leads arriving daily but the last run four days ago means you've found a silent failure.
Open three recent output records in the destination app (CRM contact, invoice, row). Is every field you care about filled in?
Look for runs that aren't plain success or plain error. Zapier marks some as "Holding" for "account-related issues, such as high task usage, an account connection issue" (Zapier); Make records warnings and incomplete executions.
Check your connections. Note which ones belong to people who've left or are about to.
Find out where alerts go today. Whose inbox? Do they still work here? Do they read it?
Write down an owner for each critical automation: one name who gets the alert and fixes it.

If step 1 or 2 surprised you, set up the alerts below before doing anything else.

Turn on free native alerts today: Zapier, n8n, Make

All three platforms include error alerts at no extra cost. Here's where to find each, per the vendors' own docs.

Zapier

Go to Settings → Notifications → My notification settings. Under Default notification, click Edit and choose Immediately (one email per error) or Immediately, then hourly summary. Avoid Never (Zapier).
For your critical Zaps, add a rule under Custom notifications → + Add notification, pick the Zaps or folders, set the frequency and click Add to notifications. Custom notifications aren't available during a trial.
Know the gap: Zapier says errors handled by an error handler don't send notification emails. If you've built error handling into a Zap, make that handler send its own alert.
Optional: route errors to Slack. Zapier's Zapier Manager app has a New Zap Error trigger with ready-made templates that post each error to a Slack channel (Zapier). If you do this, also set "Send me an email when a Zapier Manager Zap fails" to Always under Notifications → Email subscriptions (Zapier) — so you hear about it if the alert Zap itself breaks.

n8n

n8n's documented way to hear about failures is an error workflow — a separate workflow that runs when another one fails (n8n).

Create a new workflow with the Error Trigger node first, then add a Slack, email or Teams node that sends the message. Name and save it (for example "Error Handler").
In each workflow you want covered, open the three dots icon in the upper-right, select Settings, choose your handler in the Error Workflow dropdown and Save (n8n). This is per workflow, so new workflows aren't covered until you set it.
In the same settings, make sure Save failed production executions is set to save, so you have something to debug.
Put the useful fields in the alert. The Error Trigger receives the workflow name, the error message, the last node that ran and, if executions are saved, a link to it (n8n).

Bonus: the Stop And Error node lets you "cause executions to fail under certain conditions" (n8n) — use it for empty-data cases, so a search that returns nothing fails on purpose and triggers the error workflow instead of running on.

Make

Go to Profile → Email preferences → Organizations and check Errors, Warnings and Deactivation for each organization (by default you only get errors and deactivations). Make emails immediately, then a digest after 5 minutes for errors and 15 for warnings (Make).
In each important scenario, click the gear icon in the Scenario Builder to open scenario settings (Make):
- Turn on Store incomplete executions, so failed runs are saved "so the data isn't lost".
- Review how many consecutive errors Make allows before deactivating. Note that "if a scenario starts with an instant trigger, the setting is ignored and the scenario is deactivated immediately once the first error has occurred."
- Think before enabling Discard data if storage is full. It keeps the scenario running, but it throws away the failed data.

When native alerts aren't enough

Native alerts only answer one question: "did a step throw an error?" They can't tell you:

The trigger stopped firing. No run, no error, no alert.
The output is wrong. Blank fields and skipped records look like success.
Volume dropped. Twelve leads a day falling to two is a business problem, not a technical error.
Nobody is reading the alerts. An inbox that gets 40 error digests a week gets ignored.

The fix needs no new tool: a heartbeat check. Build one small scheduled automation that runs every morning, counts yesterday's new records in the destination (CRM contacts, invoices, rows), and alerts if the count is zero or far below normal — to the same channel as your error alerts, and on a different connection where possible, so one expired login can't silence both.

Dedicated monitoring tools exist, and some teams need them. You've probably outgrown DIY when:

You're running enough business-critical automations, or they're spread across enough platforms, that no one person can keep track of them from memory.
Automations move money, sync two systems both ways, or touch customer data you're accountable for.
Nobody owns them, or the person who built them has left.

At that point the fix is usually less "add monitoring" and more "rebuild the fragile parts properly": safe retries, validation before writing, and logs a human can read. Our guide on choosing between Zapier, n8n or an AI agent covers when a workflow has outgrown its platform.

A simple monthly automation health-check

Put a 30-minute recurring meeting on the calendar with the automation owner and work through this list.

Is it running?

[ ] Last run time for each critical automation matches what you'd expect.
[ ] No automations switched off by the platform (Zapier and Make both do this after errors).
[ ] Task, credit or execution usage isn't close to your plan limit. Make stops scheduling immediately when you run out of operations (Make).

Is it right?

[ ] Five random output records checked against their source, every field.
[ ] No duplicates from retried runs.
[ ] Incomplete executions (Make) or failed executions (n8n) reviewed and cleared.

Is someone watching?

[ ] Error alerts and the heartbeat check still go to a person who works here and reads them.
[ ] Every connection belongs to a current team member or a shared service account.
[ ] Each critical automation has a named owner and a one-line note on what it does.

Want a second pair of eyes on your automations?

If this check turned up more than you'd like, or there's a Zapier, n8n or Make setup nobody wants to touch, that's what our automation & integrations team does: audit what you have, add alerts and heartbeat checks, rebuild the fragile parts, and look after it ongoing if you want. Tell us what you're running and we'll tell you honestly whether it needs more than the free settings above.

FAQ

Why did my Zapier automation stop working with no notification?

The three usual causes: error notifications are set to Never or go to an unread inbox; Zapier turned the Zap off after repeated errors; or the trigger stopped firing, so there was no error to report. Check Zap history and Settings → Notifications first.

How do I get alerted when an n8n workflow fails?

Create an error workflow that starts with the Error Trigger node and sends a Slack message or email. Then select it under Error Workflow in each workflow's settings. It doesn't apply automatically to new workflows (n8n).

Does Make tell me when a scenario fails?

Yes. By default Make emails you about errors and about scenarios it deactivates. Warnings are off unless you enable them under Profile → Email preferences (Make). Scenarios with instant triggers are deactivated on the first error, so keep deactivation emails on.

How do I monitor business automations without a monitoring tool?

Combine the free native error alerts with a daily heartbeat automation that counts yesterday's new records and alerts on zero, plus the monthly checklist above. For most small teams, that covers loud and quiet failures.

Has an automation of yours ever failed quietly for days? What gave it away in the end? Tell us in the comments.

Originally published on banxal.com.

How to Vet a Developer to Fix Your Vibe-Coded App

Manveer — Tue, 06 Oct 2026 15:18:46 +0000

You post a short job description: "Lovable app, Supabase backend, payments are flaky, need someone to fix it." Three replies come in by evening. One says it's a two-day job. One says the whole thing should be rebuilt. One asks you to send your Supabase login so they can "take a quick look".

Any of the three might be right. You can't tell from the replies, and that's the real problem when you hire a developer to fix a vibe-coded app. The skills that matter here are mostly invisible from a portfolio.

This guide gives you the questions to ask on the call, what a good answer sounds like, which answers end the conversation, and a scorecard you can fill in as you go.

TL;DR

Vet for diagnosis, not just coding. The developer's first job is to find problems the AI builder hid, such as missing database access rules, leaked keys and payments that don't match your app. Ask them how they'd find those.
Access and ownership answers matter as much as technical ones. A good hire asks to be invited to your accounts, not given your passwords, and puts code ownership in writing.
Score every answer Green, Yellow or Red. A Red on security, access or ownership ends the conversation, however good the rest of the call was.

Why vetting for a vibe-coded app is different

Vetting is different here because the job isn't proving someone can build an app — it's proving they can find what's wrong with one they didn't build, and that looks fine on the surface. A normal hiring process asks "can this person build things?" For a vibe-coded app, the better question is "can this person find what's wrong with something they didn't build, and that nobody fully understands?"

The problems are predictable. Veracode tested code from over 100 large language models and found that AI-generated code introduced risky security flaws in 45% of tests (Veracode). In the case behind CVE-2025-48757, a researcher scanned 1,645 Lovable-built apps and found 170 (10.3%) with exposed data across 303 endpoints, including names, phone numbers, payment details and live API keys (bleek.dev). The cause was missing or misconfigured Supabase Row Level Security (RLS).

These problems don't show up in the demo. The app looks fine until a stranger reads someone else's records. So the developer you hire has to be good at looking under the surface, and the interview should test exactly that.

If you haven't yet worked out how bad things are, run our 30-minute fix-or-rebuild self-test first. Your scores make every question below sharper, because you'll know which answers matter most for your app.

Where founders look for help

There are three common routes. None of them is automatically better. Each one fails in its own way.

	Freelance marketplace	Independent freelancer	Small agency or studio
Best for	One clearly scoped fix	Ongoing work with one trusted person	Audit, fixes and maintenance across several areas
Who does the work	Usually the person on the profile	The person you talk to	A team. Ask who exactly
Accountability	The platform's dispute process	Your contract and their reputation	Your contract, plus more than one person who knows your code
Watch for	Quotes given before anyone has seen the code	One point of failure if they disappear	A senior person on the sales call and a junior on the code

A practical rule: the less clearly you can describe the problem, the more you need someone who will diagnose before they quote. Marketplaces work well when you can write the fix as one line. If you can't, start with an audit, whichever route you choose.

The interview: 8 questions to ask before you hire a developer to fix a vibe-coded app

Ask these on a call, not by email, so you hear how people think rather than what they can look up. You don't need to judge the technical detail yourself. Listen for specifics, for questions asked back, and for whether they're willing to say "I'd need to look first".

1. "Will you look at the code before you quote?"

Good answer: "Yes. I'd like read access to the repo and database first, then I'll give you a written list of what I found and what I'd fix first." Some charge for this review, some don't. Either is fine, as long as the review happens before the main quote.

Red flag: a firm price, or "you need a rebuild", based on a screen share or your description. Nobody can size a fix to code they haven't read.

2. "How would you check that one user can't see another user's data?"

This is the question behind most vibe-coded app incidents. Supabase's docs say a table in an exposed schema without RLS "is readable and writable by any role with a grant on it" (Supabase RLS).

Good answer: they'd check that RLS is turned on for every table and read each policy against your business rules. They'd also test it by signing in as two different users and trying to open each other's records. Bonus points if they mention Supabase's Security Advisor, which flags issues such as "RLS disabled in public" (Supabase Advisors), and say that it isn't enough on its own.

Red flag: "Lovable's security scan is green, so you're fine." In the CVE-2025-48757 write-up, Superblocks notes the scanner "only flagged the presence of RLS, not whether it worked" (Superblocks).

3. "Where should our secret keys live, and what would you do if one has leaked?"

Good answer: secret keys stay on the server, never in the browser. Lovable's own guidance says secrets in frontend code "should be considered compromised" (Lovable). On a leak, a good developer finds and fixes the cause first, then creates a new key, updates everything, and only then deletes the old one. That's the order Supabase recommends (Supabase API keys).

Red flag: "Just send me the service_role key on WhatsApp." Supabase says a secret key "bypasses every Row Level Security policy you have" (same page). Anyone who handles it casually will handle your users' data the same way.

4. "How do you make sure payments and the app agree?"

Good answer: the app learns about payments from Stripe webhooks rather than from the browser reaching a "success" page. Each webhook's signature is checked, and repeated events are ignored. Stripe warns that without verification "an attacker could send fake webhook events" to grant access, and that endpoints "might occasionally receive the same event more than once" (Stripe webhooks).

Red flag: "The success page upgrades the account, that's standard." It isn't standard. It breaks the moment someone closes the tab.

5. "Who will actually work on the code, and how do you use AI tools?"

Good answer: a named person, plus a clear way of working. Using AI coding tools is normal. What matters is that a human reviews and tests what the tools produce before it ships.

Red flag: "Our team" with no names, or work that gets passed on to people you'll never meet. The opposite is also a warning sign: someone who says AI-built code is worthless and will be thrown away, before they've even read yours.

6. "What access do you need from me, and in whose account?"

Good answer: "Invite me as a collaborator to your GitHub repo, your Supabase org and your Stripe account." Invites keep you in control. On a personal GitHub repo, for example, a collaborator can push code but can't delete the repository or transfer ownership (GitHub permissions). Our handoff prep guide lists everything to get ready before the developer starts.

Red flag: asking for your passwords, or asking you to move the repo into their account "to make things easier".

7. "Who owns the code you write?"

Good answer: "You do. It's in the contract as an assignment of rights." This matters more than most founders realise. Under US law, commissioned work only counts as "work made for hire" if it falls into one of nine listed categories and both sides sign a written agreement saying so (US Copyright Office, Circular 30). Software isn't named on that list, so a clear written assignment is the safer route. The rules differ by country. Ask a lawyer about your own contract.

Red flag: "We'll sort the paperwork later," or a contract that only grants you a licence to use the code.

8. "What does 'done' look like?"

Good answer: a list you could check off. That means written findings, each fix linked to an item on that list, tests or a repeatable check for the risky fixes, and short handover notes so the next person isn't starting from zero. If you have a written spec, share it. A one-page MVP spec gives a good developer something concrete to scope against.

Red flag: "We'll just fix bugs as they come up." That's fine for ongoing maintenance after the first round of fixes. It doesn't work as the first round.

Red flags that end the conversation on their own

Some answers make the rest of the call irrelevant. Stop if the developer:

Asks for your passwords or wants you to send secret keys over chat or email.
Quotes a rebuild without reading your code or database.
Wants the repo, database or domain moved into their account.
Brushes off exposed data as "fine for an MVP" when you have real users.
Can't explain in plain English how they'd stop one user seeing another's data.
Won't put code ownership in writing.

Score the call: Green, Yellow, Red

Use this while you're on the call. It uses the same scoring as the Pass/Warn/Fail checks in our fix-or-rebuild self-test: Green (0), Yellow (1), Red (2).

Green: a specific answer, and they ask you something useful back.
Yellow: the right idea, but vague, or "I'd have to check" without saying how they'd check.
Red: the red-flag answer, or a confident answer that contradicts the official docs.

Score	Also true	What to do
0–3	No Red anywhere	Strong candidate. Check two references, then agree the audit scope.
4–7	No Red on Q2, Q3, Q6 or Q7	Ask them to answer the Yellow questions in writing before you sign.
8–16	—	Keep looking.
Any	A Red on Q2, Q3, Q6 or Q7	Keep looking, whatever the total.

These thresholds are our rule of thumb, not an industry standard. The rule that matters is the last row. A charming developer who wants your Supabase password is still a bad hire.

A hypothetical example. Back to the three replies from the opening. Developer A (the "two-day job") answers Q1 with a firm price and Q2 with "the scanner's fine". That's two Reds, one of them on a deal-breaker. Developer B (the "rebuild") hasn't read the code either, so Q1 is Red, but they're solid on Q2 to Q4 and they offer an IP assignment. They score 4–7, so ask why they think a rebuild is needed before trusting the verdict. Developer C (the "send me your login") fails Q6 straight away. None of them is an obvious yes. That's a normal result, and it's the reason to talk to a fourth.

FAQ

Should I pay for a code audit before hiring a developer to fix my app?
Usually, yes. A short, scoped review turns a guess into a list of findings, and you keep the list even if you hire someone else. Our self-test lets you do the first pass for free.

Can the developer who fixes my app keep using Lovable or Bolt?
Yes, if you agree a way of working first. The usual risk is you and the developer changing the same code at the same time, through the builder and through GitHub. Our handoff guide covers how each builder syncs.

Is a freelancer or an agency better for fixing a vibe-coded app?
Neither is better by default. It depends on how clearly you can describe the problem. A freelancer suits one well-defined fix. A team suits a broader audit followed by ongoing work. Score both with the same eight questions.

Next step

If you'd like a second opinion on your app, or want to see how we'd answer these eight questions, Banxal builds and hardens web apps and SaaS products and looks after them afterwards. We'll review the code before we suggest anything, and we'll tell you plainly if a rebuild isn't needed. Tell us about your app.

Which of these questions has caught someone out on one of your hiring calls? Or which one do you wish you'd asked? Tell us in the comments.

Originally published on banxal.com.

MVP Spec Template for Non-Technical Founders: Cut First

Manveer — Sun, 04 Oct 2026 10:38:49 +0000

Most founders write their first spec the same way: a long list of everything the product will do. A developer reads it, quotes for all of it, and three weeks in someone asks, "Can we also add…?"

This MVP spec template for non-technical founders reverses the order. You write down what you're not building before you describe what you are. It takes five minutes, fits on one page, and gives your developer the one thing most specs leave out: a clear edge.

TL;DR

Write the out-of-scope list first. For each cut feature, note the manual workaround and the point at which you'll reconsider it. That's what keeps cut features from creeping back in.
Scope in one core workflow and name its screens. If a developer can't count the screens, they can't estimate the work.
Send one page, not twenty. Include the template below, a few sketches and your constraints. A good developer's first questions will be about the edges, not the features.

Why specs get scope creep

Specs get scope creep because the out-of-scope decision gets made too late, after the feature list is already written — and the problem is common well beyond first-time founders. In PMI's 2018 Pulse of the Profession survey, 52% of projects completed in the previous 12 months had scope creep or uncontrolled changes to scope, up from 43% five years earlier (PMI, 2018). The same report names "erroneous requirements gathering" as one of the causes behind uncontrolled scope.

For an MVP, every added feature delays the day real users tell you whether the idea works. In CB Insights' 2026 analysis of startup shutdowns, poor product-market fit was cited in 43% of cases where a failure reason could be identified (CB Insights).

Most MVP spec templates do have an "out of scope" section. The trouble is that it comes near the end, after the features. By then you've already decided what's in, and the section just collects leftovers.

Start with what you're not building

Write your out-of-scope list before you write your feature list — deciding what to cut first is what keeps the cuts from being reversed later. Starting with exclusions isn't a new idea: Basecamp's Shape Up method lists "no-gos" as one of the five parts of every project pitch: "functionality or use cases we intentionally aren't covering" (Shape Up, ch. 6). The MoSCoW prioritisation method has a "Won't Have this time" category for the same reason. Writing those items down helps "avoid them being informally reintroduced at a later date" (Agile Business Consortium).

"Informally reintroduced" is how MVP scope creep usually happens. Nobody decides to double the scope. Someone says on a call that self-rescheduling would be nice, and since nobody wrote down why it was cut, nobody can say no.

The fix is to give every cut feature three things:

The feature, named specifically ("customer self-rescheduling", not "account features").
The manual workaround you'll use instead ("customer texts us; we move it by hand").
The revisit trigger: the evidence that would put it back on the table ("more than 10 reschedule texts a week").

A cut with a workaround and a trigger reads as a decision. A cut without them reads as an oversight, and people will try to fix oversights.

The 5-minute out-of-scope exercise

Set a timer and grab paper or a blank doc.

Minutes 0–2: Dump everything. List every feature you've imagined, including the ones you assume are obvious: login with Google, an admin dashboard, notifications, a mobile app, reports, payments, reviews, multiple languages. Don't filter yet.

Minutes 2–3: Apply the one-question test. For each item, ask: Can my first 10 real customers get the core job done without this? If yes, move it to the out-of-scope column. Be strict. Most items will move.

Minutes 3–4: Write the workaround. For each cut item, write how you'll handle it by hand for now: email, a spreadsheet, a phone call, a Stripe payment link, or you personally. If you can't think of any workaround, that's a signal the item may belong in scope.

Minutes 4–5: Write the trigger. For each cut item, write what would make you reconsider it. Make it observable ("three customers ask for it unprompted"), not a feeling ("when we're bigger").

Two things never go on the cut list: basic security (proper login, protected data, backups) and anything the law requires where you operate. Those aren't features. They're the cost of having real users.

Now scope what's in (one core workflow, named screens)

Once your out-of-scope list is set, the in-scope section only needs two things: one core workflow written as numbered steps, and a list of named screens. With the edges set, the in-scope section can stay short.

One core workflow, written as numbered steps. This is the one journey a user takes to get the value you're promising. Write it from the user's point of view, one action per line. If you have two workflows, pick the one that tests your riskiest assumption and move the other to out-of-scope.

A list of named screens. "Booking page", "Confirmation email", "Owner's day view". Developers estimate in screens, data and integrations, so a named list turns "a booking app" into something they can count. If a step in your workflow doesn't map to a screen, an email or a manual action, you've found a gap.

The Agile Business Consortium recommends keeping "Must Have" work to no more than 60% of total effort, leaving room for surprises (Agile Business Consortium). In practice: if your must-haves feel like the whole budget, keep cutting.

The one-page MVP spec template for non-technical founders (copy this)

Call it a spec, an MVP scope document or a requirements template; the job is the same. Fill it in top to bottom. Section 2 comes before section 4 on purpose.

# [Product name] — MVP spec (v1, [date])

## 1. Who and why (3 lines max)
- User: [one specific type of person or business]
- Problem: [what they do today, and why it's painful]
- This MVP proves: [the one assumption we're testing]

## 2. Not in this version
| Feature cut | Manual workaround for now | Revisit when… |
|---|---|---|
| | | |

## 3. Core workflow (numbered, user's point of view)
1.
2.
3.

## 4. Screens and emails
- [Screen name]: [what the user sees or does here]

## 5. Data we store
- [e.g. Customer: name, phone, email]

## 6. Integrations (max 1–2)
- [e.g. Stripe for deposits, Google Calendar sync]

## 7. Constraints
- Must use / must avoid: [tools, accounts you already have]
- Why the date matters: [launch event, funding, season, or "no hard date"]
- Rules we must follow: [privacy, industry rules, where users are]

## 8. Done means
- [The one measurable thing that tells us v1 worked]

## 9. Swap rule
New ideas during the build go to section 2. To add one, we remove
something of equal or larger size that hasn't been started.

The swap rule comes from Jesse Fewell, quoted in the same PMI report: "You can replace any not-started deliverable with anything of equal or lesser cost" (PMI, 2018). Writing it into the spec means you agree on the rule before you're attached to any new idea.

Worked example: a booking app for a grooming salon

This is a hypothetical example to show the template in use. It isn't a client project.

Imagine a two-groomer dog salon where customers book by phone and Instagram DM, and the owner misses calls while grooming.

1. Who and why

User: existing salon customers booking a groom
Problem: booking means calling during working hours or waiting for a DM reply
This MVP proves: customers will book online if it's quick, which frees up the owner's time

2. Not in this version

Feature cut	Manual workaround for now	Revisit when…
Native iOS/Android app	Mobile-friendly web page	Most bookings come from repeat customers on phones and they ask for an app
Customer self-rescheduling	Customer replies to the confirmation email; owner moves it	More than 10 reschedule requests a week
Online payment	Pay in salon as today	No-shows cost more than a deposit system would
SMS reminders	Email reminder only	No-show rate stays high after email reminders
Customer accounts and logins	Book with name, phone, email	Repeat customers complain about re-entering details
Reports and analytics	Owner exports bookings to a spreadsheet monthly	Owner needs this more than once a month
Second location	Not needed	A second location is signed

3. Core workflow

Customer opens the booking link from Instagram or Google.
Picks a service (bath, full groom, nail trim) and dog size.
Sees available slots for the next 14 days and picks one.
Enters name, phone, email, dog's name and breed.
Gets a confirmation email, and a reminder 24 hours before.
Owner sees the booking in a day view and can cancel or block time.

4. Screens and emails: service picker, slot picker, details form, confirmation page, confirmation email, reminder email, owner login, owner day view, block-time form. That's nine items a developer can estimate.

5–8. Data: customer, dog, booking, service, groomer. Integrations: an email-sending service. Constraint: the owner already uses Google Workspace. Done means: 30% of bookings made online within the first two months.

The out-of-scope table, not the feature list, is what keeps this build small. "No online payment" and "no accounts" remove whole chunks of work, and the workarounds show they were decisions.

What to send a developer (and what a good first call sounds like)

Send four things:

The one-page spec above.
Sketches. Phone photos of paper drawings are fine. If you've built a clickable prototype in Lovable or Bolt, send that too. Our guide to handing off a Lovable or Bolt app to a developer covers what to prepare.
Two or three reference products. "Booking like Calendly, but showing services first."
Accounts you already have: domain, email provider, payment account, brand files.

On the first call, listen to the questions. A good developer asks about the edges: "What if two people book the same slot?" "Do groomers have different hours on different days?" They may push back on a cut, suggest cutting more, and say which parts they're unsure about. Be wary of anyone who agrees to everything and quotes without asking a question. That estimate is a guess.

Already have a half-built product? Read fix or rebuild a vibe-coded app before writing the spec.

Want a second pair of eyes on your spec?

Banxal builds web applications and MVPs for founders. If you've filled in the template, send it to us. We'll read it and tell you what's missing, what's unclear, and what we'd move to "not in this version".

FAQ

How long should an MVP spec be?

One page for the parts above, plus sketches. If it runs past two pages, you're probably describing more than one workflow, or writing implementation details your developer should decide. Length doesn't make a spec clear. Clear edges do.

What if I don't know what to cut?

Run the one-question test on every feature: can your first 10 customers get the core job done without it? If you still can't decide, ask what the manual workaround would cost you each week. If it's an hour of your time, cut it. If it means losing customers, keep it.

Do I need wireframes before talking to a developer?

No. Named screens and rough sketches are enough for a useful first conversation and a sensible estimate. Detailed wireframes help later, but making them before scope is settled often means designing screens you'll cut.

What's the hardest feature you've had to move to "not in this version"? Tell us in the comments. We'd especially like to hear from anyone whose revisit trigger actually fired.

Originally published on banxal.com.

AI Agent Cost per Month: The Token Maths, Worked Out

Manveer — Sat, 03 Oct 2026 07:53:15 +0000

A four-message support chat with a tool-using AI agent can send the model more than 45,000 input tokens. That's about twelve times Anthropic's own estimate of roughly 3,700 tokens for a support conversation (Anthropic pricing). Nothing is broken: each turn simply resends everything that came before it.

That's why most guides to AI agent cost per month give you wide ranges instead of a number. This one gives you a formula, worked through a small-business example and priced against six current models using each provider's official pricing page.

TL;DR

Separate build cost from run cost. This post covers only run cost: model tokens, tools, storage, monitoring and the people who handle escalations.
Conversation history is the biggest cost. In our example, resending earlier turns accounts for 44% of the model bill. Because each turn resends all the earlier ones, history cost grows with the square of the number of turns.
3,000 support conversations a month cost $17 to $342 in model fees across six current models, before caching. Turning on prompt caching cut the Sonnet 5.5 bill by 59%.

Why "AI agent cost" articles never add up

Most articles on this topic mix two different bills:

Build cost: design, integration, prompt work, testing. You pay it once, and it's usually much larger.
Run cost: what you pay every month after launch. It grows with usage and never goes away.

One top-ranking article says plainly that "the published per-token price tells you almost nothing about what an agent will actually spend" (CloudZero). True, but behaviour can be measured — and anything measurable belongs in a formula.

Not sure you need an agent at all? Read Zapier, n8n or an AI agent — often one AI step inside a normal workflow is enough.

The real cost drivers

Four things set your monthly bill:

Conversations per month. This is your volume.
Model calls per conversation. A tool-using agent usually makes at least two calls per customer message: one to pick a tool, one to write the answer.
Input tokens per call. Every call resends the system prompt, the tool definitions, the conversation so far and any retrieved documents. Tools add hidden tokens too. Anthropic adds a tool-use system prompt (496 tokens on Haiku 4.5, 286 on Sonnet 5.5) on top of your tool schemas (Anthropic pricing).
Loops and retries. These are failed tool calls, re-asked questions and agents that check their own work. Each one is another full-price call.

One more catch: the same text produces different token counts on different models. Anthropic says the tokenizer in its newer models "produces approximately 30% more tokens for the same text" (Anthropic pricing). Count tokens on the model you'll actually use.

The formula

Monthly run cost is conversations times per-conversation token cost, plus retry overhead, plus fixed costs. Here it is in full:

Monthly run cost = N × (I × p_in + O × p_out) / 1,000,000 × (1 + r) + fixed costs

N      = conversations per month
I      = input tokens per conversation (summed over every model call)
O      = output tokens per conversation
p_in   = price per million input tokens; p_out = price per million output tokens
r      = retry/loop overhead (0.10 = 10% extra calls)
fixed  = vector DB, monitoring, hosting, search fees, human fallback

The hard part is calculating I correctly. Each call's input is fixed prefix + history so far + new content. With T turns, k calls per turn and h tokens added to the history each turn:

History tokens per conversation = k × h × T(T − 1) / 2

The T(T − 1) term is the important part. Going from 4 turns to 8 turns multiplies history tokens by 4.7 (from 6 to 28 in the T(T − 1)/2 term), not by 2.

Here's the same calculation as a small pricing calculator you can edit:

def agent_cost(convs, turns, prefix, user, tool_call, tool_result, answer,
               price_in, price_out, overhead=0.10):
    history, tokens_in, tokens_out = 0, 0, 0
    for _ in range(turns):
        tokens_in += prefix + history + user                            # call 1: pick a tool
        tokens_in += prefix + history + user + tool_call + tool_result  # call 2: answer
        tokens_out += tool_call + answer
        history += user + tool_call + tool_result + answer
    per_conv = (tokens_in * price_in + tokens_out * price_out) / 1e6
    return per_conv * (1 + overhead) * convs

print(agent_cost(3000, 4, 2000, 100, 50, 1500, 250, 1.00, 5.00))  # ≈ 170.94

Worked example: AI agent cost per month for a small-business support bot

This example prices a small-business support bot at $170.94 a month on Claude Haiku 4.5, with every step shown so you can swap in your own numbers.

The setup (these are assumptions, so swap in your own): a support agent that searches a knowledge base and answers customers.

Assumption	Value
Conversations per month (N)	3,000 (about 100 a day)
Customer messages per conversation (T)	4
Model calls per turn (k)	2 (choose tool → answer)
System prompt + tool definitions	2,000 tokens
Customer message / tool call / retrieved docs / answer	100 / 50 / 1,500 / 250 tokens
Retry overhead (r)	10%

Step 1: tokens added to history per turn. 100 + 50 + 1,500 + 250 = 1,900. History at the start of turns 1–4 is 0, 1,900, 3,800 and 5,700 tokens.

Step 2: input per turn.

Call 1 = 2,000 + history + 100 = 2,100 + history
Call 2 = 2,000 + history + 100 + 50 + 1,500 = 3,650 + history
Per turn = 5,750 + 2 × history

Step 3: input per conversation. 4 × 5,750 = 23,000. History adds 2 × (0 + 1,900 + 3,800 + 5,700) = 22,800. That matches the formula: 2 × 1,900 × 6 = 22,800. Total I = 45,800 tokens.

Step 4: output per conversation. (50 + 250) × 4 = O = 1,200 tokens.

Step 5: monthly tokens, with 10% overhead.

Input: 45,800 × 1.1 × 3,000 = 151.14M
Output: 1,200 × 1.1 × 3,000 = 3.96M

Step 6: price it. On Claude Haiku 4.5 ($1 input / $5 output per million tokens): 151.14 × $1 + 3.96 × $5 = $151.14 + $19.80 = $170.94 a month, or about $0.057 per conversation. The Python above gives the same figure.

Notice the ratio: the agent reads 38 tokens for every token it writes. For tool-using agents, the input price matters far more than the output price.

Provider price comparison

Across six current models, the same worked example costs $17 to $342 a month in model fees alone. Prices as of 3 October 2026, taken from each provider's official pricing page. Re-check them before relying on this; they change often. Monthly cost uses the worked example (151.14M input, 3.96M output) with no caching and no batching.

Model	Input / Output per 1M tokens	Cached input per 1M	Example monthly cost
OpenAI gpt-6-luna	$0.10 / $0.50	$0.01	$17.09
Gemini 3.5 Flash-Lite	$0.30 / $2.50	$0.03 + storage	$55.24
Claude Haiku 4.5	$1 / $5	$0.10	$170.94
Gemini 3.5 Flash	$1.50 / $9	$0.15 + storage	$262.35
Claude Sonnet 5.5	$2 / $10	$0.20	$341.88
OpenAI gpt-6.1-sol	$2 / $10	$0.10	$341.88

Sources: Anthropic, OpenAI (short-context rates, up to 272K input tokens), Google (Gemini caching also charges $1 per million tokens per hour of storage).

Prompt caching is the biggest discount you can control. On Anthropic, a cache read costs 0.1× the base input price and a 5-minute cache write costs 1.25× (on Sonnet 5.5, that's $0.20 and $2.50 per million). With automatic caching, each new request reads everything up to the previous message from cache (Anthropic prompt caching). In our example, the eight calls add up to 45,800 input tokens. Of these, 36,450 are cache reads and 9,350 are writes:

Input: 36,450 × $0.20 + 9,350 × $2.50 = $0.0307 per conversation (down from $0.0916)
Add output ($0.012), the 10% overhead and the 3,000 conversations: $140.79 a month instead of $341.88, a 59% cut.

Two catches: the default cache lasts 5 minutes (a 1-hour cache costs 2× to write), so a quiet customer breaks the chain; and Haiku 4.5 only caches prompts of at least 4,096 tokens, so the early calls here wouldn't be cached (Anthropic prompt caching).

Batch APIs take 50% off at Anthropic, OpenAI and Google, but only for jobs that can wait, like nightly ticket summaries. They're no use for live chat.

Watch for introductory prices. Gemini 3.8 Flash is $0.75 / $3.75 until 31 December 2026, then $1.50 / $7.50 from 1 January 2027 (Google). If you budget at the introductory price, your bill will double when it ends.

Hidden costs beyond tokens

The model fee is only part of the cost of running an AI chatbot. The rest:

Vector database. Pinecone's free Starter plan covers up to 2 GB of storage, 2M write units and 1M read units a month. Its Standard plan has a $50/month minimum, then $0.33/GB/month for storage and $16–$18 per million read units (Pinecone). OpenAI's hosted file search charges $0.10/GB per day after the first free GB (OpenAI).
Monitoring and logging. You need traces to find loops. Langfuse Cloud is free for 50k units a month, and its Core plan is $29/month for 100k units plus $8 per extra 100k. You can also self-host it for free (Langfuse). Our example makes about 24,000 model calls a month before retries, so check how your tool counts units.
Search and hosted runtimes. Web search costs $10 per 1,000 searches on Anthropic and $10 per 1,000 calls on OpenAI. Google includes 5,000 free searches a month across Gemini 3.x, then charges $14 per 1,000. Anthropic's Managed Agents add $0.08 per session-hour of runtime.
Human fallback and app hosting. Escalated conversations cost your team's time, far more than the tokens. The server running the agent loop is usually a small cost, but never zero.

For comparison, Intercom's Fin charges $0.99 per resolved conversation (Intercom) — not like-for-like, since that price includes the product itself, but a useful ceiling.

When self-hosting an open model beats per-token pricing

Running an open model on a GPU you rent turns a per-token bill into a per-hour one. On Lambda, one NVIDIA A10 (24 GB) is $1.29/hour and one H100 PCIe is $3.29/hour (Lambda). Running all month (about 730 hours), that's about $942 and $2,402.

Our whole example costs $17–$342 a month through an API. At small-business volume, self-hosting costs more, often several times more. It starts to make sense when:

the GPU is busy most of the day, because your volume is high enough to use the capacity you pay for
your data can't leave your own infrastructure
you need a fine-tuned or specialised open model

To find your break-even point, benchmark how many tokens per second the GPU handles on your workload, then add the engineering time for patching, scaling and uptime.

Quick self-check: is your spend normal or bloated?

Pull a week of logs and check these:

Input-to-output ratio. A high ratio is normal for tool-using agents (ours is 38:1). A sudden rise usually means history or retrieval is growing unchecked.
Calls per turn. If you designed for 2 and see 5, the agent is looping. Set a hard cap on steps.
Cost by turn count. Long conversations cost far more than short ones. Summarise or trim history after a few turns.
Cache hit rate. The API's usage fields (for example, cache_read_input_tokens) show whether caching is working.
Model fit. Are you using a top-tier model for questions a small model can answer? Send easy questions to a cheaper model.
Most expensive 5% of conversations. Read them. Bugs and abuse usually show up there.

Want this run against your own numbers?

If you want this formula applied to your real logs, or an agent built with budget caps and caching from the start, that's part of our AI integration & agents work. Send us your volumes and we'll tell you what it should cost to run — or if an agent isn't worth it at all.

FAQ

How much does an AI agent cost per month for a small business?

In our worked example, 3,000 support conversations cost $17–$342 a month in model fees across six current models, before caching. On top of that come vector storage, monitoring, search and your team's time on escalations.

Why is my AI chatbot's running cost higher than the per-token price suggests?

Every call resends the system prompt, tool definitions and the conversation so far. History cost grows with the square of the number of turns, and retries add more full-price calls.

Does prompt caching really reduce LLM API costs?

Usually. In our example it cut the Sonnet 5.5 bill by 59%. Check your model's minimum cacheable prompt length and how long the cache lasts.

Is self-hosting an open-source model cheaper?

Rarely at small-business volume. One rented A10 GPU running all month costs about $942, which is more than our example's highest API bill.

What does your agent's input-to-output ratio look like, and which cost driver surprised you most? Tell us in the comments.

Originally published on banxal.com.

AI Agent vs Zapier for Small Business: Pick by Task

Manveer — Fri, 02 Oct 2026 15:54:56 +0000

Someone on your team just spent Friday afternoon copying form leads into the CRM. Again. Half your feed says "replace your team with AI agents"; the other half says "just use Zapier". Both camps are selling something.

Here's the honest answer to the AI agent vs Zapier small business question: most of your automations don't need an agent, a few genuinely do, and some shouldn't be automated at all. The task decides, not the tool. Below is a task-by-task table across Zapier or Make, n8n, custom code and AI agents, plus what each costs to run.

TL;DR

Ask one question first: does this task need judgment? If every input has one correct, rule-writable output, you want a workflow tool, not an agent.
Zapier or Make covers most small-business glue work. n8n earns its complexity with heavy branching, self-hosting or data control. Custom code wins at high volume or when the logic is your product.
Agents cost per run, and that cost varies run to run. Use them where the input is messy and the steps can't be predicted, with a human checkpoint in front of anything that touches customers or money.

The real question is "does this task need judgment?"

Anthropic, which builds agents for a living, draws a useful line. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths", while agents are "systems where LLMs dynamically direct their own processes and tool usage" (Anthropic, Building effective agents). Their advice is to find "the simplest solution possible, and only increase complexity when needed", because agentic systems "often trade latency and cost for better task performance".

So, in plain terms:

No judgment needed (form submitted, create CRM contact): a rule-based workflow — cheaper, faster, and it fails the same way every time, making it easy to debug.
A little judgment on a fixed path (read this email, label it "billing", "bug" or "sales"): a workflow with one AI step. The path is fixed; only one decision is fuzzy.
Open-ended judgment (research this prospect and decide what to look at next): an agent. Anthropic describes this as problems "where it's difficult or impossible to predict the required number of steps, and where you can't hardcode a fixed path."

That middle category is where most small-business value sits.

The four options in one sentence each

Zapier / Make: hosted, no-code "when this happens, do that" workflows across thousands of apps. Zapier lists 10,000+ (Zapier apps).
n8n: a visual workflow builder you can self-host, with JavaScript and Python code steps and 1,500+ integrations (n8n on GitHub).
Custom code: a script or service your developer writes, runs on your own infrastructure and keeps in version control.
AI agent: a language model given tools (search, CRM, email) and a goal, deciding its own steps until finished or stopped.

AI agent vs Zapier for a small business: the decision table

These are the tasks we see most often in startup and SMB backlogs. "Best fit" means the simplest option that does the job reliably, not the only one that could.

Task	Best fit	Why
Website form → CRM contact + Slack alert	Zapier / Make	Fixed path, popular apps, five minutes to build.
Stripe payment → invoice in accounting tool + welcome email	Zapier / Make	Clear trigger, clear actions, no judgment.
Weekly metrics from 3 tools into a Google Sheet	Zapier / Make (n8n if it grows)	Scheduled and predictable; move to n8n once it needs loops.
Lead routing with 10+ rules (region, size, source, owner capacity)	n8n	Lots of branching and merging; per-step pricing gets expensive.
Workflows touching health, finance or client data that must stay on your servers	n8n (self-hosted)	You control where the data runs.
Two-way CRM ↔ ERP sync with deduplication	Custom code (or n8n with care)	Conflict handling and retries are real engineering problems.
Sorting inbound support email into categories	Workflow + one AI step	Fixed path; only the labelling is fuzzy.
Pulling fields from invoices or PDFs with varying layouts	Workflow + one AI step	Extraction needs a model; everything around it doesn't.
Answering customer questions from your docs and policies	AI assistant on your data (RAG)	Questions are open-ended; answers must be grounded in your content.
Researching a prospect across the web and drafting a brief	AI agent	You can't predict which pages or how many steps it will need.
Nightly import of hundreds of thousands of rows	Custom code	Per-task or per-credit billing punishes volume; a script doesn't care.
A 10-minute task done twice a month	Skip automation	Write a checklist; automating costs more than it saves.

When Zapier or Make is simply correct

If the task is "when X happens in app A, do Y in app B" and both apps are mainstream, Zapier or Make is the right answer — not a compromise.

Speed to working. A non-developer can build and own it, so it doesn't wait in an engineering queue.
Built-in reliability. You don't run servers. Zapier also only counts a task when an action succeeds: "Failed actions are not counted" (Zapier pricing).
Low volume is cheap. Zapier says triggers and built-in tools like Filter, Formatter and Paths don't count as tasks (Zapier pricing).

This is the wrong choice if the workflow has grown past ~10 steps with nested paths, nobody remembers why each step exists, or your task count keeps tipping into the next pricing tier.

When n8n earns its complexity

n8n gives you more control in exchange for more responsibility. It earns it in three situations.

Self-hosting and data control. The Community edition is free to self-host. Its licence lets you use it "for your own internal business purposes" (n8n Sustainable Use License) — fine for your own automations, but embedding n8n in a product you sell needs its own licence check.
Branching-heavy logic. Loops, merges, sub-workflows and code steps in JavaScript or Python (n8n on GitHub) handle logic that turns a Zapier canvas into spaghetti.
Many steps, many runs. n8n bills per execution: "a single run of your entire workflow. It doesn't matter how many steps are in the workflow" (n8n pricing). A 15-step workflow costs the same as a 2-step one.

The hidden cost: self-hosting means you own updates, backups, uptime and security — if nobody will patch the server, use n8n Cloud or stay on Zapier.

When you actually need an AI agent

You need an agent when all three of these are true:

The input is messy: free text, varied documents, the open web.
You can't write the steps down in advance: the next action depends on what the last one found.
A wrong answer is recoverable: a human reviews it, or the cost of an error is small.

If only the first is true, skip the agent — put one AI step inside a normal workflow instead. Both Zapier and n8n support this, and it's easier to test, since the model makes just one decision per run.

When you do build an agent, take Anthropic's warning seriously: "The autonomous nature of agents means higher costs, and the potential for compounding errors. We recommend extensive testing in sandboxed environments, along with the appropriate guardrails" (Anthropic). In practice that means:

Start read-only. Let it search and draft; don't let it send, refund or delete until proven.
Default to approval. Anything reaching a customer goes through a human queue first.
Cap the run. Set a max step count and token budget so it can't loop all night.
Log every call. You need to see why, when it gets something wrong.

When to just write custom code (or skip automation)

Custom code is the right call when:

Volume is high. Per-task and per-credit pricing grows with every run; a script on a small server mostly doesn't.
The logic is your product. If customers pay for it, it belongs in your codebase with tests, not a no-code canvas only one person understands.
You need real sync. Two-way sync, idempotent retries and conflict resolution are easier to get right in code.

Sometimes the right automation is none: if a task is rare, changes every time, or lives in a tool with no API, a checklist beats a fragile bot. Quick automations also tend to become unmaintained software; if yours has, our guide on whether to fix or rebuild a vibe-coded app applies here too.

Cost reality check: the shape matters more than the sticker price

Every option is cheap to start; what matters is how the bill grows. Prices below are from each vendor's official pricing page on 2 October 2026 — check again before committing, since they change.

Option	You pay per…	Entry price (official page, 2 Oct 2026)	How the bill grows
Zapier	Task (each successful action)	Free: 100 tasks/mo, two-step Zaps only. Professional: $19.99/mo billed annually ($29.99 monthly) for 750 tasks; $39/mo annually for 1,500	Steps × runs. With pay-per-task on, overage is 1.25× the base rate on annual plans or 2.5× on monthly (Zapier)
Make	Credit (each module action)	Free: 1,000 credits/mo; Make plan from $9/mo for 5,000 credits (Make)	Modules × runs; routers and error handlers don't count
n8n	Execution (whole workflow run)	Cloud Starter €20/mo billed annually for 2,500 executions; Pro €50/mo for 10,000; Community edition free to self-host (n8n)	Runs only. Self-hosting turns it into server costs plus your team's time
Custom code	Developer time up front, then hosting	Depends on scope	Large one-off cost, then low and mostly flat
AI agent (via API)	Tokens in and out	For example, Claude Haiku 4.5 is $1 per million input tokens and $5 per million output; Sonnet 5.5 is $2 / $10 (Anthropic pricing)	Runs × tokens per run. The same task can use very different amounts of tokens each time

A quick worked example: a workflow with a trigger and four actions, run 300 times a month, costs roughly 1,200 Zapier tasks (over the 750 tier, onto the $39/mo annual 1,500 tier), 300 n8n Cloud executions (well inside Starter's 2,500), or 1,500 Make credits (inside the 5,000-credit tier). None is expensive at this size, but add steps or runs: Zapier's bill grows on both, n8n's on one.

For agents, Anthropic publishes its own estimate: about 3,700 tokens per support conversation on Haiku 4.5 comes to "~$37.00 per 10,000 tickets" (Anthropic pricing). Cheap, but that's roughly one conversation's worth of tokens. An agent that searches, reads pages and retries can use many times that, and the amount varies per run — budget with a per-run cap, not an average.

A 5-minute self-test

Pick one task from your backlog and answer these five questions.

How often does it happen? Less than weekly and under 15 minutes? Write a checklist and stop here.
Could you write every rule on one page? Yes → Zapier, Make or n8n. No → keep going.
Is only one step fuzzy (classify, extract, summarise)? Yes → a workflow with one AI step.
Does the path change based on what it finds? Yes → an agent, with read-only tools and human approval to start.
Is it high-volume, a two-way sync, or part of your product? Yes → custom code, whatever you answered above.

One more check: must the data stay on your servers? If so, use self-hosted n8n or custom code, regardless of your other answers.

Not sure which bucket your process fits?

If a task still doesn't fit a bucket, or your Zapier account has become something nobody wants to touch, that's what our automation & integrations work covers — including AI agents with review steps built in, where judgment is genuinely needed. Send us the process and we'll tell you which option fits, even if it's "keep using Zapier".

FAQ

Is an AI agent better than Zapier for a small business?

For most tasks, no — Zapier is cheaper, faster and more predictable for fixed "when X, do Y" workflows. An agent wins only when the input is messy and the steps can't be decided in advance, like prospect research or open-ended Q&A.

Is n8n cheaper than Zapier?

It depends how the workflow's built. n8n charges per execution regardless of step count, while Zapier charges per successful action (n8n pricing, Zapier pricing). Long, many-step workflows usually cost less on n8n; simple two-step ones cost about the same, and Zapier takes less setup.

Can I add AI to Zapier or n8n without building an agent?

Yes, and it's often the best option: put a single AI step (classify, extract, summarise) inside a normal workflow. The path stays fixed and testable, and you pay for one model call per run.

What's the biggest mistake with AI agents?

Giving them write access too early. Start with read-only tools and human approval, cap steps and tokens per run, and log every action before you let an agent send anything on its own.

Originally published on banxal.com.

Hand Off a Lovable or Bolt App to a Developer: Prep Guide

Manveer — Thu, 01 Oct 2026 21:14:32 +0000

You built the app in Lovable or Bolt. Now you've found a developer or agency to take it further, and their first message is: "Can you send me access?"

Before you reply, work out what "access" means. A Lovable or Bolt app lives in several places: the builder, a GitHub repo, a database, a secrets store, a domain, plus payment and email accounts. Hand off a Lovable app to a developer without mapping those, and either they spend their first paid days finding your setup, or you hand over keys you can't take back.

This guide covers the founder's side: what to export, lock down and write down before a developer opens the repo.

TL;DR

Give access, keep ownership. Invite the developer into your GitHub, database and hosting accounts. Don't transfer the accounts themselves unless you're selling the app.
Find your backend first. Lovable Cloud, your own Supabase project and Bolt Database each hand off differently. Neither builder offers a one-click way to move off its built-in database.
Secrets don't travel with the code. Lovable secrets are write-only and never sync to GitHub. Make a list of every key, share the keys safely and rotate any that have been pasted into chats.

Why handoff prep matters

Developers bill for discovery: an hour spent asking "which Supabase project is production?" costs the same as an hour building features.

There's a security reason too: Lovable's own guidance says "secrets stored in frontend code are visible to users and should be considered compromised" (Lovable security best practices) — a key pasted into a prompt, Slack thread or freelancer email counts the same way.

What moves automatically vs what you must export

The biggest variable is where your data lives — find out first.

Lovable Cloud. This is Lovable's built-in backend, "built on Supabase's open-source foundation" (Lovable Cloud docs). You manage it inside Lovable. We found no documented way to give an outside developer direct access to the dashboard underneath it.
Your own Supabase project connected to Lovable. Lovable says this route gives you "your own Supabase account and billing, full access to the Supabase dashboard" (Lovable Supabase docs).
Bolt Database. Bolt "will typically automatically create one as soon as your project needs it" (Bolt databases intro). On Pro or Teams plans you can claim it into your own Supabase organisation (Bolt Supabase docs).

Item	Lovable + Lovable Cloud	Lovable + your own Supabase	Bolt + Bolt Database
Code	Two-way GitHub sync, one branch at a time	Same	GitHub sync with auto-commits, or ZIP download
Database	Export data and storage; no one-click move to your own Supabase	Already yours; invite the developer to your Supabase org	Claim into Supabase (Pro/Teams) for direct access
Secrets	Write-only, not synced to GitHub	Lovable secrets plus any Supabase-side keys	In Bolt's Secrets panel; unclear if included in exports
Custom domain	Via Lovable: belongs to the workspace. External: A + TXT at your registrar	Same	Check where you bought it
Stripe, email, analytics	Never moves; lives in your own accounts	Same	Same

Lovable states "there is no one-click migration from the built-in backend (Cloud) to Supabase or the other way" (Lovable Supabase docs), and Cloud's region can't be changed once enabled (Lovable Cloud docs). Treat a move to your own Supabase as a scoped migration, not a settings change.

The pre-handoff checklist: access, code, data, docs

Work through this in one sitting; most of it takes a couple of hours and needs no technical skill.

Access

[ ] Write down every account the app touches: builder, GitHub, database, hosting, domain registrar, DNS, Stripe, email provider, analytics and any AI API. Note the login email and who pays for each one.
[ ] Turn on two-factor authentication for every account you own.
[ ] Invite the developer as a member or collaborator, not an owner. Supabase project transfers require you to be the source org's owner and can lower people's roles (Supabase project transfer). Keep the project in your org and add the developer to it.
[ ] Choose a safe channel for sharing keys, such as a password manager's shared vault. Don't use email, and don't use a chat app that keeps history forever.

Code

[ ] Connect GitHub if you haven't, and make sure the repo is in an account or organisation you control.
[ ] Confirm which branch the builder syncs to. Lovable "only edits and syncs one branch at a time" (Lovable GitHub docs).
[ ] Download a ZIP snapshot of the code today and keep it outside the builder.

Data

[ ] Take a backup before anyone touches anything. On a Supabase project you control, the CLI can dump roles, schema and data as separate files:

supabase db dump --db-url "$DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$DB_URL" -f schema.sql
supabase db dump --db-url "$DB_URL" -f data.sql --use-copy --data-only

(Supabase backup and restore. The full data command in the docs also excludes two storage tables. Copy it from there.) On Lovable Cloud, use the export option the Cloud docs describe for the database and storage files.

[ ] List which tables hold personal or payment data.

Docs

[ ] Write a one-page "how it works": who the users are, the three most important flows (signup, the core action, payment), and what's broken.
[ ] List every integration and which secret it uses, without writing the secret values in the doc.
[ ] Note anything you set up outside the builder, such as Stripe webhooks, DNS records or cron jobs.

How to hand off a Lovable app to a developer: Lovable-specific steps

Decide between collaborator access and moving the project. You can share the project, move it to another workspace, or transfer ownership; the new owner needs the owner, admin or editor role (Lovable project settings). For a normal engagement, share access and keep ownership.

Be careful moving workspaces once GitHub is connected. Moving the project to another workspace breaks the GitHub connection, and reconnecting creates a new repository; disconnecting works the same way (Lovable GitHub docs). Moving the repo itself is safer: sync continues "when your Lovable workspace also has a GitHub connection for the new owner," and GitHub keeps issues and collaborators and redirects the old URL (GitHub: transferring a repository).

Agree who edits where. Pushes to the active branch flow back into Lovable, so don't prompt on that same branch while the developer is working.

Rebuild your secrets inventory by hand. Lovable secrets "are write-only: after you save a secret, its value can never be viewed again in Lovable, only replaced or deleted," and they don't sync to GitHub (Lovable Secrets docs). If the original key isn't saved anywhere, generate a new one from the provider. The .env file is different: Lovable commits it so build-time VITE_* values are available, so it must hold only public values.

Check your domain. Domains bought through Lovable "belong to your workspace, not to a single project," and transferring one out is irreversible from Lovable's side (Lovable custom domain docs). An outside domain just needs an A record and a _lovable TXT record at your registrar — make sure you, not a past freelancer, can log in there.

Bolt app developer handover: Bolt-specific steps

Export to GitHub. Bolt's GitHub integration creates a commit "every time you make a change that doesn't break the project," and "checks GitHub every 30 seconds for any updates made outside Bolt" (Bolt GitHub docs). Only the project owner can manage it, and disconnecting is permanent — "you can't manually reconnect it" — so don't disconnect to "clean things up" before a handoff.

Keep a ZIP as well. Use Export > Download from the project title menu (Bolt projects docs) for a dated snapshot you control.

Don't transfer to a user unless you mean it. Bolt lets you transfer a project to another user, but "after the recipient accepts the transfer, you won't be able to access the project or make any further edits" (same page) — that fits a sale, not hiring a contractor.

Handle the database before you change anything. To get the developer into a real Supabase dashboard, claim the Bolt database into your Supabase organisation (requires a Pro or Teams plan and Supabase org owner). Don't connect a new Supabase project instead: Bolt warns that doing so "will replace the connection, which may cause data loss" (Bolt Supabase docs).

Treat secrets as unknown until checked. Bolt's Secrets panel keeps values out of users' browsers (Bolt secrets docs), but Bolt's docs don't say whether secrets or .env files end up in GitHub syncs or ZIP downloads. Open both and check — rotate any private key you find.

What a developer checks in the first hour

A good developer runs roughly these checks first — here's what each finding means.

First-hour check	Good sign	Bad sign and what it means
Clone and run the repo locally?	Runs from the README	Fails: expect setup cost before feature work
Secret keys in the browser bundle	Only publishable keys	A Supabase secret or `service_role` key: rotate it today — secret keys "bypass Row Level Security" (Supabase API keys)
Row Level Security on user tables	On, with policies per table	Off: any logged-in user may read others' data
Which environment is production?	One clear prod project	Several near-identical projects to untangle
Payment webhooks	Signed, handled server-side	Missing: payments can succeed without the app knowing

If they find a leaked key, follow Supabase's order: "Fix the root cause of the leak before you rotate anything," then create the new key, update everywhere, and retire the old one (Supabase API keys) — rotating first just leaks the new key too.

Handoff or rebuild?

Most apps that reach a handoff need fixing, not replacing. The deciding question is the data model, not the code: if your database still describes how your business works, a developer can harden what you have; if it doesn't, every fix fights the structure underneath. Run that test — Fix or Rebuild Your Vibe-Coded App? A 30-Minute Self-Test — before the handoff.

FAQ

Can I export a Lovable app to GitHub and keep building in Lovable?
Yes. The sync is two-way on one active branch. Lovable can export to a new repo but can't import an existing one (Lovable GitHub docs).

Should I give my developer my Lovable or Bolt login?
No. Invite them under their own accounts to the project, GitHub and Supabase — shared logins make it impossible to later remove just one person's access.

Do I need to move off Lovable Cloud before a handoff?
Not necessarily — only if the developer needs direct database access. It's a manual job, though: export the data, connect a Supabase project and rebuild the schema (Lovable Cloud docs).

When should I rotate secrets?
Rotate any key pasted into a chat, email or prompt before the handoff, and rotate every key the developer had when the engagement ends.

Next step

Want a second opinion before committing budget? Banxal's development services include a handoff review: we go through your repo, backend and secrets and tell you plainly whether it needs fixing, hardening or a partial rebuild. Get in touch and tell us what you've built.

Originally published on banxal.com.

Fix or Rebuild Your Vibe-Coded App? A 30-Minute Self-Test

Manveer — Thu, 01 Oct 2026 19:57:39 +0000

Your Lovable, Bolt or Cursor prototype has real users. It also breaks every week, and you're about to pay someone to sort it out. Before you do, you need to know whether to fix or rebuild your vibe-coded app, because the answer decides whether you're buying a few days of work or a few months.

Most guides end with "book an audit". This one gives you the audit's first pass free: eight checks, about 30 minutes, no developer needed, ending in a verdict.

TL;DR

Most vibe-coded apps need fixing, not rebuilding. The usual problems are exposed secrets, missing database access rules and fragile payment handling. Each of those can be fixed on its own.
Your data model decides whether you rebuild. If your database can't describe how your business works today, patching the screens won't help.
Run the 8 checks below on your own app. Score them, read off your verdict, and give the results to whoever you hire so you aren't paying them to discover what you already know.

Why vibe-coded apps work in the demo and break with users

AI builders are good at getting a screen to show the right thing. Production needs more than that. Strangers have to be kept out of each other's data. Payments have to keep working when someone closes the tab mid-checkout. A table with 50,000 rows has to load as fast as it did with five.

Security research shows how big the gap is. Veracode tested code from over 100 large language models and found that AI-generated code introduced risky security flaws in 45% of tests (Veracode GenAI Code Security Report). The best-known example is CVE-2025-48757. A researcher scanned 1,645 Lovable-built apps and found 170 (10.3%) with exposed databases across 303 vulnerable endpoints. The leaked data included emails, phone numbers, payment status and API keys (bleek.dev, Superblocks). The cause was missing or weak Row Level Security, which is check 2 below.

None of this means your app is doomed. The demo proved demand. The invisible parts just haven't been built yet, and the checks below tell you how many of them are missing.

The 30-minute self-test: 8 checks

Run these only on an app you own or are authorised to test. Most checks just need your browser and your admin dashboards. Score each one Pass (0), Warn (1) or Fail (2).

1. Secret keys in the browser bundle (4 min)

Anything your app sends to the browser can be read by anyone who visits it.

Open your live app in Chrome. Press F12 to open DevTools, then go to the Sources tab.
Press Ctrl+Shift+F (Cmd+Option+F on Mac) to search across all files.
Search for sk_live, sk_test, rk_live, sb_secret_, service_role and secret.
Open your Supabase project's API keys page. Copy the first 20 or so characters of the secret / service_role key and search for those too. Legacy Supabase keys are encoded, so the word "service_role" may not appear in plain text.

Pass: you only find publishable keys (pk_live_, sb_publishable_, the anon key). Stripe and Supabase both say these are safe to expose (Stripe, Supabase).
Fail: any secret, restricted or service key shows up. Rotate it today, before anything else.

2. Row Level Security (5 min)

Supabase's own docs are blunt: a table without RLS "is readable and writable by any role with a grant on it" (Supabase RLS).

In the Supabase dashboard, open Advisors → Security Advisor. Look for errors like RLS Disabled in Public or Sensitive Columns Exposed (Supabase Advisors).
Run the two-account test. Sign up as User A and create a record (an invoice, a project, a message) and copy its URL. Then sign in as User B in a private window and open that URL.

Pass: the advisor is clean and User B sees nothing.
Warn: the advisor shows warnings, but the two-account test holds.
Fail: any RLS error, or User B can see A's data. One catch: Lovable's built-in scanner only checks whether a policy exists, not whether it actually blocks access (Superblocks). The two-account test is what proves it works.

3. Auth and session handling (4 min)

Log out, press Back, then reload a private page. Do you still see data?
Signed in as a normal user, type /admin (or whatever your admin route is) straight into the address bar.
Run a password reset from start to finish. Does the email arrive, and does the link expire after you've used it?

Pass: all three behave. Warn: the reset flow is flaky. Fail: a normal user can reach admin pages, or a logged-out session still shows data.

4. Payment webhooks (5 min)

A webhook is the message Stripe sends to your app's server when a payment succeeds or a subscription changes. Many prototypes skip it and unlock paid features when the browser lands on the "success" page, which breaks the moment someone closes the tab.

In Stripe, open Workbench → Webhooks. Is an endpoint registered at all? Open Event deliveries and look for anything marked Failed or Pending (Stripe webhooks).
In a sandbox, start a checkout, pay with a test card and close the tab before the redirect finishes. Does the account still upgrade?
Cancel that test subscription from the Stripe dashboard. Does the app take away access?

Pass: an endpoint exists, deliveries succeed and both tests behave. Fail: there's no endpoint, deliveries are failing, or access doesn't follow what Stripe says.

5. Data model sanity (5 min)

This is the check that decides fix versus rebuild. Open Supabase's Table Editor and look for:

Tables named after screens (dashboard_data, page_two) instead of things in your business (customers, orders).
The same fact stored in several places, like a customer's email in four tables.
Lists crammed into one text or JSON column.
User-owned tables with no column saying who owns each row.
Something your business does now that the schema can't represent, such as teams, multiple locations or more than one price per product.

Pass: none of these. Warn: one or two, and they're contained. Fail: the last bullet is true, or most of the others are.

6. Error monitoring (2 min)

Who finds out first when something breaks, you or your users? In DevTools, search the Network tab for sentry, logrocket or bugsnag, then check whether you've ever actually received an alert.

Pass: errors reach you automatically. Fail: your users are your monitoring.

7. Page load with realistic data (3 min)

Fill a test account with the amount of data your heaviest customer has. In DevTools, set Network throttling to Slow 4G and load your busiest page.

Pass: the main content appears within about 2.5 seconds. Google's web.dev counts Largest Contentful Paint at 2.5s or less as "good" and over 4s as "poor" (web.dev). Warn: 2.5 to 4 seconds. Fail: over 4 seconds, or the Network tab shows the page downloading an entire table at once.

8. Code in version control you own (2 min)

Is your code in a GitHub repository under your account or organisation? Lovable can create a private repo on your GitHub with two-way sync (Lovable docs). Bolt and Cursor projects should be in a repo too.

Pass: you own the repo and can see a history of changes. Warn: a repo exists but sits in a freelancer's account. Fail: the code only lives inside the builder or on one person's laptop.

Scoring: ship, fix, refactor or rebuild

Add up your points (maximum 16). These thresholds are our rule of thumb from how these problems usually group together. They aren't an industry standard.

Score	Also true	Verdict	What it means
0–2	No Fail on checks 1–4	Ship	Keep building. Add monitoring if you don't have it.
3–7	—	Fix	Targeted repairs. Security fails (checks 1–2) go first, this week.
8–16	Check 5 is Pass or Warn	Refactor	Keep the product and the data, but restructure the code in stages.
8–16	Check 5 is Fail	Rebuild	The foundation can't hold your business. Plan a staged rebuild.

A low score with a Fail on check 1 or 2 still means act today. Rotate the key or turn on RLS, then carry on.

When rebuild is actually right (and when it's a sales pitch)

Most of the top guides agree, and so do we: the data model is the real test. Axonbuild argues that rebuilding is only justified when your data model "cannot express what the business now does" (Axonbuild). Appmatic puts it as refactor if the data model is sound, rebuild if the architecture can't support the roadmap (Appmatic).

Rebuild is right when:

Check 5 fails and your next three features all need the schema changed.
Every small change breaks something unrelated, and that's been true for months.
You can't get the code out of the platform at all.

It's probably a sales pitch when:

Someone quotes a rebuild without reading your code or schema.
The reasons are about taste ("the code is messy", "we'd use a different framework"). Messy code that works is a refactor job.
Exposed keys or missing RLS are given as the reason. Those are fixes, usually small ones.

What to hand a developer

To hand off a Lovable app to a developer (or a Bolt or Cursor one) without paying for discovery twice, send:

Your self-test scores, with screenshots of anything that failed.
Admin or collaborator access to the GitHub repo, Supabase, Stripe, hosting and your domain registrar. Use invites, never shared passwords.
A list of what's breaking, from user reports, with dates.
The next three features you need, so they can judge whether the data model will cope.
Your user and data numbers: active users, the biggest account, the largest tables.

If you'd rather not assemble this yourself, Banxal's maintenance and growth work starts with the same handover review before anything else is touched.

Fix or rebuild a vibe-coded app: what each option involves

Fixing, refactoring and rebuilding a vibe-coded app differ in what changes, what you keep, and what it costs. Cost ranges below are other agencies' published figures, not ours, and your app may differ.

	Fix	Refactor	Rebuild
What changes	Specific broken items	Code structure, tests, deployment	Code and usually the data model
What you keep	Everything	Product, data, most UI	Product knowledge, users, migrated data
Risk	Low	Medium	High: data migration and two systems running side by side
Published ranges	Axonbuild: 6–12 hour repairs at $240–$960 each	Appmatic: 4–10 weeks, $15,000–$40,000	Appmatic: 8+ weeks, $40,000+

Axonbuild's advice on the cost to fix a vibe-coded app is simple arithmetic: count your blocking problems, multiply by the cost per repair, and compare that with a rebuild quote (Axonbuild). Appmatic lists a separate code audit at 1–2 weeks from $2,500 (Appmatic).

FAQ

Is my Lovable app production ready if the Security Advisor is clean?
Not on that alone. The advisor finds missing RLS, but it can't tell you whether your policies match your business rules. Run the two-account test, and check payments and auth as well.

Can I run an AI-built app security check myself?
You can do the first pass. Checks 1–4 above catch the issues behind the best-known incidents. A developer still needs to review webhook signature checks and server-side logic, because that can't be seen from the browser.

How long does it take to fix a vibe-coded app?
Isolated issues such as a leaked key or a missing policy often take hours. The published ranges above put a fuller hardening at weeks. Your score is a better guide than any average.

Next step

If your score says fix or refactor, the next step is a code review and handover conversation. Bring your self-test results. Banxal builds and hardens web apps and SaaS products, and can look after them afterwards through ongoing maintenance. We'll tell you plainly if a rebuild isn't needed. Talk to us about your app.

Originally published on banxal.com.