DEV Community: Tushar Bhendarkar

Website Contact Form Not Sending Email: What Broke in 150 Real Cases

Tushar Bhendarkar — Fri, 30 Oct 2026 03:30:02 +0000

When a contact form stops emailing, the first advice is always to check the spam folder. I went through 150 public threads where a site owner's form stopped sending and the cause was confirmed, and the email was sitting in spam in 8 of them. In 63, more than 4 in 10, the website was sending the email in a way inbox providers don't trust, so it never arrived anywhere.

The threads come from WordPress.org support for form and email plugins, Stack Exchange, and the forums of Netlify, Shopify, Square Online, Wix, Webflow and several hosts, from 2008 to 2026. I only counted a thread when the person confirmed the fix worked, an accepted answer named the cause, or support staff confirmed it.

Below is where form emails get lost, how to find which step yours stops at, and the fix for each cause, with notes for WordPress, Wix, Shopify, Netlify and Webflow.

Why contact form emails don't arrive: 150 confirmed cases

A contact form email passes through three steps: the website has to send it, the sending server has to hand it to your email provider in a way it trusts, and your provider has to deliver it to your inbox. Each cause below breaks one of those steps.

Sending is the weak step: 63 of 150. The spam folder, the usual first suggestion, held the email in 8.

WordPress.org is 64 of the 150 threads, so WordPress causes weigh heavily. But the same causes came up on custom PHP sites, Joomla, Drupal, Magento and ASP.NET, because they all start from the same default: let the web server handle the email itself.

First, find where your form email stops

Check the submission was saved. WPForms, Forminator, Fluent Forms and Netlify Forms keep entries; for Contact Form 7, the free Flamingo plugin does. No entry means the form never sent anything, and the problem is on the website.
Send the form's email to a test address. Open the email spam tester, then set the form's notification address to the test address it gives you, or enter it as the visitor's email if your form sends an auto-reply. Submit once. If nothing arrives, the sending step is broken; if it arrives, the report shows whether it passed SPF, DKIM and DMARC.
If the test arrives but your inbox never does, the problem is in delivery: your web server keeping the email, a filter, or a blocked address.

Fix the sending: a real email login, from your own domain

Three of the top causes have the same fix. In 23 cases the site sent through the web server's built-in mail, usually PHP mail(), with no login to a real email account, so Gmail, Outlook and company mail servers had no reason to trust it. In 14, the form put the visitor's address in the From field, so the email claimed to come from Yahoo or Gmail while being sent by your web host. In 13 more, the host blocked or limited outgoing mail, for reasons from spam and malware to plan limits and hosts with no mail service at all.

Send through a real account or sending service. In WordPress, an SMTP plugin such as WP Mail SMTP, FluentSMTP or Post SMTP connects the site to Google Workspace, Microsoft 365, Zoho or a service like Brevo, Mailgun or Amazon SES. Custom sites do the same with a mail library and SMTP login, or the service's API.
Send From your own domain, Reply-To the visitor. Use an address such as website@yourdomain.com as the sender, and put the visitor's address in Reply-To, so clicking Reply still answers them.
Publish SPF, DKIM and DMARC for the service you send through. Five cases were missing records outright; the guide to why emails go to spam explains each one and what I found across 1,545 small business domains.

The From field matters more than it looks, because many visitors' email providers tell the world to refuse mail that pretends to be from them. Their published DMARC policies, as of October 2026:

Visitor's email	DMARC policy	A form email "From" them
yahoo.com, aol.com, comcast.net, verizon.net	reject	Refused
btinternet.com, sky.com	reject	Refused
icloud.com, me.com, att.net, proton.me	quarantine	Sent to spam
gmail.com, outlook.com, hotmail.com	none	Often delivered, but not trusted

That's why a form can work when you test it with your Gmail address and fail for a customer on Yahoo. And if the email login itself breaks, which happened in 8 cases, half of them were Gmail connections: a normal password Google blocked, or an OAuth connection that expired or was left in testing mode.

When the web server keeps your email (17 cases)

This one surprises people, because the form works and the email is sent, just to the wrong place. When your website and your email are with different providers, for example the site on Bluehost or GoDaddy cPanel hosting and the email on Google Workspace or Microsoft 365, the web server may still think it handles email for your domain. Mail to info@yourdomain.com then goes to a mailbox on the web server that nobody reads, and never reaches your real inbox, while mail to a Gmail address works fine.

In cPanel, open Email Routing for the domain and switch it from Local Mail Exchanger to Remote Mail Exchanger. On Plesk, Virtualmin and similar panels, turn off the mail service for that domain. The giveaway is a form that delivers to an outside address but not to your own domain.

When the form never sends (24 cases)

In 10 of these, the form's own spam protection was rejecting real enquiries: expired or mismatched reCAPTCHA keys, Fluent Forms' token check, cookie consent plugins blocking the spam check, and twice WordPress's Disallowed Comment Keys list, which in one site contained ".com", so every message with an email address was treated as spam. After changing any anti-spam setting, submit the form yourself from a phone and a computer.

The rest were code and setup: JavaScript errors from another plugin, fields without name attributes, a form whose PHP script was hosted where PHP can't run, and four Netlify Forms sites where the submission never reached Netlify's form handler, for example a React form with no plain HTML copy for Netlify to detect at build time. Check the browser console when you submit; an error there means the email was never attempted.

Platform notes: Wix, Shopify, Square Online, Netlify, Webflow

Wix: notifications come from an automation; one had no recipient set, and a form built from loose input fields instead of a Wix Forms widget never triggered it.
Shopify: contact form messages go to the store's Sender email in the notification settings, so check it is an inbox you read. Twice Shopify had stopped sending to an address after earlier bounces, which only support could clear.
Square Online: one form had no recipient set on its Submit button; another worked but went to spam.
Netlify Forms: five notification addresses were on Netlify's bounce suppression list after failed deliveries, one caused by a brief Gmail outage; Netlify support has to remove them.
Webflow: one free-plan site hit the cap on form notification emails, so submissions were saved but no more emails went out.
Contact Form 7: one site had skip_mail: on in Additional Settings, which tells it not to send email at all.

How to stop losing enquiries

Keep a copy of every submission in the form plugin or platform, so a mail problem never loses the lead itself.
Send through a real email account on your own domain, with SPF, DKIM and DMARC set up for it.
Test after every change to hosting, DNS, email provider or plugins: one submission to the email spam tester shows whether it still arrives and passes.

More on email, domains and hosting is in Launch and hosting. And if you'd like it handled, I set up form email that reliably arrives as a client project. Email me the website address and what the form is built with.

Common questions

Why is my website contact form not sending emails?
Most often the website sends the email through the web server's built-in mail, with no login to a real email account, so Gmail, Outlook and company mail servers drop it. The next most common causes are the form's own spam protection blocking real messages, and a web server that delivers mail for your domain to itself instead of to your real inbox.

Why am I not receiving emails from my website contact form?
If the form says the message was sent, check whether the submission was saved, then where the email went. In 150 confirmed cases only 8 were in the spam folder; 17 were kept on the web server because it thought it handled the domain's email, and 7 were never sent because the platform had blocked the address after an earlier bounce.

How do I fix a WordPress contact form not sending email?
Install an SMTP plugin such as WP Mail SMTP, FluentSMTP or Post SMTP and connect it to a real email account or sending service on your own domain. Set the From address to that account and put the visitor's address in Reply-To. That was the fix in 32 of the 86 WordPress threads I found, more than any other.

Why is Contact Form 7 not sending email?
Contact Form 7 uses WordPress's default mailer, which on many hosts sends unauthenticated mail that never arrives. Also check that the Mail tab's From field uses your own domain, that Additional Settings does not contain skip_mail: on, and that reCAPTCHA or a cookie plugin is not blocking submissions.

Should the From address on a contact form be the visitor's email?
No. Send From an address on your own domain and put the visitor's address in Reply-To, so you can still reply with one click. Yahoo, AOL, Comcast, Verizon, BT and Sky publish a reject policy for their addresses, so a form email pretending to come from them gets refused.

How do I test my website contact form?
Submit the form once and check that the plugin or platform saved the entry. Then point the form's notification at the address from an email spam tester, or use it as the visitor's email if the form sends an auto-reply, and see whether the email arrives and passes SPF, DKIM and DMARC.

This post first appeared on tusharbhendarkar.com. I write about the engineering behind what I ship. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.

Too Many Redirects Error: What Caused 165 Real Cases, and the Fix for Each

Tushar Bhendarkar — Tue, 27 Oct 2026 03:44:29 +0000

When a site shows "too many redirects", the usual advice is to clear your cookies. I went through 165 public threads where someone hit this error and the cause was confirmed, and clearing cookies fixed just 4 of them. In 65, about 4 in 10, the cause was the same mistake: HTTPS handled in two places that can't see each other, so each one keeps sending the browser to the other.

The threads come from Cloudflare Community, WordPress.org, Stack Overflow and the forums of hosts and site builders such as Netlify, Webflow and Ghost, from 2013 to 2026. I only counted a thread when the person confirmed the fix worked or an accepted answer named the cause.

Below is what the error means, what caused those 165 loops, how to tell which layer your loop is in from the addresses it bounces between, and the fix for each.

What the too many redirects error means

A redirect is a site telling the browser "this page lives at another address, go there". A loop happens when two rules undo each other: one sends the browser from A to B, the other from B back to A. The browser follows along until it hits its limit. Chrome and Firefox give up after 20 redirects, the limit set by the web's Fetch standard, and show one of these messages:

Chrome and Edge: "This page isn't working. yoursite.com redirected you too many times." with ERR_TOO_MANY_REDIRECTS
Safari: "Safari can't open the page. Too many redirects occurred trying to open..."
Firefox: "The page isn't redirecting properly"

If you're only visiting the site: reload once, then delete the cookies and site data for just that site and try again, or open it in a private window. In Chrome, click the icon to the left of the address and open the site's cookies and site data. In Safari on iPhone, go to Settings, Safari (under Apps on newer iOS), Advanced, Website Data, and remove the site. If it still fails, the problem is on the site's side, and the rest of this post is for its owner.

What causes too many redirects: 165 confirmed cases

The two red bars are the same mistake in different places: HTTPS handled twice. Browser cookies, the usual first suggestion, fixed 4.

Cloudflare's own forum is a quarter of the sample, which inflates the Cloudflare causes. But outside that forum the same mistake still leads: Flexible SSL in 14 threads, and HTTPS hidden by a proxy or load balancer in 22 more.

The pattern behind the top two is worth understanding, because it explains most loops. Your visitor's connection is secure up to some middle layer, such as Cloudflare, a load balancer or a reverse proxy, and that layer talks to your server over plain http. Your server sees an http request, redirects it to https, and the middle layer passes that redirect back to the browser, which asks again over https. Round and round, 20 times.

Find the loop from the addresses it bounces between

Before changing settings, look at the actual hops. Paste the address into the redirect checker, which follows each redirect and stops at the loop, or run curl -IL https://yoursite.com in a terminal. Where the addresses bounce tells you which layer is to blame:

The hops look like	Usual cause
The same https address, over and over	HTTPS handled twice: Cloudflare Flexible, a proxy or load balancer, or a tunnel connecting over http
yoursite.com to www.yoursite.com and back	Two layers disagree on www: host or site builder settings against Cloudflare, the server or the CMS
/page to /page/ and back	Trailing slash rules: the framework adds the slash and the host or proxy strips it
/en to / and back, or between language subdomains	A language redirect that also runs on the address it redirects to
/dashboard to /login and back	Login or middleware: the session is not seen, or the login page runs the same check
One address redirecting to itself	A rule matching its own target, such as a too-broad redirect plugin rule

If the loop only happens for you and not in a private window or on your phone, it is the rare cookie case. Otherwise it is in the site's settings, and the fixes below follow the order of how often each cause came up.

How to fix too many redirects, cause by cause

Cloudflare SSL mode set to Flexible (40 cases)

In Cloudflare, open SSL/TLS and change the encryption mode from Flexible to Full (strict), or Full if your server only has a self-signed certificate. That makes Cloudflare connect to your server over https, so the server stops redirecting. Cloudflare's troubleshooting guide covers the same fix. Check it even if you never picked Flexible: in three of the threads, Cloudflare's Automatic setting had chosen it.

HTTPS hidden by a proxy or load balancer (25 cases)

This is the same loop without Cloudflare: an AWS load balancer, Heroku's router, nginx in front of Apache, a Docker proxy or a Kubernetes ingress handles https and passes plain http to your app. The fix is to let the app trust the X-Forwarded-Proto header that the proxy sets:

WordPress: add the snippet from WordPress's HTTPS guide to wp-config.php, which sets $_SERVER['HTTPS'] = 'on' when the header says https.
Django: set SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https"), with the HTTP_ prefix, which one thread missed.
Express: call app.set('trust proxy', 1) and check req.secure, not the raw protocol, which is always http behind Heroku.
nginx in front of another app: pass proxy_set_header X-Forwarded-Proto https when an outer proxy already handled https, because $scheme will be http there.

Three of these cases were a Cloudflare Tunnel pointed at http://localhost while the server forced https. Point the tunnel at the https port instead, or stop redirecting on the server; my guide to exposing a local API with Cloudflare Tunnel shows the setup.

A WordPress plugin (24 cases)

SEO, redirect, security, membership and caching plugins all add redirects. Yoast SEO came up in 6 threads, half of them its option to remove the category base from URLs; the Redirection plugin looped when a rule matched its own new address. If you can't reach the dashboard, rename the plugin's folder in wp-content/plugins to turn it off, then turn plugins back on one at a time. Security plugins can leave rules in .htaccess that keep looping after they are removed, so check that file too.

Domain settings on the host or site builder (15 cases)

Site builders and hosts pick one address as the main one and redirect the rest to it. In 5 of the Webflow threads, Webflow's default domain was the bare domain while the DNS was set up for www, and making the www address the default fixed it. Netlify and Google Sites looped when their DNS records were switched to Proxied in Cloudflare; setting them to DNS only fixed it. Most of the rest were DNS records pointing somewhere other than the host, such as a Shopify store whose A record did not point to Shopify, or registrar forwarding left on for a Bubble app.

Trailing slash, language and login loops (23 cases)

These are rules in the app itself. A language redirect has to skip addresses that already have the language; a trailing slash rule has to agree with what the host does to the URL; and login middleware must not run on the login page, static files or the page it sends users to. In Next.js, use the middleware matcher to exclude those paths. When a login loop only happens in production, check that the session cookie and the app's base URL use the same host, including www.

Server rules, site address and www conflicts (25 cases)

In WordPress, the WordPress Address and Site Address under Settings, General must match the real address exactly; two threads were fixed by removing capital letters from them. Then make sure only one layer decides between www and the bare domain and between http and https: the host, a Cloudflare redirect rule, .htaccess or nginx, not two of them. Four of the loops came from Cloudflare redirect rules, so check Rules in the Cloudflare dashboard too.

How to stop redirect loops from coming back

Decide one final address, such as https://www.yoursite.com, and write it down.
Let one layer do each redirect. If Cloudflare forces https, the server doesn't need to; if the host picks www, nothing else should.
Test after every change to DNS, SSL, plugins or hosting: the redirect checker tests http, https, www and the bare domain at once, and all four should reach the final address in one hop.

More on domains, SSL and hosting is in Launch and hosting. And if you'd rather hand it over, I fix redirect loops and run domain and hosting moves as client projects. Email me the site address and where it is hosted.

Common questions

What does "too many redirects" mean?
The site kept telling the browser to go to another address, which sent it back again, until the browser gave up. Chrome and Firefox stop after 20 redirects, the limit set by the web's Fetch standard. It is almost always a problem with the site, not your device.

How do I fix too many redirects in Safari or Chrome?
Reload once, then delete the cookies and site data for just that site and try again, or open it in a private window. In Safari on iPhone that is Settings, Safari (under Apps on newer iOS), Advanced, Website Data. If it still fails, the site itself is broken and only its owner can fix it.

Does clearing cookies fix too many redirects?
Rarely. In 165 cases where the cause was confirmed, clearing cookies or cache was the fix in only 4, all visitors to sites like Amazon, Gmail and Yahoo. In the other 161 the loop was in the site's own settings.

Why does Cloudflare cause too many redirects?
With the SSL/TLS mode set to Flexible, Cloudflare connects to your server over plain http. If the server redirects http to https, Cloudflare passes that back to the browser, which asks again over https, and the loop never ends. Switch the mode to Full (strict).

How do I fix too many redirects in WordPress?
Check Cloudflare's SSL mode first, then make the WordPress Address and Site Address match your real address exactly, including https and www. If the loop started after installing or changing a plugin, rename its folder in wp-content/plugins to turn it off.

How many redirects is too many?
Browsers give up at 20, but a healthy address needs at most one: from http or www straight to the final https address. Google's crawlers follow up to 10 hops, and every extra hop slows the page down.

This post first appeared on tusharbhendarkar.com. I write about the engineering behind what I ship. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.

How Much Does It Cost to Build an App for My Business? Real 2026 Numbers

Tushar Bhendarkar — Mon, 26 Oct 2026 03:30:05 +0000

Half of the small businesses posting a new app build on Upwork in September budgeted $900 or less. The simplest real app, a web tool with sign-up and one main screen, is about 124 hours of work, which comes to $4,600 to $9,200 at going rates. That gap is why so many app projects stall, get abandoned halfway, or launch and then break.

I see the budgets because I track freelance job posts, and I see the cost side because I build these apps. So I priced five apps small businesses ask for most, hour by hour, using a published estimating model, and put them next to what owners actually budget.

Below is what each one costs, where the hours go, why some quotes come in so much lower, and how to spend less without paying twice.

What small business apps cost, against what owners budget

The budgets come from 34 fixed-price job posts for a new app or SaaS build in my September 2026 sample of 501 Upwork posts: the middle one was $900, and the middle half ran from $100 to $3,500. The costs use the hour estimates published by appdevelopmentcostcalculator.com in October 2026, priced at the middle of Clutch's hourly bands: $37 for an offshore app company and $74.50 for a US software agency.

Even the simplest app costs about five times the typical budget. Budgets: 34 fixed-price new-app posts on Upwork, September 2026.

App	Hours	Weeks at 30 h/week	Cost range
Simple web tool: sign-up and one main screen	124	4	$4,600 to $9,200
AI assistant that answers from your documents	239	8	$8,800 to $18,000
Customer portal: logins, files, payments, admin	412	14	$15,000 to $31,000
Booking web app with payments and reminders	451	15	$17,000 to $34,000
Booking app on iPhone, Android and web	862	29	$32,000 to $64,000

None of these include hosting, app store fees or the monthly bill for an AI model, which depend on how many people use the app.

Where the hours go

Take the booking web app: sign-up, a booking calendar, card payments, reminders, an admin dashboard and one connection to another tool, such as your accounting software. Of its 451 hours, building the features themselves is only 176, or 39%. The rest is what makes the app safe to put in front of customers:

Testing, 77 hours (17%). Every payment path, every booking clash, every phone size.
Foundation and backend setup, 66 hours (15%). The database, sign-in plumbing and hosting everything else sits on.
Code review and hardening, 61 hours (13%). Security checks and fixing what testing finds.
Planning and calls, 55 hours (12%). Agreeing what gets built, and changes along the way.
Design, 16 hours (4%) with a ready-made UI kit; a custom design adds much more.

Features differ a lot, too. In the same model, sign-up and login are about 37 hours, card payments about 62, and chat between users about 108, because messaging needs real-time updates, storage and moderation. You can try your own mix in the app development cost calculator, which shows the same hours at offshore, freelance and US agency rates.

Why some quotes come in at $500

When the budget is $900, someone will still take the job. What you get for it is usually one of these: a template with your logo on it, a no-code setup you'll outgrow, the screens without a working backend, or a first draft that skips the 42% of hours that go into testing, review and planning. None of those are wrong if you know that's what you're buying. The trouble is when it's sold as the finished app.

AI app builders have changed the low end. Lovable, Bolt and Replit can produce a working first version in days for the price of a subscription, and for testing an idea that's often the right call. But the same gap shows up later: the Lovable apps and Replit apps I've looked at mostly break on the same production work, such as login, data security, payments and deployment, that a cheap quote leaves out.

What changes the price most

Mobile apps. Building for iPhone, Android and the web takes about 1.85 times the build hours of a web app alone, and testing doubles. That's most of the jump from $17,000 to $32,000 in the table.
Payments and subscriptions. Card payments and subscriptions are among the heaviest everyday features, and the ones you least want to get wrong.
Connections to your other tools. Each one, such as QuickBooks, HubSpot or Shopify, adds about 37 hours.
AI features. An AI assistant adds about 72 hours on its own, mostly server work, plus the AI provider's monthly bill.

How to spend less without paying twice

Build one job first. Pick the single thing a customer must be able to do, and cut the rest. An admin dashboard can start as a spreadsheet; subscriptions can start as one-off payments.
Start on the web. A web app that works on phones costs about half as much as native apps, and can often be installed like an app.
Use a managed backend such as Supabase or Firebase, which cuts server work by about 30% compared with a custom server.
Prototype with an AI builder, then pay for the production work: security, payments, testing and deployment, rather than rebuilding from scratch.
Agree the scope per milestone, so you see a working piece before paying for the next.

If you're still deciding, the cost calculator lets you untick features and see what each one adds, and there are more guides on getting a first version built in Build your MVP.

And if you'd like it built, I take on app builds as client projects, from a first version to finishing one an AI builder started. Email me what the app needs to do.

Common questions

How much does it cost to build an app for a small business?
At 2026 market rates, a simple web app with sign-up and one main screen is about $4,600 to $9,200, a customer portal or booking web app $15,000 to $34,000, and a booking app on iPhone, Android and the web $32,000 to $64,000. The range depends mostly on which features you need and whether it has to be a native mobile app.

How much does AI app development cost?
An assistant that answers questions from your own documents, with sign-up and file uploads, is about 239 hours of work, roughly $8,800 to $18,000 at offshore to US agency rates. On top of that you pay the AI provider every month, and that bill grows with how much people use it.

Why do some developers quote $500 for an app?
A quote that low usually covers a template, a no-code setup, or only the screens, without the server, testing and launch work that make up more than half of a real build. Compare quotes by what is included and how many hours they assume, not just the total.

How long does it take to build an app?
A simple web app is about 4 weeks for one developer working 30 hours a week, a booking or customer portal web app about 14 to 15 weeks, and a booking app on iPhone, Android and the web about 29 weeks. A smaller first version can launch much sooner.

Should I build a web app or a mobile app first?
For most small businesses, a web app that works well on phones first. Building for iPhone and Android as well takes nearly twice the build hours, and you can add the stores later once people use it; an installable web app covers much of the gap.

Is it cheaper to build my app with Lovable, Bolt or Replit?
Usually, for a first version. These tools can get a working prototype in days. The cost comes later, when it needs to be secure, reliable and connected to payments, which is where most of the problems I see with AI-built apps start.

This post first appeared on tusharbhendarkar.com. I write about the engineering behind what I ship. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.

Turn Your Own Machine Into a Public API Server (For Free) Using Cloudflare Tunnel

Tushar Bhendarkar — Sun, 25 Oct 2026 03:30:03 +0000

Recently, I wanted to use my own machine as a server. Not for production, just experimenting. Testing an API. Saving cloud costs. Trying out a few AI endpoints.

I expected this to be complicated: VPNs, port forwarding, firewalls, all the usual pain. So I researched a bunch of solutions. And surprisingly, the cleanest, fastest, most secure option was 👉 Cloudflare Tunnel.

It's free. It's easy. And it works beautifully. Sharing the exact steps I used in case someone else needs this.

cloudflared connects out to Cloudflare, so your router and firewall stay closed.

Step 1: Install cloudflared

brew install cloudflared

cloudflared tunnel login

This connects your Cloudflare account.

Step 2: Create a Tunnel

cloudflared tunnel create my-tunnel

Cloudflare will generate:

a tunnel ID
a credentials JSON file

This authenticates your machine.

Step 3: (Optional) Map a Domain / Subdomain

If you want a custom URL:

cloudflared tunnel route dns my-tunnel api.yourwebsite.com

No domain? For quick tests, cloudflared tunnel --url http://localhost:8000 gives you a temporary trycloudflare.com address instead.

Step 4: Configure the Tunnel

Create:

~/.cloudflared/config.yml

Add:

tunnel: <your-tunnel-id>
credentials-file: <path-to-credentials.json>

ingress:
  - hostname: api.example.com
    service: http://localhost:8000
  - service: http_status:404

This means: public URL → tunnel → your local FastAPI server.

Step 5: Run the Tunnel

cloudflared tunnel run my-tunnel

That's it! Your local API is now securely exposed to the internet. No port forwarding. No firewall changes. No server deployment.

Congrats! Your machine is now acting as a secure public API server, without any deployment or port forwarding. Feels like magic the first time you see it work.

Optional: Keep It Running Automatically

On macOS you can use launchctl to keep the tunnel alive:

launchctl load ~/Library/LaunchAgents/com.tunnel.plist
launchctl start com.tunnel
launchctl stop com.tunnel
launchctl unload ~/Library/LaunchAgents/com.tunnel.plist

🎯 Why This Is Useful

Test APIs without deploying
Run local AI inference endpoints
Prototype backend changes instantly
Webhook testing
Connect a frontend to a local backend
Experiment without cloud costs

Once you try this, you realize how powerful "local → public" can be.

If the API behind your tunnel is a chatbot that answers from documents, here is why it may give wrong answers and how to fix it. More notes like this one are in engineering notes.

Common questions

Is Cloudflare Tunnel free?
Yes. Cloudflare Tunnel is free to use with a Cloudflare account, which is what makes it a good fit for testing APIs and running small projects from your own machine.

Do I need to open ports or change my firewall?
No. cloudflared makes an outbound connection from your machine to Cloudflare, so nothing has to be forwarded on your router and no inbound firewall rule is needed.

Do I need my own domain to use Cloudflare Tunnel?
Not for testing. Running cloudflared tunnel --url http://localhost:8000 gives you a temporary trycloudflare.com address. For a stable address, route the tunnel to a hostname on a domain in your Cloudflare account.

Is it safe to expose my local machine this way?
Only the services listed in the ingress rules are reachable, and visitors connect to Cloudflare rather than to your IP address. If the API should not be public, put Cloudflare Access in front of the hostname so only approved users get through.

This post first appeared on tusharbhendarkar.com. I write about the engineering behind what I ship. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.

How I Debugged Expensify Bugs & Got Paid

Tushar Bhendarkar — Sat, 24 Oct 2026 03:30:02 +0000

Expensify paid me $500 for fixing two bugs in their app. I don't work there. Nobody assigned me the work. I found the bugs on GitHub, wrote up the root causes, and my fixes were merged into a React Native app used by more than 10 million people.

The money is the hook, but it's not the story. The story is what it takes to get a fix merged into a codebase that size when nobody knows who you are. Here is how both bugs went down, plus two investigations that never became PRs but taught me just as much. (The contracts, payments and review are in the Expensify case study.)

How Expensify's bounty system works

Expensify runs one of the most open contributor programs of any production app. Bugs are filed as public GitHub issues, most carry a bounty (typically $250), and anyone can submit a proposal: a written explanation of the root cause and the fix you intend to make. If your proposal is approved, you implement it, go through review like any employee would, and get paid when it ships.

The catch: proposals compete. The way you win is not by being first, it's by being the person who actually understood the bug.

Bug 1: The onboarding modal that wouldn't go away

The symptom: a user connects Xero (accounting software) to their Expensify account, has two-factor authentication disabled, and refreshes the page. The onboarding modal pops up behind the 2FA setup prompt. This user finished onboarding long ago. The modal had no business being there (issue #46026).

The obvious place to look was the modal component. That was the wrong place.

The network tab told the real story. On app load, the client calls an OpenApp API to fetch initial user data into Onyx, Expensify's client-side state store. When Xero is connected and 2FA is disabled, the server refuses with error code 666 ("Your organization requires Two Factor Authentication") and returns empty data. That means the nvp_onboarding key, the flag saying "this user finished onboarding", never arrives on the client.

From there the dominoes fall in order: the hasCompletedGuidedSetupFlow selector reads the missing key and returns false, the navigation root sees an "un-onboarded" user, and it calculates the onboarding route as the app's initial state. The UI was doing exactly what it was told. The data was the problem.

Every step did what it was told. The missing onboarding flag, not the modal, was the bug.

My fix (PR #46750, three files) made the initial-state calculation aware of the pending 2FA gate: if the 2FA requirement modal is about to show, don't treat missing onboarding data as "user needs onboarding". Merged, $250.

The lesson: when a screen does something impossible, ask what data it was missing, not which component misbehaved.

Bug 2: The chat that vanished when you pressed the down arrow

The symptom: in Search, navigating chats with the keyboard scrolled the selected chat out of view whenever the chats were large (issue #48902). An accessibility bug: if you can't see what's focused, keyboard navigation is useless.

The cause lived in React Native's SectionList virtualization. The shared list component computes getItemLayout offsets by hand, and the list header and footer were accounted for differently than SectionList expects. Combine that with SectionList's default behavior of keeping exactly one item above the focused one, and items that can grow taller than the screen, and the focused chat ends up off-screen.

Here is the part that made this bug hard: the component, BaseSelectionList, is shared by a huge surface of the app. The reviewer suggested only pushing section header layouts conditionally. I tested that branch across my accounts and found it broke the virtualized list entirely on one of them, and I posted a video proving it (the discussion). We converged on viewOffsetToKeepFocusedItemInView: admittedly a workaround, and I said so in the thread, but it was the change whose failure modes we could actually enumerate.

My fix (PR #51754) shipped. Merged, $250.

The lesson: in a shared component, the best fix is not the most elegant one. It's the one whose blast radius you can defend in review.

The investigations that never became PRs

Two more bugs ate my evenings without paying out, and they were still worth it.

The back button that went home(issue #47562): creating a workspace from the search page, then pressing back, dumped you at the inbox instead of where you came from. The existing code "fixed" this with Navigation.resetToHome(), which is a mask, not a fix. I traced the real cause into the core routing logic: an extra route was being pushed into the root navigation state because a flag (isCentralPaneAndBottomTabMandatory) stayed true during full-screen navigator actions. I proposed both the targeted fix and the deeper flag change, with file-and-line links for every claim.

The mis-styled system message(issue #47487): a system message ("exported this report to CSV") rendered faded with an error indicator. Everyone's instinct said frontend styling bug. I clicked "Reply in thread" and watched the backend return an error for exactly this message type and no other. The styling was the app correctly rendering a server-side data problem. That analysis redirected the fix to the PHP backend and saved someone a week of patching the wrong layer.

What transfers to any large codebase

Reproduce before you read code. Both merged fixes started with a reliable reproduction, not a theory.
Write the root cause down with evidence. Every proposal linked the exact lines involved. Maintainers can verify a claim in minutes instead of re-deriving it.
Trace the data, not the symptom. One bug looked like a modal problem and was a missing API payload. Another looked like CSS and was a backend error. The same rule explains why AI chatbots give wrong answers: the model is rarely the problem, the data it receives is.
Respect the blast radius. When a component is shared everywhere, choose the fix you can test the edges of, and show your testing.

If you want to break into a large open source codebase, find a project that pays for fixed bugs and treat the proposal like the product. The bounty is $250. The proof that you can walk into 10 million users' worth of unfamiliar code and leave it better is worth a lot more.

Common questions

How does the Expensify bug bounty program work?
Expensify files bugs as public GitHub issues, and most carry a bounty, typically $250. Anyone can submit a proposal explaining the root cause and the intended fix. If the proposal is approved, you implement it, go through code review like an employee would, and get paid when the fix ships.

How much does Expensify pay for a bug fix?
Most issues carry a bounty of about $250. The two fixes in this post paid $250 each, $500 in total.

Do you need to work at Expensify to fix their bugs?
No. Proposals are open to anyone. Both fixes here came from an outside contributor, working as a contractor through Upwork.

How do you get a proposal accepted on a large open source project?
Reproduce the bug reliably first, write the root cause down with links to the exact lines involved, trace the data rather than the screen where the symptom appears, and choose a fix whose side effects you can test and explain.

This post first appeared on tusharbhendarkar.com. I write about the engineering behind what I ship. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.

AI Chatbot Giving Wrong Answers? Why It Can't Find What's in Your Documents

Tushar Bhendarkar — Fri, 23 Oct 2026 03:30:03 +0000

When an AI chatbot gives wrong answers about your own documents, the AI model is usually not the problem. The model only reads the few passages a search step hands it, and when that search hands it the wrong ones, a perfectly good model answers badly.

You have probably seen both versions of this. The bot says "I couldn't find that information" when the answer is sitting on page 4 of your PDF. Or it answers confidently with something your documents never said. Same root cause, different symptom.

I build these pipelines in my day job: pulling text out of documents, splitting it, indexing it, and running sets of test questions that catch wrong answers before users do. When an answer comes out wrong, the cause is usually in one of those earlier steps, not in the model.

In this post I'll explain why it happens in plain English, the five places it usually breaks, how to check each one, and how to prove a fix worked. It applies to chatbots built on your own documents (often called RAG, short for retrieval-augmented generation) and to ChatGPT custom GPTs with uploaded files.

How a document chatbot answers a question

A chatbot that answers from your documents does not read all of them every time someone asks something. That would be slow and expensive. Instead, each document is prepared once, and every question goes through the same short pipeline:

Extraction. The text is pulled out of the PDF, page by page.
Chunking. The text is cut into short passages of a few paragraphs each.
Embeddings. Each passage is turned into a list of numbers that captures its meaning, so passages can be compared with questions.
Search. The question is converted the same way, and the closest passages are found.
Context. The best few passages are pasted into the prompt next to the question.
Answer. The model writes a reply from what it was given, ideally citing the document and page.

Stages 1 to 5 decide what the model sees. The answer can only use what reaches it.

The model at the end can only be as good as the passages it receives. If the right passage never reaches it, it either says it found nothing, which is honest, or fills the gap with something that sounds right, which is worse.

A worked example: the refund question

Here is the failure in miniature, using a sample refund policy. The document, scores and results are illustrative, but the pattern is a very common one.

A customer asks: "When can I request a refund?" The rules are on page 4. The chatbot replies: "I couldn't find that information in your documents."

Problem 1: the chunk with the answer never says "refund"

The heading "5. Refunds" sits at the very bottom of page 3, and the rules start at the top of page 4. The document was split page by page, so the heading landed in one chunk and the rules in another:

Chunk A has the word the customer typed but no answer. Chunk B has the answer but never says refund.

Chunk B holds the answer, but it talks about "money back" and a "return window". The word the customer typed lives in a different chunk.

Problem 2: search finds the right chunk, then throws it away

Search does find chunk B, but it scores 0.76 for similarity, just under a cut-off of 0.80 that was set to filter out weak matches. Only three results are kept anyway:

The real answer scores 0.76 and falls just under the 0.80 cut-off, so the model never sees it.

So the model receives a passage about shipping and one about cancellations, neither of which mentions refunds, and correctly says it found nothing. Every part of the system did what it was told. Two settings, chosen once and never tested, did the damage.

The five places it breaks, in the order to check them

Do not guess which stage is broken, and do not start by swapping the AI model. For each question that fails, look at what every stage produced. The root cause becomes something you can see, not something you argue about.

1. Extraction: is the text actually there?

Open the extracted text for the page that holds the answer. Scanned PDFs are pictures of pages, with no text at all unless they go through OCR (text recognition) first. Tables often come out as a jumble of numbers, and two-column layouts can be read straight across both columns, mixing sentences. If the text is wrong here, nothing later can fix it.

2. Chunking: does each heading stay with its text?

Check the chunk that should contain the answer. Splitting by page or by a fixed number of characters cuts sections in half, exactly as in the refund example. Split along headings instead, keep each heading attached to the text under it, let neighbouring chunks overlap a little, and store the document name and page number with every chunk so answers can cite them.

3. Embeddings: are documents and questions measured the same way?

Documents and questions must be converted with the same embedding model. If the model was changed, or a PDF was replaced, every chunk has to be converted again. A half-updated index produces search results that look random.

4. Search settings: is a filter hiding good matches?

Look at how many passages are kept and whether there is a minimum score. Both are usually guessed when a chatbot is built; set them from test questions instead. When customers use different words from your documents ("money back" versus "refund"), meaning-based search alone can miss. Combining it with plain keyword search, known as hybrid search, catches those cases.

5. What reaches the model: is the found text sent, and is "not covered" allowed?

Check the final prompt. Sometimes the right passages are found and then cut to fit a length limit. And if the instructions never say "answer only from these passages, and say so when they do not cover the question", the model fills gaps with confident guesses.

Why it makes up answers instead of saying it doesn't know

A made-up answer is the same failure as "I couldn't find that", with a different ending. When search returns passages that are near the topic but do not contain the answer, the model tries to be helpful and stitches together something plausible.

Two changes stop most of it: an instruction to answer only from the passages provided, and a citation (document and page) on every answer. A citation makes a wrong answer easy to spot, for you and for your customers.

Prove the fix with the same questions, before and after

Before changing anything, agree on a set of test questions and the right answer for each. Include three kinds: direct questions, reworded ones (how customers actually talk), and questions your documents cannot answer, where the right reply is "that isn't covered". Run them before the fix and after. The fix only counts if this table improves:

Before: not found, and a made-up answer. After: the right answer with its page, and an honest 'not covered'.

Question	Type	Before	After
When can I request a refund?	Direct	Not found	Correct, p. 4
Can I get my money back?	Reworded	Generic answer	Correct, p. 4
How long do I have to return something?	Reworded	Not found	Correct, p. 4
Can I cancel before it ships?	Direct	Correct	Correct, p. 2
When will my order arrive?	Direct	Correct	Correct, p. 3
What if my item arrives damaged?	Reworded	Generic answer	Correct, p. 5
Do you ship to Canada?	Not in the documents	Made-up answer	Says it's not covered
Who is your CEO?	Not in the documents	Says it's not covered	Says it's not covered

In this sample, 3 of 8 answers were right before the fix and 8 of 8 after, each with the page cited. Look at the Canada question: before the fix the bot invented an answer, and after it says the documents do not cover it. For a business, that is the most important row in the table.

Keep the questions. Every time you add documents or change a setting, run them again.

If you use ChatGPT custom GPTs or file uploads

The same mechanics apply. A custom GPT searches its knowledge files for relevant passages instead of reading them end to end, so the same things go wrong:

Scanned PDFs may have no readable text. Run OCR first, or upload a text version.
Long files with vague headings are hard to search. Split them into smaller files with clear, descriptive headings.
In the instructions, tell it to search the knowledge files before answering, to name the section it used, and to say when the files do not cover a question.
Test it with the same before-and-after questions.

If a custom GPT still misses answers after that, it has reached the limits of a tool you cannot tune. That is usually the point where a small chatbot of your own, where you control the chunking, the search settings and the prompt, starts paying for itself.

The principle: find the stage that breaks, fix only that

Wrong answers from a document chatbot feel like an AI problem, so the instinct is to try a bigger model. Usually the fix is earlier and cheaper: text that was never extracted, a heading cut off from its section, or a search filter set by guesswork. Trace one failing question through every stage, fix the stage that breaks, and prove it with the same questions before and after.

It is the same rule that got two of my fixes merged into a 10 million user app: trace the data, not the symptom. More guides like this one are in AI chatbots and AI features.

If you would rather hand it over, I trace chatbots exactly this way. Send me the PDFs that cause trouble and a few questions that fail today, and you get the same before-and-after table for your own documents, with a short note on the root cause.

Common questions

Why does my chatbot say it can't find information that is in my PDF?
Because the passage with the answer never reached the AI model. Usually the document was split so the answer sits in a chunk without the words people search for, or a search setting (a minimum score, or too few results kept) dropped it. Check the extracted text and the search results for that question before changing anything else.

Why does my AI chatbot make up answers?
When search returns passages that are close to the topic but do not contain the answer, the model fills the gap with something plausible. Tell it to answer only from the passages it is given and to say when they do not cover the question, and require a document and page citation on every answer.

Why is my custom GPT not using its knowledge files?
Custom GPTs search their knowledge files instead of reading them end to end, so scanned PDFs, very long files and vague headings all make the right passage hard to find. Use text-based PDFs, split long files into smaller ones with clear headings, and tell the GPT in its instructions to search the knowledge files before answering.

Will a better AI model fix wrong answers?
Rarely. A stronger model still only sees the passages it is given. If the problem is extraction, chunking or search settings, a new model gives the same wrong answers in nicer words.

Can this be fixed without rebuilding the chatbot?
Usually, yes. Most fixes are a change to how documents are split, a re-index, adjusted search settings and a clearer prompt. A fixed set of test questions tells you when it is done.

This post first appeared on tusharbhendarkar.com. I build and fix AI chatbots and RAG systems for small businesses. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.

How to Transfer GitHub Repo Ownership Without Breaking Your Site

Tushar Bhendarkar — Thu, 22 Oct 2026 03:30:03 +0000

Transferring a GitHub repository takes about two clicks, and those clicks are rarely the problem. I went through 80 public reports of repository transfers going wrong, from Vercel's and Netlify's forums, GitHub, Railway, Reddit and Stack Overflow. The transfer itself failed in only 12 of them. The rest broke afterwards: hosting that quietly stopped deploying (22), a GitHub Pages site or custom domain that went down (15), and people locked out of accounts the old developer still controlled (12).

Every guide ranking for this search shows you GitHub's Transfer button and stops there. This one covers the button, and then everything connected to the repository that the button doesn't move.

It's also how I think about code in general. At The AI Lab, the code I work on, including the Trust Identity Protocol, lives in a GitHub organization, not in anyone's personal account. People join and leave; the code stays with the business. If your app's code sits in a developer's or agency's account, this is how to bring it home.

What actually breaks when you transfer a repository

The transfer itself failed in only 12 of 80 reports. Most broke afterwards, in what was connected to the repository.

Two things stood out. Hosting providers sometimes keep showing "Connected" while pointing at a repository that no longer exists at that address, so nothing looks wrong until you push a change and the live site doesn't update. And for small businesses, the code was rarely the hostage. Eleven reports were custom domains still sitting in an old Vercel or Netlify account, ten of them a former developer's or agency's. Only three were a developer refusing to hand the code over.

How to transfer GitHub repo ownership, step by step

Before you start, check three things:

The person transferring has admin access to the repository. Collaborators with write access can't do it.
The new owner has no repository with the same name, or a fork in the same network. If it does, rename one first.
For an organization, you're allowed to create repositories there, and the source organization allows transfers out. Owners can restrict both.

Open the repository on GitHub and click Settings.
Scroll to the Danger Zone and click Transfer.
Choose an organization, or type the username of the new owner.
Type the repository name to confirm, then click "I understand, transfer this repository".
If the new owner is a personal account, they get an email and must accept it within one day, or the invitation expires.

GitHub's transfer docs say old web links and git addresses redirect to the new location, so nothing breaks immediately. The redirect disappears if anyone later creates a repository with the old name, so update your local copy anyway with git remote set-url origin and the new address. The original owner is added as a collaborator afterwards; remove them when you're ready.

Moves with the repository	Stays behind or needs redoing
Commit history, issues, pull requests, wiki, stars	Hosting links (Vercel, Netlify, Cloudflare and others)
Repository secrets, webhooks and deploy keys	Organization-level secrets, variables and runners
Large files stored with Git LFS	Container images and project boards
Redirects from the old address	GitHub Pages address (not redirected)

One more trap: a private repository moved to a GitHub Free account loses its protected branches, wiki and GitHub Pages, because those are paid features for private repositories. If the site is published with GitHub Pages, it goes offline.

Relink your hosting, or your site stops updating

This was the biggest group in the reports. Vercel, Netlify, Cloudflare, Render, Railway and AWS Amplify all connect to GitHub through an app installed on one GitHub account. After a transfer, that app has to be installed on the new owner, and the hosting project pointed at the repository's new address:

Host	What to do after the transfer
Vercel	Settings, Git: disconnect, then connect the repository at its new address
Netlify	Continuous deployment, Repository, Manage repository: link the repository again
Cloudflare Pages	Cannot relink: transfer it back, or create a new Pages project
Cloudflare Workers	Disconnect builds, then connect the repository again
Render, Railway, Amplify	Install their GitHub app on the new owner, then reconnect

Vercel has two traps worth knowing. On the free Hobby plan, private repositories owned by a GitHub organization can't deploy at all, so moving a client's private repository into their new organization stops their deploys until they upgrade or keep it in a personal account. And Hobby only deploys commits authored by the owner of the Vercel account, according to Vercel's Git docs. Netlify has its own: the repository link belongs to the person who created it, so when the departing developer loses access, builds can stop, and the fix is to relink the same repository from your side.

Moving the hosting project itself is a separate step from moving the code. On Vercel, a project transfer carries its deployments, domains and environment variables, but not integrations such as a database, and it needs a team that both people belong to. On Netlify, if you and the developer don't share a team, the site transfer goes through support.

However it's hosted, I'd do it in this order: transfer the repository, reconnect the hosting, deploy once from the new repository, and compare the live site page by page with what visitors saw before. Only then remove the old access.

The domain is the part that gets stuck

In the reports, the domain was the most common thing still sitting in a former developer's account. Code can be transferred in two clicks; a domain registered or connected in someone else's account needs their cooperation, so sort it out while you're still on good terms.

Registrar: the domain should be registered in an account in your name, with your email on it.
Vercel: if your project only uses a subdomain, the root domain stays with the original Vercel team, which keeps paying for it if it was bought there.
GitHub Pages: if the developer verified your domain on their account, only their repositories can publish to it. Verify it on your own account, which also releases it if GitHub says the domain is already in use. A domain left pointing at GitHub Pages after the site is removed can be taken over by someone else, which is exactly the state a transfer to a free account can leave you in.

The same goes for every account around the code: hosting, email sending, payments, analytics and the database. Twelve reports were people locked out of one of these after the developer left. Make a list, and move each one into your name before you say goodbye.

For developers: what else changes after a transfer

Secrets you can't read back. Organization-level Actions secrets and variables stay with the old organization, and GitHub never shows secret values again, so collect the real values from wherever the developer keeps them before the move.
Cloud deploys through OIDC. Workflows that log in to AWS, Azure or Google Cloud are trusted by a subject that names the owner and repository. Since July 15, 2026, a repository transferred or renamed switches to a new subject format that includes IDs, so update the trust policies on the cloud side, per GitHub's OIDC reference.
A fresh organization is locked down. New organizations block OAuth-based tools until an owner approves them, and don't allow new deploy keys by default. The receiving organization's Actions policy applies immediately too, and it can block common actions.
Things that point at the old owner. Reusable workflows or actions in the agency's private repositories, CODEOWNERS teams, container images on ghcr.io, and submodule URLs. Package publishing breaks too: npm and PyPI trusted publishing check the owner and repository name.

When you cannot get a transfer

If the developer won't transfer the repository but will give you read access, you can still get a full copy with its history. GitHub documents it as mirroring: create an empty repository in your account, clone the old one with git clone --bare, then push it with git push --mirror to yours. The copy has every commit and branch; it just isn't linked to the original.

If they won't give you any access, who owns the code comes down to your contract, and that's a question for a lawyer, not for me. The cheaper fix is prevention: create the GitHub organization yourself at the start, give it at least two owners as GitHub recommends, and invite developers to it. The same goes for apps built with AI tools; I covered that version in how to export a Lovable project to GitHub.

The order that keeps your site running

Create your GitHub organization or account, and accounts for hosting and the domain.
Collect secret values and a list of every connected service while the developer is still around.
Transfer the repository, and accept it within one day.
Install the hosting app on the new owner and reconnect the project.
Move the domain and the other accounts into your name.
Deploy once from the new repository and check the live site page by page.
Only then remove the old developer's access.

More guides on taking control of an app are in Fix an AI-built app. And if you'd rather hand it over, I take these on as client projects: send me where things live today.

Common questions

How do I transfer ownership of a GitHub repository?
You need admin access to the repository. Open its Settings, go to Danger Zone, click Transfer, choose an organization or type a username, then type the repository name to confirm. A transfer to a personal account sends the new owner an email that expires if it is not accepted within one day.

Do commit history and issues move when I transfer a repo?
Yes. Commit history, issues, pull requests, the wiki, stars and watchers move with the repository, and so do its webhooks, repository secrets and deploy keys. Organization-level secrets, runners and project boards stay with the old owner.

Do old GitHub links still work after a transfer?
Yes. Web links and git clone, fetch and push to the old address redirect to the new one, though GitHub still recommends updating your remote with git remote set-url. The redirect stops working if someone later creates a repository with the old name, and GitHub Pages addresses are not redirected.

Will my Vercel or Netlify site keep deploying after I transfer the repo?
Not reliably. Both deploy through a GitHub app installed on one account, so install it on the new owner and reconnect the project to the repository at its new address. On Vercel's free Hobby plan, private repositories owned by an organization cannot deploy at all.

Can I transfer a GitHub repo to an organization?
Yes, if you are allowed to create repositories in that organization. Transfers out of an organization also need permission there, and organization owners can restrict transfers to owners only. Once it arrives, the organization's own rules, Actions policy and default permissions apply.

What if my developer will not transfer the repository?
If they will give you read access, you can make a full copy with its history in your own account by cloning it with --bare and pushing it with --mirror. If they will not give any access, it comes down to your contract, which is a question for a lawyer.

Do GitHub Actions secrets transfer with the repository?
Repository-level secrets do. Organization-level secrets and variables belong to the old organization and stay there, and secret values can never be read back from GitHub, so get the real values from your developer before the move if you need to recreate them.

This post first appeared on tusharbhendarkar.com. I fix apps built with Lovable, Replit, Bolt and Base44, and I build free checkers for live apps. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.

How to Export Lovable Project to GitHub and Really Own the Code

Tushar Bhendarkar — Wed, 21 Oct 2026 03:36:23 +0000

Several of the top guides on exporting a Lovable project to GitHub are out of date. They point to a GitHub button Lovable removed in May 2026, say you need a paid plan (sync works on every plan), and warn you never to rename the repository, a rule Lovable dropped this year. Follow them and you lose an afternoon looking for a button that isn't there.

The bigger problem is the one none of them cover. Exporting is easy. Owning the code is not the same thing, and the hard part comes when an app was built by a freelancer or an agency and the repository sits in their account. I sorted 136 public reports of Lovable and GitHub going wrong, and nine were exactly that: a handover stuck because the developer held the repository or the project.

This is the setup I'd use: how to export, what you actually get, the rules that keep the sync working, and the order for moving an app out of a developer's accounts and into yours without breaking anything.

What goes wrong between Lovable and GitHub

The reports come from Reddit, YouTube, Hacker News, Trustpilot and GitHub, from 2025 to October 2026. I put each one in a group by the cause the thread confirmed.

Most problems are about the sync and the account the repository lives in, not the code itself.

One caution on the chart: the reports about renaming or moving the repository all date from before Lovable changed its rules in 2026. Today renaming is safe, and moving is safe if you do it in the right order, which is most of what this post is about.

How to export a Lovable project to GitHub, step by step

Open Project settings, Git, GitHub. The GitHub button in the editor's top bar moved there on May 18, 2026. You can also reach it from the + button next to the chat, then Project, GitHub.
Add a connection. A GitHub popup asks you to pick your personal account or an organization, then All repositories or Only select repositories, then Install & Authorize. If nothing happens, your browser blocked the popup.
Connect the project. Lovable creates a brand-new private repository under the account you picked and starts two-way sync straight away.
Check it. The project settings should show Connected, a sync status card, a branch picker and links to clone or view the repository on GitHub.

Two permission traps come up often. Only a Lovable workspace owner or admin can add the GitHub connection. And in a GitHub organization, only an organization owner can install Lovable's app, because it asks for administration rights to create repositories; anyone else can only send a request. Lovable's GitHub docs cover both.

Sync works on every plan, with GitHub, GitLab or Bitbucket. Downloading the whole codebase as a zip is for paid plans, and Lovable recommends sync over zip snapshots anyway. One thing you can't do is connect a repository you already have: Lovable always creates a new one, so if you have existing code, let it create the repository and copy your code in.

What is in the repository, and what is not

This is where "I exported it, so I own it" usually goes wrong. According to Lovable's sync overview:

In the repository	Not in the repository
Your app code	Your database records
Edge functions and database migration files	Uploaded files, and since May 2026 large images, which live on Lovable's CDN
A .env file pointing at the live backend	Secrets, and the credentials behind connectors and Lovable AI

Two of those surprise people. The .env file means a copy of the code on your laptop reads and writes the same live database as your published app; a Git branch doesn't give you a separate database. And because large images now sit on Lovable's CDN, a downloaded copy has small pointer files where the images were, so they fail to load outside Lovable. If you plan to host it elsewhere, I covered what breaks in Lovable app not working, and how the backend works in Lovable Supabase integration.

Rules that keep the two-way sync working

Every edit in Lovable is committed and pushed to the repository, and commits pushed to the synced branch show up in Lovable. Pushing never changes your live site, though; only Publish in Lovable does. The rest is a handful of rules:

Don't rewrite history. No force-pushing, rebasing or squashing commits that are already on the synced branch; undo with a revert commit. Since October 5, 2026, if something does replace Lovable's commits, Lovable keeps a backup that only the project owner can restore.
Protected branches reject Lovable. If GitHub refuses a push, Lovable pushes to a branch called lovable-sync and asks you to merge it. If your team requires pull requests on main, point Lovable at its own branch instead.
Code you push isn't deployed. Lovable doesn't deploy a changed edge function or run a new migration that arrives through Git; ask Lovable in chat to do it.
Big files fail. GitHub rejects files over 100 MB, and Lovable itself can't save files over 10 MB.
Renaming is fine now. Renaming the repository, your username or the organization keeps the sync running. Older guides say otherwise because that was the rule until mid-2026.

If commits you pushed don't appear in Lovable, GitHub probably never told Lovable about the push. Lovable's official fix is to push any new commit, even an empty one. What I wouldn't do is disconnect and reconnect: reconnecting always creates a new repository, and in the reports it often made things worse.

Is the code really yours? Check whose account it is in

Lovable's FAQ says you own the projects and code you create. Its terms put that as between Lovable and the account holder, which is the account that built the project. If a freelancer or an agency built it in their account, who owns it between the two of you comes down to your contract. That's a question for a lawyer, not for me. What I can tell you is how to see where things stand.

The first part of a GitHub address is the owner: in github.com/someone/your-app, someone owns it. In the repository's Settings, Collaborators and teams lists everyone with access. Two details from GitHub's docs matter here. A personal account's repository has exactly one owner, and every collaborator gets write access, never admin. And if the repository sits in an organization, every owner of that organization can always see it. So if it lives in your agency's organization, being given access isn't the same as owning it, however friendly everyone is.

The apps I build live in GitHub repositories, and on any codebase the first thing I check is whose account it's in. If you're setting up your own, use a GitHub organization rather than a personal account: it can have several owners, and GitHub recommends at least two.

How to move it from your developer's account into yours

The order matters, because two of Lovable's rules interact. Transferring a repository keeps the sync only if the Lovable workspace already has a GitHub connection for the new owner. And moving a Lovable project to another workspace breaks its GitHub link, so reconnecting there creates a new repository with fresh history. This is the order I'd use:

Set up your side first, transfer the repository second, and close old access only after the live site checks out.

Transferring the repository

On GitHub the developer opens the repository's Settings, Danger Zone, Transfer, and types your username or organization. A transfer to a personal account sends you an email that expires if you don't accept within one day. Issues, pull requests, history, webhooks, secrets and deploy keys move with it, and old links and git addresses redirect, according to GitHub's transfer docs. Afterwards the original owner is added as a collaborator, so remove them when you're ready. If a transfer isn't possible, the developer can give you read access and you can mirror the repository into your account with its full history.

Taking over the Lovable project

If the developer built your app in a workspace of its own, this is the easy case: since September 7, 2026, the workspace's main owner role, which covers billing and domains, can be handed to any Lovable account by email, on every plan. Nothing moves, so nothing breaks. If your project sits in the developer's shared workspace, move it to yours with Move workspace. Its GitHub link breaks, so reconnect it in your workspace and keep the repository you were transferred as the history. A Cloud backend travels with the project, and your workspace pays for it from then on.

Avoid remixing as a handover. A remix is a separate copy that leaves behind the GitHub sync, secrets, database data, custom domain and collaborators.

Everything that isn't code

The domain, your own Supabase project if you use one, Stripe, and the email service each need to be in your name too. Then publish, check the live site page by page, and only after that remove the developer from the repository and the workspace. Exporting the code doesn't cancel anything either: Lovable says the subscription and any Cloud usage carry on until you change them.

When the sync breaks

"Install the GitHub App for to enable gitsync". Usually after a workspace transfer or a removed connection. Reconnect and install the app on the owner shown.
Every project on a connection disconnected at once. Someone uninstalled the Lovable GitHub app. Reinstalling works, but each project reconnects to a new repository.
Lovable lost access to one repository. Someone switched the app to Only select repositories and left yours out. Reconnect and add it back.
The repository was deleted. Restore it on GitHub, which is possible for 90 days, and the sync resumes. Otherwise reconnect to get a new repository.
You need a different GitHub account on the project. You can't switch it in place; disconnect and reconnect to the other account, which creates a new repository.

Own the accounts, not just a copy

A zip file or a repository in someone else's account is a copy of your app. Ownership is the repository, the Lovable project, the backend and the domain all sitting in accounts you control, with at least two people able to get in. Export early, check whose name is on each one, and move them in order. More guides like this are in Fix an AI-built app.

And if you'd rather hand it over, I take these on as client projects: send me what you have and where each piece lives.

Common questions

How do I export my Lovable project to GitHub?
Open Project settings, Git, GitHub, then Add connection. Pick your personal account or organization in the GitHub popup and click Install & Authorize. Lovable creates a new private repository there and starts two-way sync. The old GitHub button in the editor top bar was removed in May 2026.

Is Lovable's GitHub sync free?
Yes. Two-way sync with GitHub, GitLab and Bitbucket works on every Lovable plan, including Free. Downloading the whole codebase as a zip file needs a paid plan, and the Free plan code editor is read-only.

Can I connect an existing GitHub repository to Lovable?
No. Connecting always makes Lovable create a brand-new repository, and reconnecting later creates another one. The workaround is to let Lovable create its repository, then copy your existing code into it.

Can I rename or move the repository after connecting?
Renaming the repository, your GitHub username or the organization now keeps the sync running. Transferring it to another owner keeps the sync only if your Lovable workspace also has a GitHub connection for that new owner; otherwise Lovable disconnects the project. Many older guides still say never rename it, which was the rule until mid-2026.

Does the GitHub export include my database?
No. The repository holds your code, edge functions and database migration files, plus a .env file pointing at the live backend. It does not hold your data, uploaded files, secrets or the credentials behind Lovable AI, and since May 2026 large images live on Lovable's CDN instead of in the repository.

How do I get my Lovable project from my developer?
Get your own GitHub account and Lovable access first, add a GitHub connection for your account in the workspace that holds the project, then have the developer transfer the repository to you and hand over the project. Move the domain, backend and payment accounts too, and remove the developer's access last.

Why did my Lovable GitHub sync stop?
Usually GitHub never told Lovable about a push; the official fix is to push any new commit, even an empty one. Other causes are a protected branch, a removed or suspended GitHub app, or a repository moved to an owner the workspace is not connected to. Avoid disconnecting and reconnecting, which creates a new repository.

Lovable Stripe Integration: Built-in Payments or Your Own Stripe, and Why Payments Break

Tushar Bhendarkar — Tue, 20 Oct 2026 03:30:06 +0000

The worst Lovable payment bug is the one where the payment works. The customer is charged, Stripe shows the money, and the app never unlocks what they paid for. I went through 52 public reports of payments going wrong in Lovable apps, all from Reddit, and 14 of them were exactly that: a subscription status that never updated, a webhook that was never set up, or a signature check that rejected Stripe's message.

Getting a checkout button on the page is the easy part. Both apps I built this year, Launch Check and Client Approvals, take subscriptions through Stripe, and the work is in everything after the button: test and live mode, webhooks, and the moment the database is told someone has paid.

This guide covers both ways Lovable connects to Stripe, how to take each one live, and the places a successful payment gets lost.

What goes wrong with payments in Lovable apps

I sorted the 52 reports by the cause each thread confirmed. Fourteen were payments that succeeded without the app finding out. Four were test and live mode mixed up, four were checkout redirects and success pages, and three were people burning credits asking the AI to fix payments. The largest group, 25, was a mix, but nine of those were founders who couldn't use Stripe at all because of their country or type of business. I'll come back to that one.

Two ways to add Stripe to a Lovable app

Lovable's payments docs describe two separate paths. Built-in payments, launched in April 2026, have Lovable create and manage the payment account for you, on Stripe or Paddle. The older path connects your own Stripe account with a key.

	Built-in payments	Your own Stripe
Lovable plan	Pro or higher	Any plan, including Free
Who sets up the account	Lovable, on Stripe or Paddle	You, in your Stripe account
Fees	Stripe rates, or Paddle 5% + 50 cents; nothing added by Lovable	Stripe rates
Preview	Test mode with test cards	Whatever key you paste; a live key means real payments
Webhooks	Set up by Lovable	None by default; you add them yourself
Tax and verification	Paddle handles sales tax as merchant of record	You, in Stripe

My take: if this is your first paid product, use built-in payments, because the webhook work is the part people get wrong and Lovable does it for you. If you already run a business on Stripe, or you're on the Free plan, connect your own account and treat the webhooks as your job.

Built-in payments: setting up and going live

Only project or workspace admins and owners can turn built-in payments on, and Lovable recommends adding login first so purchases link to users. In the preview everything runs in test mode with test cards; the published app runs live, and live checkout doesn't work until the go-live steps are done. Products and prices copy from test to live when you publish, but discount codes don't, so create those in live separately. Don't edit products directly in the Stripe or Paddle dashboard either, which can leave test and live IDs out of step.

Going live on Stripe means claiming the Stripe account Lovable created for you, finishing Stripe's onboarding, then copying your products and the app to live. On Paddle it's a readiness check, identity and business verification, and a review of your domain, which usually takes about a day. The readiness check most often fails on missing privacy, terms or refund pages, or a site that isn't published. Lovable also suggests connecting a custom domain first, because the provider reviews the live address.

Your own Stripe account: setting up and going live

Paste a restricted key (rk_) or secret key (sk_) into the Connect Stripe form, never into the chat. Publishable keys (pk_) don't work. Lovable stores it as a backend secret called STRIPE_SECRET_KEY, and the payment code runs in edge functions. Stripe's key docs recommend restricted keys, which carry only the permissions you grant.

The trap is that this path has no separate test environment: the key you paste decides the mode. If you paste a live key, payments you make while testing in the preview are real. Use a test key until you're ready. To go live, Lovable's Stripe docs list three steps: submit a live key, switch the app to live price IDs (they're different from test ones), and make one real purchase on the published app.

Two more things to know. By default this path uses no webhooks: the app asks Stripe directly whether a signed-in user has an active subscription, and matches subscriptions to users by email address. And the customer portal, where people manage their subscription, has to be switched on once in the Stripe dashboard before it works.

When the payment works but the app does not know

Here is the path a payment takes after the customer clicks pay, and where it breaks:

Anything that breaks after step 2 means the customer paid and got nothing.

The endpoint is gone or doubled. Built-in payments register two webhook endpoints per environment. Lovable warns that deleting the app's endpoint silently breaks unlocking, and that a duplicate one you added by hand delivers events the app can't verify.
The wrong signing secret. Every webhook endpoint has its own secret, and test and live secrets differ even for the same address, according to Stripe's webhook docs. Stripe says the wrong secret is the most common reason signature checks fail; the one from the Stripe command line tool differs from the dashboard's too.
The body was changed. The signature is checked against the raw request. Anything that parses or re-formats the body first breaks the check.
The function expects a signed-in user. Stripe can't sign in to your app, so a webhook function that requires a logged-in user rejects it. In some threads that was the whole bug. The function has to be public and rely on the signature instead.
Upgrades and renewals aren't handled. customer.subscription.updated fires on renewals and plan changes, so handling only the first purchase misses them. Stripe also doesn't promise events arrive in order, and can send the same one twice, so record the event IDs you've already processed.

My rule is simple: the success page says thank you, and only a verified webhook unlocks anything. Stripe's own fulfilment guide says not to rely on the success page alone, and requires webhooks for subscriptions.

Test mode and live mode are two separate worlds

In Stripe, test and live objects are completely separate: a product or price created in test mode can't be used for a live payment, and test cards like 4242 4242 4242 4242 only work in test mode. Copying a test product to live creates a new product with new IDs, which is why an app still holding test price IDs fails the moment it goes live. The customer portal has separate settings for each mode too, so switching it on in test doesn't switch it on in live.

Before you take your first real payment

Publish the app, and connect a custom domain if you can.
Add privacy, terms and refund pages.
Check you're on live keys and live price IDs, with the live webhook secret if you use one.
Switch on the customer portal in live mode.
Buy your own product with a real card on the live site, and check it unlocks.
Upgrade, cancel and refund that test purchase, and check the app follows each change.

When Stripe is not an option

Nine of the reports were founders who couldn't use Stripe at all: their country isn't supported, Stripe wanted a registered company, or their kind of business wasn't accepted. Built-in payments can run on Paddle instead, which acts as the merchant of record: it sells to your customer on your behalf and handles VAT and sales tax, for 5% plus 50 cents per transaction (a flat 10% under $10). Stripe has its own merchant of record option, Managed Payments, in fewer countries. PayPal, Razorpay and other providers aren't built in and need custom code.

Disconnecting does not stop billing

One last warning from Lovable's docs. Disconnecting built-in payments is permanent and doesn't cancel subscriptions or refund anyone, so your customers keep being billed. If your app uses its own Supabase project, disconnecting your own Stripe leaves the secret key there, so the payment functions can keep charging. Switching providers doesn't migrate products, prices or subscriptions either. Cancel and clean up in Stripe first, then disconnect.

If your app is breaking in other places too, I wrote up the most common causes in Lovable app not working, and how the database side works in Lovable Supabase integration. And if you'd rather hand it over, I take these on as client projects: send me the app and what's going wrong with payments.

Common questions

How do I add Stripe to a Lovable app?
Either turn on built-in payments, where Lovable creates and manages a Stripe or Paddle account for you (Pro plan and up), or connect your own Stripe account by pasting a restricted or secret key into the Connect Stripe form, which works on any plan. Never paste a key into the chat.

Should I use built-in payments or my own Stripe account?
Lovable recommends built-in payments for most new projects: it handles the webhooks and keeps test and live separate. Connect your own Stripe if you already run a business on Stripe, are on the Free plan, or want to manage keys and webhooks yourself.

Why did the customer pay but my Lovable app did not unlock anything?
The app never got, or never accepted, Stripe's message that the payment succeeded. Common causes are a deleted or duplicated webhook endpoint, the wrong signing secret, a function that rejects Stripe because it is not signed in, and upgrade or renewal events that are not handled.

Does Stripe work in the Lovable preview?
With built-in payments the preview runs in test mode with test cards, and the published app runs live. With your own Stripe there is no separate test environment: the key you paste sets the mode, so with a live key, payments made in the preview are real.

How do I take my Lovable app's payments live?
With your own Stripe: switch to a live key, switch the app to live price IDs (they differ from test ones) and make one real purchase on the published app. With built-in payments: complete the provider's verification and readiness check, which needs privacy, terms and refund pages and a published site.

What if Stripe is not available in my country?
Lovable's built-in payments can run on Paddle instead, which acts as the merchant of record and handles sales tax and VAT, for 5% plus 50 cents per transaction. Other providers such as PayPal or Razorpay are not built in and need custom code.

Does disconnecting Stripe in Lovable cancel subscriptions?
No. Disconnecting built-in payments is permanent and does not cancel subscriptions or refund anyone, so customers keep being billed. With your own Supabase project, disconnecting your own Stripe leaves the secret key in Supabase, so payment functions can keep charging.

Lovable Supabase Integration: Cloud or Your Own Project, and How to Set It Up Safely

Tushar Bhendarkar — Sun, 18 Oct 2026 03:38:19 +0000

If you connect your own Supabase project to Lovable and launch as is, your sign-up emails won't reach your customers. Supabase's built-in email only sends to members of your own Supabase team, and only two an hour. It's one of a handful of settings the Lovable Supabase integration leaves to you, and an easy one to discover only when your first real customer tries to sign up.

For my last post I sorted 264 public reports of broken Lovable apps. Sixty-eight of them were about Supabase: logins, connections and who can see what. The biggest single cause was the database access rules, switched off or open to everyone (12 reports), followed by confusion between Lovable Cloud and your own Supabase project (6) and security warnings that were never fixed, or turned out to be noise (6).

I build on Supabase myself. Launch Check and Client Approvals both run on it, so this is the setup I use, written for a Lovable app: which backend to pick, how to connect it, the settings Lovable doesn't do for you, and how I test that one user can never see another user's data.

Lovable Cloud or your own Supabase project?

Lovable Cloud is Supabase, run for you. It's built on Supabase's open-source foundation, each project gets its own Supabase project behind it, and it's switched on by default, so most Lovable apps never need a separate Supabase account. Lovable's Supabase docs give three reasons to connect your own project instead: owning the account and billing, full Supabase dashboard access, or reusing a project you already have.

	Lovable Cloud	Your own Supabase project
Who runs it	Lovable	You, in your Supabase account
How you pay	Lovable credits	Your Supabase plan (free tier to start)
Where you manage it	Inside Lovable (Database, Users, Storage, Logs)	The Supabase dashboard
Login settings and Google sign-in	From the Lovable chat	In Supabase and Google Cloud, by you
Branded emails	Paid Lovable plans	Your own email server (custom SMTP)
Backups and pausing	Managed in Lovable	Managed in Supabase
Switching later	No automatic move either way	Moving onto Cloud is not supported

My rule: Cloud for a prototype or an internal tool, my own Supabase project for anything I'd sell or hand over to a client. Then the database, its bill and its backups are in my name, and I can open it without going through a builder.

Whichever you pick, decide early. There is no automatic move between the two in either direction. Since July 3, 2026 you can export a Cloud database and remove Cloud from a project, but removing it permanently deletes the Cloud data, storage, logins and functions. One more trap: Lovable turns Cloud on automatically when a feature needs a backend, because the permission defaults to Always allow. If you want your own Supabase, change it to Ask each time under Connectors, Cloud, Manage my agent's permissions, before you build anything.

How to connect your own Supabase project

Create a Supabase project. The free tier is enough to start, and the integration works on every Lovable plan.
Link your Supabase organization once. A Lovable workspace owner or admin does this; other members can then connect projects from it without their own Supabase account.
Connect the project. For a new app, click + in the prompt box, open Databases and pick your Supabase project. For an existing app with no backend yet, open More, Cloud and choose "Already have a Supabase project? Connect it here". That link disappears once Cloud is on.
Check the Cloud view. It should show your Supabase project's name and status, with links to its dashboard.

From then on Lovable writes database changes as migrations, shows them for your approval, runs them and saves them in supabase/migrations. It deploys edge functions, stores keys for services like Stripe as Supabase secrets, and creates storage buckets when a feature needs uploads. One Lovable project connects to one Supabase project. Several Lovable projects can share one Supabase project, but they overwrite each other's secrets, which Lovable now warns about.

Your app's browser code talks to the database directly. The access rules on each table are what stop one visitor reading another's data.

The settings Lovable leaves to you

On your own Supabase project, Lovable's docs are clear that login settings, providers and email live in the Supabase dashboard, not in Lovable. These are the three I set before anyone else signs up.

Emails: add your own email server

Supabase's email docs say that without custom SMTP, auth emails only go to members of your Supabase organization, and real users get "Email address not authorized". The built-in service also sends at most two emails an hour and isn't meant for production. Add any SMTP provider (Supabase lists Resend, Postmark, AWS SES and others) under Authentication, SMTP Settings. The limit then starts at 30 emails an hour, and you can raise it.

Login addresses: Site URL and redirect URLs

The Site URL is where users land after confirming their email, resetting a password or signing in with Google. It starts as http://localhost:3000, and it must be your live address. Every other address your app sends people back to has to be on the Redirect URLs list under Authentication, URL Configuration. If it isn't, Supabase quietly sends the user to the Site URL instead, which is the classic "sign-in sends me to localhost" bug. Supabase's redirect docs suggest wildcards for preview addresses and exact paths for production. For Google sign-in, add Supabase's callback address as an authorized redirect in Google Cloud. Without your own branding or a custom domain, Google's consent screen shows your-project-id.supabase.co instead of your app's name.

Pausing on the free plan

Supabase pauses free projects after about a week with too little database activity, after emailing you a warning. Restore it from the dashboard with Resume project; paid plans are never paused for inactivity. One catch from Supabase's API key docs: the old anon and service_role keys are being retired by the end of 2026, and since November 2025 a project restored from a pause comes back without them. If your app still uses a long key starting with eyJ, plan the move to the new publishable key before a pause forces it.

Row level security, in plain English

Your app's code runs in the visitor's browser and talks to the database directly, using a publishable key that is public on purpose. Supabase's own analogy: the publishable key is taped to the front door and only opens the lobby, and the secret key is the master key that stays in your pocket. What decides which rooms the lobby key opens is row level security (RLS): rules on each table that act like a WHERE clause added to every query.

Lovable writes these rules for you and checks them after schema changes, but it still tells you to verify every table yourself before going live. One reason: tables created with SQL, which is how migrations create them, need RLS switched on explicitly. This is the standard pattern for data that belongs to one user, from Supabase's RLS guide:

alter table public.notes enable row level security;

create policy "Owners read their notes"
on public.notes for select
to authenticated
using ( (select auth.uid()) = user_id );

create policy "Owners add their own notes"
on public.notes for insert
to authenticated
with check ( (select auth.uid()) = user_id );

create policy "Owners edit their notes"
on public.notes for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

create policy "Owners delete their notes"
on public.notes for delete
to authenticated
using ( (select auth.uid()) = user_id );

create index on public.notes (user_id);

One policy per action makes it obvious what each rule covers. WITH CHECK stops someone creating a row that belongs to another user, or moving a row to someone else when they edit it. Wrapping auth.uid() in a select and indexing user_id are performance fixes: in Supabase's own benchmark on 100,000 rows, wrapping auth.uid() took a query from 179 ms to 9 ms, and indexing user_id took another from 171 ms to under 0.1 ms.

Rules that look safe but are not

A rule that lets everyone through. using (true) means RLS shows as enabled, and everyone gets in anyway. A read rule "to anon using (true)" gives every signed-out visitor every row.
Several rules on one table. They combine with OR, so the most generous one wins.
Roles kept in user_metadata. Users can edit their own metadata, so never base access on it. Keep roles in app_metadata or a table.

Things that skip RLS completely

The secret key (the old service_role key) ignores every rule. It belongs in edge functions only, and Lovable warns that server code using it must check permissions itself.
SECURITY DEFINER functions run as their owner, usually postgres, and anyone can call them by default, including signed-out visitors.
Views run as their creator too. On Postgres 15 and up, create them with security_invoker = true.
Storage has its own rules on storage.objects. Tight table rules don't protect an uploaded file, and a broad read rule on storage lets anyone list every file.

Supabase's Security Advisor flags most of these, and its production checklist starts with it. One more date for your calendar: from October 30, 2026, Supabase stops exposing new tables to the API automatically in existing projects, according to its announcement. A new table without an explicit grant then returns "permission denied for table" (error 42501), even if its RLS rules are right. Lovable's docs don't mention this yet, so if a new table suddenly returns 42501 after that date, a missing grant is the first thing I'd check.

How I test that one user can never see another's data

When I built Client Approvals, I wrote a database test that signs in as different people and tries to break the rules. A team member should see only their own workspace. They try to comment on another workspace's request, attach a comment to the wrong item, post while pretending to be the client, and upload a file into another workspace's folder. Another user tries to read those comments and list those files. A signed-out client with a share link should see exactly one request and nothing else. Every one of those attempts has to fail, and the test rolls everything back when it finishes.

Sign in as each kind of person and try every action. Anything not marked allowed must fail, for files as well as tables.

The trap is testing in the wrong place. Supabase's SQL editor runs as the table owner, which ignores RLS, so a query that returns rows there proves nothing about what your users see. Use Supabase's user impersonation (in public beta), or run the check as a real role. This is the shape of it, inside a transaction so nothing is kept:

begin;

-- act as user B, signed in
select set_config('request.jwt.claims',
  json_build_object('sub', '<user B id>', 'role', 'authenticated')::text, true);
set local role authenticated;
select count(*) from public.notes where user_id = '<user A id>';  -- must be 0

-- act as a signed-out visitor
reset role;
select set_config('request.jwt.claims', json_build_object('role', 'anon')::text, true);
set local role anon;
select count(*) from public.notes;  -- must be 0

rollback;

If you don't write SQL, do the manual version: create two normal accounts, add something private in each, then try to open one account's records and files while signed in as the other, and again while signed out. Both attempts must fail.

When the integration stops working

These are the problems that come up most, from the reports and from Supabase's own troubleshooting docs, with the fix for each:

"Supabase connection issue" in Lovable. Lovable can't find the project: it was deleted, or the workspace lost access to the organization. Disconnect, or use Manage organizations and pick the project again. Disconnecting deletes nothing.
Nothing loads right after turning on RLS. RLS with no policies blocks everything through the API. Add the policies the app needs.
Data won't load on Cloud. Lovable's list: the instance is too small, a query error, RLS blocking the query, or a paused backend that needs Wake up.
"Email address not authorized". No custom SMTP yet. See the email section above.
Users land on localhost after signing in. The Site URL or Redirect URLs list is missing your live address.
"Too Many Requests" at sign-up. Supabase allows 30 sign-up and sign-in requests per 5 minutes per IP address by default.
"Infinite recursion" (error 42P17). Two tables' policies read each other, which is common with sharing features. Move the check into a helper function in a private schema.
A scan warning you can't clear. Leaked password protection needs Supabase's Pro plan, so it can't be switched on for a free project.

Moving from Lovable Cloud to your own Supabase

It's possible, by hand. Lovable's migration guide says to keep the app running on Cloud while you build the new backend, and to switch only when it's complete. The schema, RLS policies, functions, triggers and storage bucket policies move with the migration files. Auth providers, secrets, table data, storage files, users and edge functions you move yourself.

The Cloud export is a PostgreSQL backup file that you restore with pg_restore, with limits of 15 GB of storage and one export a day, and it leaves out storage files, edge function code and secrets. Cloud projects changed since October 7, 2026 record their changes as Drizzle migrations, which supabase db push won't run, so apply them in the order the guide lists. The final switch is two files in the Lovable project, .env and supabase/config.toml. Only remove Cloud after the new backend works, because removal deletes the Cloud data for good.

The integration is the easy part

Connecting Lovable to Supabase takes a few clicks. What makes it production-ready is everything around the connection: emails that reach real people, login addresses that point at your live site, and access rules that you've actually tried to break. If your app is already misbehaving, I wrote up what breaks most often in Lovable app not working, and there are more guides in Fix an AI-built app.

And if you'd rather hand it over, I take these on as client projects: send me the app link and what you need.

Common questions

Is Lovable Cloud the same as Supabase?
Lovable Cloud is built on Supabase, and each Lovable project gets its own separate Supabase project behind it. The difference is who runs it: with Cloud, Lovable manages it, you see it inside Lovable and pay in Lovable credits. With your own Supabase project, the account, dashboard and bill are yours.

Should I use Lovable Cloud or my own Supabase project?
Cloud is fine for prototypes and internal tools, and it is the default. Use your own Supabase project when you want to own the account and billing, use the full Supabase dashboard, or reuse an existing project. Decide early: there is no automatic switch between the two in either direction.

How do I connect Lovable to my own Supabase project?
A workspace owner or admin links your Supabase organization once. Then, for a new project, click + in the prompt box, open Databases and pick the Supabase project. For an existing project that has no backend yet, open More, Cloud and choose "Already have a Supabase project? Connect it here". That link is missing once Cloud is on.

Why are my Supabase emails not reaching users?
Without your own email server (custom SMTP), Supabase only sends auth emails to members of your Supabase organization, and at most 2 an hour. Real users get "Email address not authorized". Add an SMTP provider such as Resend or Postmark under Authentication, SMTP Settings before you launch.

Why does Supabase say permission denied for my table?
Error 42501 means the role has no grant on the table, which fails before any access rule runs. From October 30, 2026, new tables in existing Supabase projects are no longer exposed to the API automatically, so each new table needs an explicit grant. If nothing loads right after you turned row level security on, the table has no policies yet.

How do I check my Lovable app's row level security?
Run Supabase's Security Advisor, then test as real users. Do not trust the SQL editor: it runs as the table owner and ignores the rules. Use Supabase's user impersonation, a test that sets a user's role, or sign in as two normal accounts and try to open each other's records. Both attempts must fail.

Can I move a Lovable app from Lovable Cloud to my own Supabase?
Yes, by hand. Export the Cloud database, rebuild the schema in a new Supabase project, then move auth providers, secrets, files, users and edge functions yourself, and switch the app's settings last. Keep Cloud running until the new backend is complete, because removing Cloud permanently deletes its data.

Why Is My Base44 App Not Working? What 192 Real Reports Say

Tushar Bhendarkar — Sat, 17 Oct 2026 03:42:49 +0000

More than one in five people who said their Base44 app had stopped working had done nothing wrong. I went through 192 public reports of broken Base44 apps, from Reddit, Base44's own feedback board, Trustpilot and YouTube, and sorted each one by what actually caused it. The biggest group, 42 reports, was Base44 itself having an outage.

I did this because Base44 keeps coming up in the freelance work I look at: founders who built something real with it, then got stuck. Before telling anyone how to fix their app, I wanted to know what actually breaks.

The outage number matters because the usual reaction is to ask Base44's AI to fix the app. During an outage that can't work. It costs credits, and it can break code that was fine. Base44's own docs say credits aren't refunded when the AI gets something wrong.

So below are the causes in the order I'd check them, with the fix for each from Base44's documentation. If your app works but isn't showing up in Google, skip to the last section: I ran 45 live Base44 apps through my free checkers, and 8 of them were telling Google not to index them.

What 192 broken Base44 apps had in common

The reports run from August 2025 to October 2026: 88 Reddit threads, 73 posts on Base44's public feedback board, 16 Trustpilot reviews, and a handful from X, YouTube, GitHub, Hacker News and elsewhere. I put each one in a group based on the cause the thread confirmed, or the fix that worked.

The single biggest cause was Base44 itself being down. Login problems and preview-only issues come next.

What surprised me is how little of this is code. Three groups make up almost half of the list: Base44 outages, login and sign-up problems, and issues that only exist in the editor preview or your browser's cache. You don't fix any of those by rewriting your app. The rest are real problems in an app's settings or code, and many of them come down to a setting you can check in a few minutes. In 22 reports the cause was never found, or didn't fit any group.

Step 1: make sure it is not Base44, or your network

This is the step people skip. Before you touch the app, open status.base44.com and the r/Base44 subreddit. Base44's status feed lists 26 incidents between December 2025 and September 2026, five of them affecting previews or published apps. In the reports, people sometimes posted about an outage on Reddit before the status page showed anything. If your app and other people's apps broke at the same time, wait before you change anything.

When an outage ends, your browser can keep showing the old loading screen. After its September 9, 2026 incident, Base44 told users: "If you still see Loading your app, refresh the page or clear your browser cache." A hard refresh (Ctrl+Shift+R, or Cmd+Shift+R on a Mac) or a private window is the quickest test.

Then I'd open the app on a phone using mobile data, not Wi-Fi. Four of the reports turned out to be the visitor's internet provider blocking base44.app addresses: Comcast Xfinity's Advanced Security feature in the US, and an internet provider in the Philippines. The app was fine. Those visitors just couldn't reach it until they switched network or used a VPN.

Step 2: work out which kind of "not working" you have

"Not working" covers very different problems, and the fix depends on which one you have. Find the line that matches what you see, then jump to its section below.

What you see	Most likely causes	Check first
Nothing loads, for anyone, you included	Base44 outage, or a stale cache after one	Status page, hard refresh, another network
It loads for you but not for others	Not published, set to Private, a custom domain, or the visitor's network	App Visibility and the Publish button
It works in the preview, not in the live app	Not republished, test data, a backend function not redeployed	Publish panel, test data switch
Login, sign-up or Google sign-in fails	Login settings, emails in spam, Google OAuth setup	Login settings, spam folder
Data is missing or will not save	Data permissions, or a field that does not match its table	"Act as a user", App Logs
It worked yesterday, broke after an AI change	The AI edit itself	The Revert button, Version History
Emails, AI features or payments stopped	Credits ran out, plan limits, API keys	Credits page, plan, Secrets

Base44 also has a built-in check: type "Something is wrong" in the AI chat and it runs a diagnosis. Read what it says, but don't let it make several rounds of changes before you know the cause.

It works in the preview but not when published

The editor preview and the live app are two different things. According to Base44's editor docs, the live app only changes when you click Publish, and the preview is visible only to you and your collaborators. So my first question is always the boring one: did you click Publish after the change, and did you see the success message?

Test data is not real data

On the Builder plan and up, the preview can use a separate test database. The published app always uses real (production) data, and the two are completely separate, so records you created while testing will never appear in the live app. Base44 explains this on its test data page.

Backend functions and the browser cache

Base44's troubleshooting guide has an official checklist for when published changes don't appear: clear the browser cache, try another browser or device, confirm you clicked Publish, redeploy any backend function you changed, and check the error logs. A backend function you edited keeps running its old version until it's redeployed.

Sixteen reports were problems that existed only in the editor preview or the browser cache, such as a preview that kept going white after every AI change while the live app worked. Revert the last change first. If both the preview and the live app fail with a 500 error, Base44's guide calls that a server-side problem the builder usually can't fix, and that one is for support.

It loads for you but not for your users

This is the most confusing one, because everything looks fine when you test it. As the owner, you can see things your users can't.

Check App Visibility

Every app has a visibility setting in Dashboard, then Overview, then App Visibility: Public (anyone, no sign-in), Private (only people you invited) or Workspace (only your Base44 workspace). People who weren't invited to a Private app see an error or a request-access pop-up. Private applies to every page, including a landing page, and since February 6, 2026 new Private apps need the Starter plan or higher. The details are on Base44's access page. Invites also do nothing until the app is published, so an invited person can still be locked out of an unpublished app.

Data that only you can see

On any app with user accounts, this is the one I'd check first. Base44 protects each table with data permissions, and a blocked read doesn't show an error. Its security docs say a denied read behaves as if the data doesn't exist: the list just comes back empty. So a page can be full for you and empty for a normal user, with nothing in the console. The built-in Users table is a common trap: only the owner and collaborators can read it, so member profiles and leaderboards work for you and break for everyone else.

To see what a normal user sees, use "Act as a user" or "Test Permissions in preview", and run the Security scan, which flags missing or wrong rules. If saving fails with a 403 error, the user doesn't have permission to write to that table.

Custom domains

Ten reports were custom domain problems: stuck on "Pending verification", or a Bad Gateway error on the domain while the base44.app address worked. Base44's domain guide says to remove any AAAA (IPv6) records, allow up to 48 hours, and, if your DNS is on Cloudflare, set Base44's records to "DNS only" (grey cloud). Proxying them through Cloudflare can cause SSL errors and pages that load on base44.app but not on your domain. I always test the base44.app address first: if that works, the problem is the domain, not the app.

Login and sign-up problems

Login failures were the second biggest group, with 27 reports: verification codes that never arrived, invites that skipped the set-password step, Google sign-in errors and redirect loops. Base44's login docs cover the common causes:

Emails in spam. Verification and reset emails come from no-reply@base44-apps.com unless you set up your own sending domain. Ask users to check spam and allowlist that address.
A renamed reset page. Apps built since June 2026 have their own login pages, and the reset link always points to /reset-password. If the forgot-password or reset-password page is renamed or deleted, password resets break.
Google sign-in. By default the Google window says base44.com. Showing your own domain needs the Builder plan, a connected custom domain, the right redirect address and Google's approval, which can take up to five days.
Self sign-up on a Private app. If people can register but then see access denied, the app is probably Private. Make it Public and protect the pages that need a login.

It worked yesterday, and an AI edit broke it

Fifteen reports describe the same loop: the app worked, someone asked the AI for a change or a fix, and something else broke. Each new fix broke something new and spent more credits.

The most important rule comes from Base44's own troubleshooting guide: asking the AI chat to revert never undoes anything. Only the Revert button on a message, or Version History, rolls the app back. Base44 also advises trying the automatic fix once or twice, then switching to Discuss mode (about 0.3 credits a message) to describe the problem instead of letting the AI keep editing. One warning if you use GitHub sync: after you connect it, Version History can't restore versions from before the connection.

This is the group that worries me most, because the worst report in it wasn't a crash. In a client portal built on Base44, the AI "fixed" a display bug by changing how files were looked up, and two weeks after launch one company could see another company's files. Nothing looked broken, which is why nobody noticed.

When I built Client Approvals, I wrote a test that checks one workspace can never see another workspace's requests. After any AI change that touches data, that's the check I'd run by hand: sign in as a normal user and look at what they can see.

Features that quietly stop: credits, plans and keys

Some failures look like bugs but are really limits. Base44 has two kinds of credits, explained on its credits page: message credits, spent when the AI builds or edits your app, and integration credits, spent when the live app uses Base44's built-in services such as email, AI calls and file uploads.

Running out doesn't take the app down. Actions that use credits pause until your next reset. Since August 27, 2026 every email the app sends uses integration credits, so at the limit, workflow emails fail. Reading and writing your own data never uses credits.
Credits are shared. They come from one pool for the whole workspace, so one busy app can use them up for all your apps. The Free plan is capped at 5 credits a day.
Some features need a plan. Backend functions need the Builder plan or higher. Downgrading, or a disputed card payment that moves the workspace to Free, stops them, along with every integration that depends on them.
Keys and webhooks. API keys for other services go in Secrets. In one report, a function kept using an old key after it was changed, until the app was republished. Webhooks from services that can't sign in, such as Telegram or WhatsApp, return 403 unless the function is public.

Not showing up on Google? What I found on 45 live Base44 apps

Sometimes "not showing" means the app works fine but can't be found or shared. I build free website checkers, so I wanted to see how live Base44 apps look from the outside. I took 45 of them from Base44's own showcase, its templates and Hacker News posts, ran each one through my sitemap checker, Open Graph checker and security headers checker, and fetched each home page the way Googlebot does.

Eight apps their makers had shared publicly were telling Google not to index them.

Eight of the 45 apps sent Google a noindex instruction on their home page, which tells search engines to leave the page out of their results. These were apps their makers had shared publicly. Base44's SEO docs describe the usual source: switching off the main SEO setting adds noindex and stops Base44 from writing your page content into the version crawlers read. Three more apps showed Google a page with no text on it at all. If your app isn't showing up in Google, check that setting first.

The same docs say Base44's search features (sitemap, robots.txt and social previews) are built for apps on a custom domain. The free base44.app address can be crawled, but it isn't meant for search traffic, so if Google matters to you, connect your own domain.

Share previews were mostly there but often weak. Base44 builds them from the title, description and logo in your app settings, which is why many apps share a square logo, and many apps show a square image as a small thumbnail instead of a large card. Nineteen of the 40 share images were over 300 KB, and WhatsApp often skips images that big. My Open Graph checker shows exactly what your link looks like before you post it. On security, Base44 sets HTTPS correctly for every app, but 44 of 45 sent no Content-Security-Policy, the header that limits which scripts a page may run.

When to stop prompting and get help

Work through the causes in order: Base44 and your network first, then who can see the app, then its data and logins, and only then the code. It's the same rule I use for chatbots that give wrong answers: find the stage that breaks, and fix only that.

If you need Base44 support, send them the app link, the time it happened, the errors from your browser console and what App Logs shows (Dashboard, then Logs, with the Errors only filter). Their guide asks for exactly that.

If you're thinking of leaving Base44, know what export gives you. Downloading the code or syncing it to GitHub needs the Builder plan, and you get a standard React and Vite project. But that code still talks to Base44 for your data, logins and backend functions, so moving off Base44 means rebuilding the backend, not just downloading files. More guides like this one are in Fix an AI-built app.

And if you'd rather hand it over, I take these on as client projects: send me the app link and what's broken.

Common questions

Why is my Base44 app stuck on "Loading your app"?
Most often because Base44 itself is having trouble: check status.base44.com and the r/Base44 subreddit. If the outage is over and you still see the loading screen, do a hard refresh or clear your browser cache, which is what Base44 told users after its September 2026 incident. If it only fails on one network, try mobile data, because some internet providers have blocked base44.app addresses.

Why does my Base44 app work in the preview but not when published?
The live app only changes when you click Publish, so the usual cause is an edit that was never published. If you use test data, the preview reads a separate test database while the live app always uses real data. Backend functions also need to be redeployed after changes, and a stale browser cache can show an old version.

Why can other people not open my Base44 app?
Check that the app is published and that App Visibility (Dashboard, Overview) is set to Public. A Private app only lets in people you invited, and invites do nothing until the app is published. If you use a custom domain, test the free base44.app address too, and ask the person to try another network.

Why is data missing for some users of my Base44 app?
Usually data permissions. When a permission rule blocks someone from reading a table, Base44 returns an empty list with no error, so the page looks empty to them while it looks fine to you as the owner. The built-in Users table can only be read by the owner and collaborators, which breaks member profiles and leaderboards for regular users.

Does a Base44 app stop working when credits run out?
The app stays live, but features that use credits pause until your credits reset: built-in email, AI calls, file uploads and similar. Reading and writing your app's own data does not use credits. Credits are shared across every app in the workspace, so one busy app can use them up for all of them.

Why is my Base44 app not showing up on Google?
Check that the app is not telling Google to stay away: Base44 adds a noindex tag when its main SEO setting is switched off, and 8 of 45 live apps I checked had one. Base44's search features are also built for apps on a custom domain rather than the free base44.app address.

Can I export my Base44 app and host it myself?
You can download the code or sync it to GitHub on the Builder plan or higher, and you get a standard React and Vite project. But it still talks to Base44 for data, logins and backend functions, so moving fully off Base44 means rebuilding that backend, not just downloading the code.

Lovable App Not Working? What Breaks Between the Demo and Production

Tushar Bhendarkar — Thu, 15 Oct 2026 03:46:51 +0000

The Lovable apps in the most trouble were the ones that looked fine. I went through 264 public reports of Lovable apps breaking, from Reddit, Trustpilot, GitHub and Hacker News, and sorted each one by what caused it. The biggest groups were logins and database connections (37), Lovable itself being down (33), and apps that couldn't be found on Google (32). Right behind them were 31 reports about data that was exposed or at risk, which is the one problem a working app can hide completely.

I've shipped that kind of bug myself. In one of my own products, any logged-in user could see other customers' private data, because the app checked that you were logged in, but not that the data you asked for was yours. Nothing crashed and nobody complained, which is exactly why nobody had noticed.

That's the real gap between a demo and production. A demo only has to work for you, on your laptop, while you watch. Production has to work for every user, on every network, when Lovable has a bad day, when your credits run out, and when someone tries to open data that isn't theirs.

Below are the causes in the order I'd check them, each with the fix from Lovable's own documentation. I build on Supabase and Stripe myself, the same backend most Lovable apps run on, so I've added what I check on my own apps. At the end is what I found when I ran 53 live Lovable apps through my free checkers.

What 264 broken Lovable apps had in common

The reports run from 2025 to October 2026: 195 Reddit threads, 22 Trustpilot reviews, and the rest from Lovable's status page, GitHub issues, Hacker News, YouTube and security write-ups. I put each one in a group based on the cause the thread confirmed or, when nobody found one, the main symptom.

Data exposure sits near the top, and it is the one cause you cannot see from inside the app.

No single cause dominates, which is why "just ask the AI to fix it" fails so often. The top four groups make up about half of all reports, and the AI can't see most of them from inside the editor: an outage, a login setting in Supabase, how Google reads your site, or what a stranger can see in your database.

Step 1: check Lovable, not your app

When someone reports a published site is down, Lovable's own hosting docs say to check the status page first, and I agree. Open status.lovable.dev before you change anything. It tracks published sites (under Hosting) separately from the editor, so you can tell whether the problem is your app or Lovable. Its public history only covers the last 90 days, and in that window it lists 36 incidents, including previews and publishing failing on August 10, 2026 and published TanStack apps going down on August 4.

The expensive mistake is spending credits during an outage. At least four reports lost credits that way, on prompts and builds that failed because Lovable itself was having problems. And if the app fails for one person but not for others, try their phone on mobile data. Two reports turned out to be an internet provider blocking the app.

It works in the preview but not on the live site

The preview is your working copy. The live site is a snapshot from the last time you published. Lovable's publish docs are blunt about it: edits aren't live until you open the Publish dialog and click Publish changes, and a small dot on the Publish button means you have unpublished changes. Publishing from that dialog costs no credits, even at a zero balance. If the dialog shows "Build errors need fixing" instead, publishing is blocked until the build passes.

Sign-in works in the preview, fails on the live site

This is the one I'd check first. Lovable's login docs say sign-in that works in the preview but fails on the published app or a custom domain is usually caused by missing Site URL and redirect URLs. On Lovable Cloud they're updated automatically when you publish. On your own Supabase project they aren't, so you have to add your live address yourself.

The preview and the live app share one database

This surprises people. In Lovable, the preview and the published app use the same backend and the same data, so test records you create in the preview land in your real database. Separate test and live databases were tried in a beta from February 5, 2026, then withdrawn for new Cloud projects on March 24, 2026.

Login and database problems

Logins and database connections were the biggest group, with 37 reports: Google sign-in breaking, password resets failing, confirmation emails that never arrived, and projects that couldn't connect to Supabase. These are the usual causes:

Confirmation emails stop arriving. Lovable's login emails have an hourly sending limit, which is the first thing to check when many people sign up at once, and the default sender often lands in spam.
Google sign-in shows Lovable's name. With Lovable Cloud's built-in Google login, the sign-in screen can say Lovable instead of your app. The fix one thread landed on was setting up your own Google OAuth client and consent screen.
Auto-confirm is still on. Turning off email confirmation makes testing easier, but Lovable warns it lets anyone sign up with an address they don't own. Turn it back on before launch.
The Supabase project is paused. A paused or still-provisioning Supabase project can't be connected to Lovable, according to its Supabase docs.

The failure that does not look broken: your data is open

Most Lovable apps keep their data in a Supabase database. Each table has access rules, called row level security (RLS), that decide who can read or change which rows. If a rule is missing or too open, anyone who opens your app can read data that isn't theirs, and everything still looks normal to you.

Lovable says this plainly. Its security guide calls misconfigured RLS the most common cause of data exposure in Supabase-backed apps, and its Supabase docs tell you to check the rules yourself before going live. It does scan for it: a quick security scan runs on every publish and looks for tables without RLS and rules that let everyone through. But findings don't block publishing unless a workspace admin turns that on, the deeper code review is something you start by hand, and Lovable itself says its scans can't guarantee security.

One thread is worth knowing about: users could see each other's data even though RLS showed as enabled, because database functions, views and storage rules can get around it. A green check on one table isn't proof for the whole app.

The check I trust is the one I use on my own apps. When I built Client Approvals, I wrote a test that checks one workspace can never see another workspace's requests. You can do the manual version in a few minutes: create two normal accounts, add something private in each, then try to open one account's records while signed in as the other. Both attempts must fail.

It worked yesterday, and an AI edit broke it

Twenty-one reports describe the same loop: a small fix breaks two working things, and undoing it costs four or five more messages. Lovable's own debugging advice is to use Try to fix once or twice, describe the bug precisely, switch to Plan mode to find the cause, and revert if the fixes have tangled the code. Plan mode costs one credit a message and doesn't change code.

Every change creates a version you can restore from the History panel. But reverting restores code only: it doesn't roll back your database or its migrations, so check your data after a revert. My habit is to stop prompting after the second failed fix and read the actual error instead. For a blank published site, Lovable says to paste the browser console error into the chat, because the agent can't see errors outside the preview.

Credits ran out, and the backend went to sleep

Credits are the production surprise nobody plans for. Lovable's credits page says that when credits run out, building stops, AI features in your live app fail, and the Cloud database, storage and logins pause shortly after. The pages stay up, but anything that needs the backend stops. Adding credits may not restart it: you have to click Wake up under More, Cloud, Overview.

Since June 18, 2026, Lovable splits spending into Build credits, for prompting, and Run credits, for hosting and the backend of the live app. That's when people started reporting idle projects draining credits. In one thread, a background job sending email every five seconds kept a near-idle project busy.

I learned this on one of my own products: its AI features had no spending limit, so one bad day could cost any amount. I added a hard cap and a switch to turn the feature off. On Lovable, the equivalent is the usage limits and alerts added on October 7, 2026. Set them before you launch, not after the first surprise.

It broke when you moved it off Lovable

Twenty-three reports were apps that worked on Lovable and broke on Vercel, Netlify or Cloudflare. Most trace back to one change: since May 13, 2026, new Lovable apps are built with TanStack Start, which renders pages on a server. Lovable's self-hosting guide says these apps need a host that runs server code. That's why so many exported apps built fine and then returned 404 on every page.

Newer apps (TanStack Start): deploy to a host that runs server code, and check which host the build targets. In one report the build defaulted to Cloudflare, and switching it fixed Vercel.
Older apps (React and Vite): add a rewrite that sends every path to index.html, or direct links and refreshes return 404.
Settings: set VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY on the new host before you build, and add the new domain to your login redirect URLs.
What you take with you: exports include your code and database migrations, but not your data or stored files, and built-in AI calls keep running through Lovable's credits until you replace them with your own accounts.

Not on Google? What I found on 53 live Lovable apps

Thirty-two reports were about search: apps that never showed up on Google, or shared links with the wrong title and picture. Lovable explains the cause on its own blog: apps built before May 2026 send a nearly empty page and draw everything with JavaScript, and link previews are read from that raw page.

Lovable now pre-renders those older pages for Google and other verified crawlers, and since July 28, 2026 you can upgrade an older project to server rendering in place, typically for 10 to 35 credits. It also has a free SEO and AI search review that flags a missing sitemap, robots.txt and metadata.

I wanted to see what that looks like on real apps, so I took 53 live Lovable apps from Lovable's own pages, Product Hunt, Hacker News and Reddit launch posts, and ran them through my free sitemap checker, Open Graph checker and security headers checker. I only read what any browser receives.

Twenty-one apps give Google no list of their pages, and nine still share Lovable's default image.

Twenty-one of the 53 had no sitemap at any of the usual addresses, so Google gets no list of their pages. Nine still shared Lovable's default image, so a link to the app shows Lovable's branding instead of its own. Four pointed their share image at a file that doesn't load, and 13 used images over 300 KB, which WhatsApp often skips.

Two sitemaps listed pages on addresses that don't respond, one of them a custom domain that no longer loads while the app's lovable.app address still works. Lovable's domain docs list the usual causes: a leftover AAAA record, records left over from the previous host, or Cloudflare proxying the domain (set those records to DNS only). On security, all 53 were on HTTPS, but 51 sent no Content-Security-Policy and 50 could be loaded inside another site's frame. If you host the app yourself, my security headers checker shows which headers to add.

What actually changes between a demo and production

Every cause in this post has the same shape. The demo worked because it only had to work once, for you. Production has to keep working for strangers, with an empty credit balance, on a bad day for Lovable, and when someone tries data that isn't theirs.

I've been caught by a version of this too. One of my own products ran a daily job that published broken content about nine days a month, and nobody was told. It never threw an error. What fixed it wasn't a smarter job: it was checking the result before publishing, and sending an alert when it failed.

So before you launch: publish and open the live address in a private window, sign up as a brand-new user, try to open another user's data, set credit limits and alerts, and check what your link looks like when it's shared. If you also build on Base44, I did the same research in why is my Base44 app not working, and there are more guides in Fix an AI-built app.

And if you'd rather hand it over, I take these on as client projects: send me the app link and what's broken.

Common questions

Why does my Lovable app work in the preview but not when published?
The live site is a snapshot from your last publish, so open the Publish dialog and click Publish changes; a dot on the Publish button means you have unpublished edits. If sign-in fails only on the live site, your login redirect URLs are probably missing the live address. And remember the preview and the live app share one database.

Why is my Lovable app showing a blank page?
In the preview, click Refresh, then Shift+Refresh to restart it; a blank preview usually means an error in the app. On the published site, copy the error from your browser console into the chat, because the agent cannot see errors outside the preview. If the blank page is on Vercel or Netlify, see the next answer.

Why does my Lovable app break on Vercel or Netlify?
Apps created since May 13, 2026 use TanStack Start, which needs a host that runs server code, so a plain static deploy builds and then returns 404. Older React and Vite apps need a rewrite that sends every path to index.html. Either way, set your Supabase variables before the build and add the new domain to your login redirect URLs.

Is my Lovable app's data safe?
Only if your database access rules (row level security) are right. Lovable runs a quick scan on every publish, but findings do not block publishing by default and Lovable says its scans cannot guarantee security. Test it yourself: sign in as two normal users and try to open each other's records. Both attempts must fail.

What happens when Lovable credits run out?
The pages stay up, but AI features in the live app fail and the Cloud database, storage and logins pause shortly after. Adding credits may not restart the backend: click Wake up under More, Cloud, Overview. Set usage limits and alerts before launch so it does not happen by surprise.

Why is my Lovable app not showing up on Google?
Apps built before May 2026 draw their pages with JavaScript. Lovable now pre-renders them for verified crawlers, and you can upgrade an older project to server rendering in place. Run Lovable's free SEO and AI search review, and make sure you have a sitemap: 21 of the 53 live Lovable apps I checked had none.

Why do my Lovable app's links show the wrong picture when shared?
Lovable uses the share image you set, or a screenshot of the app, and older projects can still carry Lovable's default image: 9 of 53 apps I checked did. Set your own 1200 x 630 image, publish, then refresh the preview in each platform's debugger, since Slack and LinkedIn keep old previews.