DEV Community: Vishal Chauhan

How to Find Keywords Your New SaaS Can Actually Rank For: A 7-Step Free Keyword Research Guide for Beginners

Vishal Chauhan — Sun, 25 Oct 2026 11:29:30 +0000

In September 2026, a founder posted on r/SaaS that Google was not ranking their new site even though they had done the "basic SEO" work: meta titles, descriptions, indexing. Search Console showed 159 impressions and 1 click in 28 days, with an average position of 48. One of the most useful replies pointed out that people only search an app's name once they already know it; the real demand sits one step earlier, in someone describing the job they want done.

That is the core problem with keyword research for a first SaaS. If you built your app with Cursor, Claude Code, Lovable, Bolt, Replit or v0, you probably wrote pages about your product, in your words. Customers type their problem, in their words. This guide shows you how to find those words with free tools, check which ones a brand-new site can win, and turn them into a short list of pages to write.

Quick glossary

Keyword (or query): the exact words someone types into Google, like "how to send invoice reminders".
Search intent: what the person actually wants. To learn something, compare options, buy something, or go to a specific site.
Search volume: roughly how many times per month people search a keyword. Every tool estimates this differently.
Keyword difficulty (KD): a score from a tool that guesses how hard it is to reach page one. It is a guess, not a rule.
Long-tail keyword: a longer, more specific search with fewer searches, like "late payment reminder email template for freelancers". Easier for new sites.
SERP: search engine results page. The page Google shows after you search.
Impressions: how many times your site appeared in Google results, even if nobody clicked. You see this in Google Search Console.

Step 1: Write down your customers' problems in their words

Do not open a keyword tool yet. Start a text file of phrases real people use to describe the problem your app solves. Look in:

Your support emails, chat messages and signup survey answers.
Reddit threads where your users hang out. Search for the problem, not your product category.
Posts and replies on X complaining about the problem.
1-star to 3-star reviews of bigger competitors. Complaints are full of search phrases.

Copy phrases exactly. This guide uses a hypothetical example, an invoice tool for freelancers, whose notes might contain "client keeps paying late", "how do I remind a client to pay without sounding rude" and "invoice template that adds tax automatically".

An AI assistant can pull phrases out of messy notes. Just do not let it invent data:

Below are raw notes from support emails, Reddit threads and reviews about
[PROBLEM YOUR APP SOLVES]. My customers are [WHO THEY ARE].

1. Extract every distinct phrase a customer used to describe their problem
   or goal. Keep their original wording.
2. Add 10 more phrases a beginner in this audience might type into Google,
   and mark these clearly as "AI guess".
3. Do NOT include search volumes, difficulty scores or any numbers.
   I will check demand myself with real tools.

Notes:
[PASTE NOTES HERE]

Aim for 20 to 40 phrases. These are your seed keywords.

Step 2: Expand your seeds with free tools

Now check what people actually type. All of these are free as of October 2026:

Google autocomplete: type a seed into Google slowly and note the suggestions. Google's help page says predictions reflect real searches, but they also depend on your language, location and past searches. Use a private window.
People Also Ask and related searches: the question box on the results page and the related searches near the bottom. Each question is a possible section or page.
Google Trends: compare two or three phrases to see which is more popular and whether interest is growing. Google says Trends shows relative interest scaled from 0 to 100, not search counts, and very low-volume terms show as 0. So "0" does not always mean nobody searches it.
Google Keyword Planner: free inside a Google Ads account. Google's help says you must enter billing information to use "Discover new keywords", but you do not need to run a campaign. Expect volume ranges like "100-1K" instead of exact numbers if you are not spending; Google introduced this limited view for lower-spend accounts, and Google Ads community experts still describe it the same way. Ranges are fine for comparing ideas.
Bing Webmaster Tools Keyword Research: free with a Bing Webmaster Tools account. Enter a root keyword and get related keywords, question keywords and the top ranking URLs, filtered by country, language and device for any period in the last six months. The numbers are Bing data, so use them to compare phrases, not to predict Google traffic.
Ahrefs Free Keyword Generator: free, no account. Enter a seed and get keyword ideas, including questions, with estimated volumes.
Semrush free account: 10 keyword research queries per day, no credit card, per Semrush's own free-account page. Enough to check a shortlist.

Add everything relevant. In the hypothetical invoice example, you might add "how to politely ask for payment" and "what to do when a client doesn't pay". A list of 50 to 150 phrases is normal; the next steps cut it down.

Step 3: Check search intent by looking at the results page

A keyword tool cannot tell you what Google thinks the searcher wants. The results page can. For each promising phrase, search it in a private window and look at the top 10 results:

Mostly blog posts and guides? The intent is learn. You need a helpful article.
Mostly "best X tools" lists? The intent is compare. You need a list or comparison page.
Mostly product homepages and pricing pages? The intent is buy. Your landing or feature page fits.
Mostly templates, calculators or generators? People want a tool or template, not an essay.

Write the intent next to each keyword. If Google shows templates and you planned a long essay, the essay will struggle to rank.

Step 4: Judge whether a new site can compete

Most beginners skip this. A brand-new domain has no history and few links, so it cannot beat huge sites on broad terms. On the same results page, look for these signals.

Good signs (opportunity):

Reddit, Quora or forum threads in the top 10. Google could not find a great dedicated page.
Small blogs, personal sites or tiny tools ranking.
Results that only half answer the query or are outdated.

Bad signs (skip for now):

Every result is a big brand, a huge publisher or a well-known tool.
The top results are recent, excellent guides that answer everything.

Treat keyword difficulty as a hint; the SERP is the real test. Mark each keyword "go", "maybe" or "skip".

Step 5: Pick long-tail problem keywords and map one main keyword per page

Now pick your first 5 to 10 pages. Choose keywords that are:

Marked "go" in Step 4.
Close to your product. Someone searching it has the problem you solve.
Specific. Long-tail problem phrases beat broad category words for a new site.

For the hypothetical invoice tool, "invoicing software" is a skip (big brands everywhere), while "payment reminder email template for freelancers" could be a go if forums and small blogs rank.

Give each page one main keyword and a few close variations. If two keywords show almost the same top 10 results, they belong on the same page. If the results are different, they need separate pages.

AI can draft this grouping if you give it your real data:

Here is my keyword list with the intent and the "go/maybe/skip" verdict I
noted from looking at Google's results myself:
[PASTE ROWS: keyword | intent | verdict | volume range if I have one]

Group these into page ideas:
- One main keyword per page, plus up to 5 close variations.
- Put keywords together only if they share the same intent.
- Suggest a page type (guide, template, comparison, landing page).
- Ignore anything marked "skip".
- Do NOT invent or estimate search volumes or difficulty. Use only the
  numbers I gave you; leave blanks blank.
Output a table: page idea | main keyword | variations | page type | why.

Check its work against the real results pages, then keep everything in one sheet:

keyword,source,intent,verdict,volume_range,main_or_variation,target_page,status,date_published,gsc_impressions_28d,gsc_avg_position
payment reminder email template for freelancers,autocomplete,learn/template,go,(from your tool),main,/templates/payment-reminder-email,draft,,,
how to politely ask a client for payment,people also ask,learn,go,(from your tool),variation,/templates/payment-reminder-email,draft,,,
invoicing software,keyword planner,buy,skip,(from your tool),,,,,,

The rows above are hypothetical. Fill in volume ranges from Keyword Planner, Bing or another tool, and leave the Search Console columns empty until Step 7.

Step 6: Write each page to answer the query

You are not writing "SEO content". You are writing the best answer to one question. A simple checklist for each page:

PAGE CHECKLIST
[ ] Main keyword (or a natural version of it) in the title and the H1
[ ] First 2-3 sentences answer the question directly
[ ] Format matches what Google shows (template, steps, list, tool)
[ ] Covers the People Also Ask questions for this keyword
[ ] Includes something real: a screenshot, an example, your own steps
[ ] Clear, specific meta description written for humans
[ ] Links to 1-2 related pages on your site, and from your homepage or blog
[ ] Soft, relevant mention of your product where it actually helps
[ ] Page is indexable (not blocked, not noindex) and in your sitemap

If AI drafts the page, give it your notes, real examples and the questions you collected, then edit hard. A page that sounds like every other AI article adds nothing new.

For the hypothetical invoice tool, the reminder page would open with a ready-to-copy template, add first, second and final reminder versions, and only then mention the app can send them automatically.

Step 7: Measure in Google Search Console and iterate

Wait a few weeks after publishing; new pages take time to be crawled. Then open Google Search Console, go to Performance, and use:

Queries tab: the actual searches where your site appeared. Google's help explains you can switch metrics on for clicks, impressions, CTR and average position.
Pages tab: click a page, then open Queries to see which searches it shows up for.
Date range: the default is the last three months. Compare the last 28 days with the previous period.

What to look for:

Queries with impressions but position 8 to 20: improve that page. Add the missing section, make the answer clearer, link to it from other pages.
Queries you never planned for: these are new keyword ideas from real data. Add them to your sheet.
A page with zero impressions after several weeks: check it is indexed, then check the intent again in Step 3.

Update the sheet once a month and pick your next batch of pages from what you learn.

Common mistakes

Starting with your product category. Broad category words are owned by big brands. Start with problem phrases.
Trusting one volume number. Every tool estimates differently, and Keyword Planner often shows only ranges. Use numbers to compare, not to predict traffic.
Skipping the results page. Intent and competition are visible in the SERP, not in a spreadsheet.
Letting AI invent volumes. If an AI gives you exact search numbers without a data source, they are made up.
One keyword per blog post, ten posts on the same topic. Similar keywords with the same results belong on one strong page.
Giving up after two weeks. New sites need time.

Your action summary

Collect 20 to 40 customer phrases from support emails, Reddit, X and competitor reviews.
Expand them with autocomplete, People Also Ask, Trends, Keyword Planner, Bing and one free keyword generator.
Search every promising phrase and write down the intent.
Mark each keyword "go", "maybe" or "skip" based on who ranks.
Pick 5 to 10 long-tail problem keywords and give each page one main keyword.
Write each page to answer the query in the format Google already shows.
Check Search Console Performance after a few weeks and plan the next batch.

You do not need an expensive SEO tool to find your first keywords. You need your customers' words, an honest look at the results page and one small spreadsheet, so pick five problem phrases today and write the page that answers the first one this week.

How to Add Security Headers to Your AI-Built App: A 7-Step Beginner Guide to HTTPS and CSP

Vishal Chauhan — Sun, 25 Oct 2026 06:29:04 +0000

Your app is live, people are signing up, and then someone runs a free security scanner on it and sends you a screenshot full of red: "Missing Content-Security-Policy. Missing X-Frame-Options. Grade: D."

You are not alone. In October 2026, the team behind the ShipSniffer scanner ran a passive scan on 99 live apps launched on Show HN (mostly built with Lovable, Bolt, Replit and Cursor). By their count, 91% had no Content-Security-Policy and 88% had no protection against being framed by another site. They call their numbers indicative, since automated scans make mistakes, but the pattern is clear: AI builders get you to a live URL and skip this step.

The fix is mostly copy-paste. Security headers are a few lines of config that tell the browser how strict to be with your pages. This guide gives you 7 steps, with configs for Vercel, Next.js and Netlify, a note for Lovable and Bolt, and a prompt for your AI.

Quick glossary

Response header: a small line of text your server sends along with each page, like X-Content-Type-Options: nosniff. Visitors never see it, but the browser follows it.
HSTS (Strict-Transport-Security): tells the browser "only ever load this site over HTTPS, for the next N seconds."
CSP (Content-Security-Policy): a list of where your page is allowed to load scripts, styles, images and connections from. If an attacker manages to inject a script, a good CSP can stop it from running.
Report-only mode: a way to test a CSP without blocking anything. The browser just complains in the console.
Clickjacking: another site loads your app invisibly in an iframe and tricks users into clicking your buttons. frame-ancestors and X-Frame-Options stop this.

One honest note before we start: headers are a safety net, not a lock. They do not fix a database with no access rules or a secret key in your frontend. If you use Supabase, do the Row Level Security lockdown first.

Step 1: Check what your site sends today

Many hosts already send some headers, so look first. Open a terminal and run this against your live URL (not the editor preview):

curl -sI https://yourapp.com | grep -iE "strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy"

curl -I asks for the headers only. The grep part filters the list down to the six headers this guide covers. No output means none of them are set.

Some real defaults, so you know what to expect:

Vercel's docs say custom domains get Strict-Transport-Security: max-age=63072000; automatically, and .vercel.app URLs get a preloaded version.
Netlify says it redirects HTTP to HTTPS and sends HSTS on its netlify.app subdomains.
When I ran curl on a lovable.app response and a bolt.host app on October 25, 2026, both already sent HSTS, X-Content-Type-Options: nosniff and Referrer-Policy: strict-origin-when-cross-origin. The Bolt app also sent a minimal CSP. Neither sent a full CSP or frame protection. Platform defaults change, so check your own app.

Write down what you found:

Header check (date: ____ )   URL: ____________________
Strict-Transport-Security:  yes / no   value: ________
Content-Security-Policy:    yes / no / report-only
X-Frame-Options or frame-ancestors: yes / no
X-Content-Type-Options:     yes / no
Referrer-Policy:            yes / no   value: ________
Permissions-Policy:         yes / no

Step 2: Add the four easy headers

These four almost never break anything, so ship them first:

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: DENY

What each one does, in plain words:

nosniff stops the browser from guessing a file's type. MDN notes it makes the browser block a script or stylesheet whose content type doesn't match. It is the only valid value.
strict-origin-when-cross-origin sends other sites only your domain (not the full page URL) when someone clicks a link out. It's already the browser default, but setting it stops scanners flagging it.
Permissions-Policy with () turns a feature off for your page and every iframe in it. Only list features you don't use. If your app uses the camera, leave camera out.
X-Frame-Options: DENY blocks other sites from framing you. Use SAMEORIGIN if your own site needs to iframe its own pages.

Vercel (any framework) - create vercel.json in the project root:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" },
        { "key": "X-Frame-Options", "value": "DENY" }
      ]
    }
  ]
}

Next.js - you can use headers() in next.config.js instead:

module.exports = {
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          { key: 'X-Content-Type-Options', value: 'nosniff' },
          { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
          { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
          { key: 'X-Frame-Options', value: 'DENY' },
        ],
      },
    ]
  },
}

Netlify - add a plain text file named _headers to your publish folder. For a Vite app, put it in public/ so the build copies it into dist/:

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  X-Frame-Options: DENY

One Netlify catch from its docs: these custom headers don't apply to responses from functions, edge functions or server-rendered pages. Those need to set headers in code.

Step 3: Get HSTS right (and skip "preload" for now)

HSTS is hard to undo. Once a browser sees max-age=63072000 (two years, in seconds), it refuses plain HTTP for your domain for that long.

Rules I'd follow:

If your host already sends HSTS (Step 1), leave it alone. A Netlify forum thread shows that adding your own can produce two HSTS headers, which can confuse browsers and fails the preload check.
If you must add it, only do so once every page and subdomain works on HTTPS:

Strict-Transport-Security: max-age=63072000; includeSubDomains

Leave out preload unless you've read hstspreload.org. Netlify's docs warn that preloading "is not easily reversible." includeSubDomains also covers things like blog.yourapp.com, so make sure they all have HTTPS too.

Step 4: Start your CSP in report-only mode

A CSP is the most useful header and the easiest to get wrong. A strict policy pasted blindly will block your analytics, your fonts, your Supabase calls and maybe your whole app. So you test it first with Content-Security-Policy-Report-Only, which MDN describes as monitoring violations "without enforcing" them. Vercel's own security headers guide recommends the same start.

A beginner starter policy (one line in the real header):

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' https://YOUR-PROJECT.supabase.co wss://YOUR-PROJECT.supabase.co; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'

Swap YOUR-PROJECT for your Supabase project ID, or delete it if you don't use Supabase. The wss:// part is for realtime connections.

Add it with the same config file as Step 2. Then:

Deploy, open your live app in Chrome, and open DevTools (right-click, Inspect, Console tab).
Click through everything: sign up, log in, pay, upload, every main screen.
Look for messages starting with [Report Only] Refused to.... Each one names a blocked source and which directive blocked it.
Add each legit source to the right directive. For example, if Google Fonts shows up, add https://fonts.googleapis.com to style-src and https://fonts.gstatic.com to font-src.

Hypothetical example: your console says a script from https://plausible.io was refused under script-src. You'd add https://plausible.io to script-src, and probably to connect-src too, since analytics scripts send data back.

Chrome may also warn that a report-only policy has no reporting endpoint. That's fine here; the console is your report. (MDN covers the report-to setup if you want reports emailed or logged later.)

Next.js heads-up: Next.js injects small inline scripts, so script-src 'self' will report a lot. The official Next.js CSP guide offers two paths: 'unsafe-inline' in next.config.js (simpler, weaker), or nonces generated per request in proxy.ts (stronger, but forces dynamic rendering). In local dev, React also needs 'unsafe-eval'. Production does not.

Also note: a CSP in a <meta> tag can't do report-only mode or frame-ancestors, according to MDN. Use real headers.

Step 5: Switch CSP to enforce mode

After a few days with no new console messages during normal use, rename the header from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the same value.

Then:

Deploy and click through the full flow again, watching for anything that breaks.
If something breaks, add the missing source. Don't "fix" it with * or 'unsafe-eval'; Vercel's guide warns against both.
Keep X-Frame-Options: DENY from Step 2. Modern browsers use frame-ancestors 'none', and the Next.js docs call X-Frame-Options superseded by it, but keeping both is harmless and covers old browsers.

If you need your app embedded somewhere (say, a widget on a customer's site), change frame-ancestors 'none' to frame-ancestors 'self' https://customer-site.com and drop X-Frame-Options: DENY for that path.

Step 6: Lovable, Bolt and other hosted builders

I couldn't find a custom response header setting in Lovable's hosting docs, and third-party reviews of Bolt hosting report the same (checked October 2026). Your options:

Accept the defaults for a prototype. Step 1 shows they already cover HTTPS, HSTS and nosniff.
Deploy the code to Vercel or Netlify. Lovable's docs explain how to deploy its projects to Vercel, Netlify or Cloudflare Pages, and Bolt still offers a Netlify option. Then use the Step 2 configs.
Put Cloudflare in front of your custom domain and add headers with a Response Header Transform Rule.

Here's a prompt for Cursor, Claude Code or any AI coding tool:

Add HTTP security headers to this app. We deploy on [Vercel / Netlify / other].
1. Tell me which file to use (vercel.json, next.config.js, or public/_headers) and why.
2. Add: X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin,
   Permissions-Policy disabling camera, microphone and geolocation (unless we use them -
   search the code first), X-Frame-Options DENY.
3. Do NOT add Strict-Transport-Security if our host already sends it.
4. Add a Content-Security-Policy-Report-Only header (not enforced). List every external
   domain the code loads scripts, styles, fonts, images or API calls from, and include
   them in the right directives. Do not use * or 'unsafe-eval'.
5. Change only the config file. Show me the diff and a curl command to verify.

Step 7: Verify, then re-check after big changes

After each deploy:

Re-run the curl command from Step 1 on your homepage and one logged-in page.
Run a free scanner: securityheaders.com or Mozilla's HTTP Observatory. Both grade your headers and explain what's missing.
Do one last full click-through.

Disclosure: I work on Siteory. Its full audit (you get one free with a verified account at siteory.co) checks these same headers on your HTML page, including weak CSP values like unsafe-inline, and gives you a fix prompt to paste into your AI tool. As its own methodology page says, header work rarely moves rankings, and a scan is not a penetration test.

Re-check whenever you add a new script, analytics tool, payment provider or CDN, since each one can trip a working CSP.

Common mistakes

Pasting a strict CSP straight into enforce mode. Blank pages and broken logins. Always start report-only.
Testing the editor preview instead of the live URL. Previews often run on a different domain with different headers.
Adding HSTS preload on day one. Hard to undo. Skip preload until you're sure.
Fixing CSP errors with * or 'unsafe-eval'. That turns the policy back into a sign that says "anything goes."
Using a <meta> CSP and thinking you're covered against clickjacking. frame-ancestors only works as a real header.
Disabling features you use. camera=() will break your video-call feature. Search your code first.
Assuming headers replace real security. They don't fix missing database rules or leaked keys.

Your action summary

Run curl -sI on your live URL and fill in the header check.
Add nosniff, Referrer-Policy, Permissions-Policy and X-Frame-Options with your host's config.
Leave HSTS to your host if it already sends it. No preload yet.
Add a CSP in report-only mode and fix every console warning.
Switch to enforced CSP after a few clean days.
On Lovable or Bolt, keep the defaults or deploy the code where you control headers.
Verify with curl and a free scanner, and re-check after every new integration.

Most of this is one config file and one afternoon. Do the four easy headers today, start the report-only CSP tonight, and that red scanner screenshot turns into something you'd be happy to share.

How to Find Out Where Your SaaS Signups Come From: A 7-Step Beginner Guide to Simple Analytics

Vishal Chauhan — Sat, 24 Oct 2026 11:31:06 +0000

In March 2026, a founder posted on r/SaaS that they were finally getting their first users but had no idea where those users came from. Google Analytics showed mostly "Google" and "direct", and they summed it up as growth "happening in the dark". If you built your app with Lovable, Bolt, Replit, v0, Cursor or Claude Code, there is a good chance you are in the same spot: people sign up, and you are guessing why.

Guessing is expensive. You keep posting where it feels busy instead of where signups actually come from. This guide fixes that in 7 steps, with free or cheap tools, a little copy-paste code and AI prompts you can hand to your coding tool. It takes an afternoon, and the setup is one-time.

Quick glossary

Pageview: one page loaded by one visitor.
Event: anything you choose to count, like "signup" or "created first project". A pageview is also an event in most tools.
Referrer: the site a visitor clicked from, sent by the browser. Sometimes it is missing.
UTM parameters: tags you add to the end of a link, like ?utm_source=reddit, so your analytics knows where the click came from even when the referrer is missing.
Direct (or "Direct / None"): visits with no referrer and no UTM. Plausible's docs explain this bucket includes clicks from email, messaging apps like WhatsApp, Slack or Discord, and bookmarks. People often call it "dark traffic".
First touch: the very first place a person came from, before they ever signed up.
Conversion: a visitor doing the thing you care about, like signing up or paying.

Step 1: Write down 3 questions and 3 events

Most beginners install a dashboard, look at a pretty traffic chart, and learn nothing. Start with the questions instead. For an early SaaS, three are enough:

Which channel brings visitors who actually sign up?
Which channel brings signups who get value (their "first win")?
Which channel brings paying customers?

Each question needs one event. Keep the names short, lowercase and boring, and never rename them later.

EVENT PLAN (copy into your notes)
signup        -> account created successfully
first_win     -> user did the core thing once (e.g. created first project)
paid          -> first successful payment
Rule: lowercase, underscores, max 3-5 events for now.

If you already track an activated_at date from an onboarding setup (like in our onboarding emails guide), your first_win event is the same moment.

Step 2: Pick one simple tool (and know its limits)

You do not need Google Analytics 4 to answer three questions. A lightweight, privacy-friendly tool is easier to read. Here is what the main options include, as of October 2026, from each vendor's own pricing or docs page:

Umami Cloud Hobby: $0, 100K events per month, 1 website, 6 months of data. Includes custom events, UTM reports, goals, funnels and an attribution report. Umami says it uses no cookies, so no cookie banner is needed for it. Note that every pageview and every stored event property counts toward the 100K.
Plausible: 30-day free trial, then Starter at $9/month for up to 10k monthly pageviews, with goals and custom events. No cookies.
PostHog: free tier with 1M analytics events per month, no card required. It sets cookies by default, but has a cookieless mode you can switch on.
Vercel Web Analytics (Hobby plan): free, but custom events need the Pro plan and UTM parameters need the Web Analytics Plus add-on. So on Hobby you cannot track signups or UTMs.
Lovable's built-in Analytics: free and cookieless, groups visits into channels like Social, Referral and Direct. But Lovable's own docs say that to track steps like sign-up and purchase you should connect a dedicated tool such as PostHog.

This guide uses Umami because the free plan covers everything here. The same ideas work in Plausible or PostHog; only the one-line tracking call changes.

Step 3: Install it on your real domain only

Create a free Umami Cloud account, add your website, and copy the tracking snippet it gives you. It looks like this. The data-domains attribute tells Umami to only count visits on the domains you list, so your localhost and preview URLs do not pollute the numbers.

For Vite apps (most Lovable and Bolt projects), paste it inside <head> in index.html:

<script defer src="https://cloud.umami.is/script.js"
  data-website-id="YOUR-WEBSITE-ID"
  data-domains="yourapp.com,www.yourapp.com"></script>

For Next.js (common with v0 and Cursor), use next/script in app/layout.tsx:

import Script from "next/script";

// inside <body> in your root layout
<Script
  src="https://cloud.umami.is/script.js"
  data-website-id="YOUR-WEBSITE-ID"
  data-domains="yourapp.com"
  strategy="afterInteractive"
/>

Umami's docs say single-page apps are tracked automatically when the URL changes, so you do not need extra code for page navigation. Or hand it to your AI tool:

Add the Umami analytics script to this app so it loads on every page.
Script: <paste the snippet from your Umami dashboard>
Rules: add it once only (index.html head for Vite, or next/script in
the root layout for Next.js). Keep data-domains so it only tracks
yourapp.com. Do not add any other analytics or cookies.
Show me the exact file you changed.

Then open your live site, open DevTools, go to the Network tab, and check that script.js loads. If it does not show up, try with your ad blocker off; Umami's docs note ad blockers can block it.

Step 4: Track the signup at the moment it succeeds

The most common mistake is firing "signup" when someone clicks the button. Clicks fail: wrong password format, email already used, network error. Fire the event only after your auth call returns without an error.

With Supabase auth it looks like this:

const { data, error } = await supabase.auth.signUp({ email, password });

if (!error) {
  window.umami?.track("signup");
}

Do the same for first_win right after the core action saves successfully, and for paid on your payment success page or webhook-confirmed screen. If you use PostHog instead, the line is posthog.capture("signup"). In Plausible it is plausible("signup"), and you must also create a goal with the exact same name in the dashboard, because Plausible does not show events without a matching goal.

Never put emails or names into event data. Umami's docs warn against sending personal information, and you do not need it to answer your three questions.

Step 5: Save each user's first source in your database

Analytics tools show trends, but they cannot tell you "user 47 came from Reddit and paid". For that, store the source on the user record. Two parts:

Part A: remember where they first came from. This runs on every page load and only saves the first visit's source:

// src/lib/firstTouch.js
const KEY = "first_touch";

export function saveFirstTouch() {
  if (localStorage.getItem(KEY)) return;
  const p = new URLSearchParams(window.location.search);
  let ref = "";
  if (document.referrer && !document.referrer.includes(window.location.hostname)) {
    ref = new URL(document.referrer).hostname;
  }
  localStorage.setItem(KEY, JSON.stringify({
    signup_source: p.get("utm_source") || ref || "direct",
    signup_medium: p.get("utm_medium") || "",
    signup_campaign: p.get("utm_campaign") || "",
    landing_page: window.location.pathname,
  }));
}

export function getFirstTouch() {
  return JSON.parse(localStorage.getItem(KEY) || "{}");
}

Part B: attach it at signup. Supabase lets you pass extra user metadata in signUp, and it is stored on the user:

const { data, error } = await supabase.auth.signUp({
  email,
  password,
  options: { data: getFirstTouch() },
});

For Google sign-in, call supabase.auth.updateUser({ data: getFirstTouch() }) once after the first login if signup_source is missing. Users can edit their own metadata, so treat it as a marketing hint, never for permissions.

Also add one optional dropdown to your signup form: "How did you hear about us?" with 5-6 options (Google, Reddit, X, a friend, a newsletter, other). It catches the people your links cannot: the friend who sent your URL on WhatsApp shows up as "direct" in analytics, but the user will happily tell you "a friend".

AI PROMPT
Add an optional "How did you hear about us?" select to the signup
form with options: google, reddit, x, friend, newsletter, other.
Save the value as heard_from in the Supabase signUp options.data,
together with the object returned by getFirstTouch().
Call saveFirstTouch() once when the app loads.
Do not make the field required.

A privacy note: you are storing a small marketing value in the browser and on the user record. Mention it in your privacy policy, and if you have EU users, check whether your consent setup covers it.

Step 6: Tag every link you share with UTMs

Referrers get lost all the time. UTMs fix that for links you control. Google's own help page says to always use utm_source, utm_medium and utm_campaign, and warns that values are case-sensitive, so stick to lowercase.

LINK TEMPLATE
https://yourapp.com/?utm_source=SOURCE&utm_medium=MEDIUM&utm_campaign=CAMPAIGN

SOURCE   = the exact place: reddit, x, linkedin, newsletter, youtube
MEDIUM   = the type: social, community, email, referral, video
CAMPAIGN = what you were doing: launch_oct, tutorial_post, bio_link

Rules:
- lowercase only, underscores instead of spaces
- one name per platform forever (always "x", never "twitter" or "X")
- one row per link in a sheet: date, where posted, full link, notes

Put a tagged link in your X bio, your newsletter, your Dev.to profile and every community post. Keep a simple sheet of every link so the numbers make sense later. If you use a link shortener or redirect, check that the final URL still has the ?utm_... part, because Plausible's docs note UTMs are lost if a redirect drops the query string.

Step 7: Test it, then review one table every week

First, test end to end:

Open your site in a private window with ?utm_source=test&utm_medium=test&utm_campaign=test.
Sign up with a throwaway email.
Check Umami: you should see the visit under UTM and one signup event.
Check Supabase: the new user's metadata should show signup_source: "test".

Then, once a week, run this in the Supabase SQL editor:

select
  coalesce(raw_user_meta_data->>'signup_source', 'unknown') as source,
  coalesce(raw_user_meta_data->>'heard_from', '-') as heard_from,
  count(*) as signups
from auth.users
where created_at > now() - interval '7 days'
group by 1, 2
order by signups desc;

Compare it with Umami's numbers. Your database count is often higher, because ad blockers can stop analytics scripts from loading. Trust the database for "how many", and use analytics for "which pages and links".

Spend 15 minutes on it and make one decision. Hypothetical example: if Reddit sent 400 visitors and 3 signups while a single tutorial post sent 90 visitors and 6 signups, write one more tutorial this week instead of five more Reddit comments. One founder in r/SaaSMarketing shared self-reported numbers like this in May 2026, where a smaller SEO channel produced more paying users than a bigger Reddit one. Your numbers will differ; that is the point of measuring.

Common mistakes

Tracking the click, not the success. Fire signup only when the auth call returns no error.
Counting your own visits. Use data-domains and test on a private window, not your daily browser.
Messy UTM names. "Twitter", "twitter" and "x" become three sources. Lowercase, one name per platform.
Expecting UTMs to catch everything. DMs, emails and bookmarks still show as direct. That is what the "How did you hear about us?" field is for.
Putting personal data in events. No emails or names in analytics.
Picking a free plan that cannot do the job. Vercel Hobby has no custom events or UTMs; Lovable's built-in analytics does not track signups.
Looking daily and changing everything. With small numbers, one week is the minimum before you decide anything.

Your action summary

Write your 3 questions and 3 events: signup, first_win, paid.
Pick one tool (Umami Hobby is free as of October 2026) and create your site.
Install the script with data-domains and confirm it loads in DevTools.
Fire signup only after Supabase returns no error, plus first_win and paid.
Save first-touch source and "How did you hear about us?" on the user record.
Tag every shared link with lowercase UTMs and log it in a sheet.
Test with utm_source=test, then run the weekly SQL and make one decision.

You do not need a data team to stop guessing. Three events, one stored source and one weekly table will tell you more about your growth than any traffic chart, so set it up today and let next week's numbers pick your next move.

How to Fix a Slow Vibe-Coded App: A 7-Step Beginner Guide to Faster Pages and Queries

Vishal Chauhan — Sat, 24 Oct 2026 06:31:20 +0000

Your app worked fine when it was just you clicking around. Then real people showed up, and now pages hang on a spinner, images pop in one by one, and someone tells you "it feels slow on my phone."

This is one of the most common problems with apps built in Lovable, Bolt, Replit, v0, Cursor or Claude Code. AI builders are great at "make it work," but they don't think about how much data, how many images and how much code your app sends to a stranger on a phone. In a January 2026 r/lovable thread, a developer described a client app that slowed to 30+ second page loads at around 1,000 users. The causes were boring: one endpoint returning every record, a database call per row, and no pagination.

The good news: boring problems have boring fixes. This guide walks you through 7 steps, in the order I'd do them, with copy-paste prompts and short code. You don't need to be a performance expert.

Quick glossary

LCP (Largest Contentful Paint): how long until the biggest thing on screen (usually a hero image or headline) shows up. Good is 2.5 seconds or less.
INP (Interaction to Next Paint): how fast the page reacts when someone taps or clicks. Good is 200 milliseconds or less.
CLS (Cumulative Layout Shift): how much stuff jumps around while loading. Good is 0.1 or less.
Index: a lookup table for your database, like the index at the back of a book. Without one, the database reads every row to find what you asked for.
Bundle: the JavaScript file(s) your app ships to the browser. Bigger bundle, slower start.

These three LCP/INP/CLS numbers are Google's Core Web Vitals. Google says a page passes when 75% of visits hit "good" on all three, measured separately on mobile and desktop.

Step 1: Measure before you change anything

If you skip this, you'll ask your AI to "make it faster," it will change 40 files, and you won't know if anything improved.

Do this once and write the numbers down:

Open PageSpeed Insights, paste your live URL (not the editor preview), and check the Mobile tab. Note LCP, INP (if shown), CLS and the overall score.
Run it on your 2-3 most important pages too: the landing page, the main logged-in screen, and any page with a list or feed.
Open Chrome DevTools (right-click, Inspect), go to the Network tab, tick Disable cache, set throttling to a slower preset like Fast 4G, and reload. Note how long until the page looks usable.

One thing that confuses beginners: PageSpeed Insights shows two kinds of numbers. "Discover what your real users are experiencing" is field data from real Chrome users, and a new or low-traffic app usually won't have it yet. The lab numbers below it come from a single simulated test. Use the lab numbers as your before/after scoreboard.

Save this as a note in your project:

Speed baseline (date: ____ )
Page: /            Mobile score: __  LCP: __s  CLS: __
Page: /dashboard   Mobile score: __  LCP: __s  CLS: __
Page: /feed        Mobile score: __  LCP: __s  CLS: __
Slowest thing I noticed by eye: ____________________

Step 2: Find out what's actually heavy

Stay in the Network tab and look for the biggest offenders. Click the Size column to sort largest first, then use the filter buttons:

Img: are any images over a few hundred KB? Are 1-2 MB photos being squeezed into small cards?
JS: is one JavaScript file huge?
Fetch/XHR: these are your database and API calls. Are there dozens of them on one page? Does one take seconds, or return a giant response?

In an April 2026 r/lovable thread about a card feed that got slower as you scrolled, a commenter suggested exactly this check: filter by Img and see if full-size photos are loading into small slots. That's usually the answer for image-heavy pages.

Write down the top 3 things you see. They tell you which steps below matter most.

Step 3: Fix your images (the fastest win)

Images are usually the biggest bytes on a page. Four rules cover most of it:

Resize and compress before upload. A card that displays at 400px wide doesn't need a 4000px photo. Export at roughly 2x the display size and use WebP. Free tools like Squoosh work fine.
Always set width and height. This reserves space so the layout doesn't jump (that's your CLS score).
Lazy-load images below the fold. Add loading="lazy" so the browser only fetches them when the user scrolls near them.
Never lazy-load the main image at the top. Google's web.dev guidance is blunt: never lazy-load your LCP image. Give it fetchpriority="high" instead, and only on 1-2 images.

Here's what that looks like:

<!-- Hero image at the top: load it first -->
<img src="/hero.webp" alt="App dashboard preview" width="1200" height="630" fetchpriority="high">

<!-- Cards further down: load them when needed -->
<img src="/cards/item-42.webp" alt="Item 42" width="400" height="300" loading="lazy" decoding="async">

If your users upload photos to Supabase Storage, you can resize them on the fly with Supabase's image transformations. As of October 2026 that feature is on the Pro plan and above, with 100 origin images included per billing cycle and $5 per extra 1,000. On the free plan, resize images when they're uploaded instead.

Copy-paste prompt for your AI builder:

Audit every <img> and image component in this app.
1. The main image at the top of each page: add fetchpriority="high" and make sure it is NOT lazy-loaded.
2. Every other image: add loading="lazy" and decoding="async".
3. Every image must have explicit width and height (or a fixed aspect-ratio box) so the layout doesn't shift.
4. List any image files in the repo over 300 KB with their display size, but do not delete or replace them. I will compress them myself.
Show me the list of files you changed. Do not change any other behavior.

Step 4: Stop loading data you don't need

This is the one that bites at a few hundred users. AI-generated code often does three expensive things:

Fetches every column with select('*'), including big text or JSON you never show.
Fetches every row with no limit, so the response grows with your user base.
Makes one call per row (the "N+1 problem"): get 100 orders, then 100 more calls to get each customer name.

The fixes with the Supabase JavaScript client:

// Before: everything, forever
const { data } = await supabase.from('orders').select('*')

// After: only the columns you show, only this user's rows,
// the customer name in the SAME request, 20 at a time
const { data } = await supabase
  .from('orders')
  .select('id, total, created_at, customers(name)')
  .eq('user_id', userId)
  .order('created_at', { ascending: false })
  .range(0, 19)

A few notes:

customers(name) pulls the related customer in the same request. It works when there's a foreign key from orders to customers. (Table names here are just examples.)
.range(0, 19) returns rows 1-20. Load the next 20 when the user scrolls or taps "Load more."
The .eq('user_id', userId) filter looks redundant if your Row Level Security policy already limits rows to the user. Supabase's own performance docs recommend adding it anyway, because it helps the database plan a faster query.

Copy-paste prompt:

Find every database query in this app (Supabase client calls, fetch calls to my API, server routes).
For each one, tell me: which page uses it, whether it selects all columns, whether it has a limit, and whether it runs inside a loop or once per list item.
Then fix only these issues: select only the columns the UI uses, add pagination of 20 items to any list that can grow, and replace per-item queries with a single query that fetches related data together.
Keep the same UI and behavior. Show me a before/after table of the queries you changed.

Step 5: Add the database indexes your app is missing

If a specific screen is slow even after Step 4, the database may be reading every row to answer you. Supabase has a free checker for this.

In your Supabase dashboard, open Advisors and look at the Performance Advisor.
Look for "Unindexed foreign keys." It means a column like orders.customer_id links to another table but has no index, so joins and filters on it are slower.
Also index any column your RLS policies filter on, usually user_id.

The fix is one line of SQL per column, run in the SQL Editor:

create index if not exists orders_user_id_idx on orders (user_id);
create index if not exists orders_customer_id_idx on orders (customer_id);

One more RLS tip straight from Supabase's docs: wrap auth.uid() in a select inside your policies, so Postgres can run it once per query instead of once per row:

-- inside a policy
using ( user_id = (select auth.uid()) )

Want proof it worked? Run explain analyze on a slow query in the SQL Editor before and after. If you see "Seq Scan" on a big table and a large "Rows Removed by Filter," an index is likely the fix. Supabase's query optimization guide also says: if an index doesn't lower the cost, remove it. Indexes aren't free, so add them where the Advisor or a slow screen points, not everywhere.

If you followed my earlier guide to backups and safe database changes, add these as a migration file and test on your dev database first.

Step 6: Ship less JavaScript

Most AI-built apps are single-page React apps, and by default every page's code is packed into one big bundle. A visitor on your landing page downloads your entire dashboard, settings page and admin panel before seeing anything.

See what's in your bundle. For Vite apps (most Lovable and Bolt projects), install a visualizer as a dev dependency:

npm install -D rollup-plugin-visualizer

// vite.config.js (or .ts)
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { visualizer } from 'rollup-plugin-visualizer'

export default defineConfig({
  plugins: [react(), visualizer({ open: true })],
})

Run npm run build and a map of your bundle opens. Big blocks are big libraries. Common surprises: a full icon pack, a charting library only used on one page, or two date libraries doing the same job.

Load pages only when they're visited. React's built-in lazy splits each page into its own file:

import { lazy, Suspense } from 'react'

const Dashboard = lazy(() => import('./pages/Dashboard'))
const Settings = lazy(() => import('./pages/Settings'))

// wrap your routes once:
<Suspense fallback={<div>Loading...</div>}>
  {/* your <Routes> here */}
</Suspense>

Next.js apps (common from v0 and Cursor) already split code per route, so there your focus is mostly images, data and heavy libraries.

Copy-paste prompt:

I want a smaller JavaScript bundle without changing how the app looks or works.
1. Convert each top-level page/route to load with React.lazy and a single Suspense fallback.
2. List the 5 largest dependencies in the build and where each one is used.
3. For any library used on only one page, make sure it is only imported by that page.
Do not remove any library or feature without asking me first.

Step 7: Re-measure, then stop it from coming back

Run PageSpeed Insights and your Network-tab check again on the same pages, same settings, and fill in your baseline note with the new numbers. Change one area at a time (images, then queries, then bundle) so you know what helped. If something got worse, undo that change with Git.

Then protect your gains. AI tools will happily re-add a 3 MB image or a select('*') next week. Add rules to the file your tool reads every time (AGENTS.md, CLAUDE.md, Cursor rules, or Lovable's project knowledge):

Performance rules for this project:
- Never lazy-load the main image at the top of a page; give it fetchpriority="high".
- All other images use loading="lazy" and have explicit width and height.
- Never use select('*'). Select only the columns the UI shows.
- Every list that can grow is paginated (20 items) and never fetched in a loop.
- New foreign key or policy-filtered columns get an index in the same migration.
- Each page/route is lazy-loaded. Ask before adding any new dependency.

Re-check once a month and after any big feature.

Common mistakes

Testing only on your laptop on Wi-Fi. Your users are on phones on mobile data. Always check the Mobile tab and throttle the Network tab.
Lazy-loading everything. It feels like a speed fix, but lazy-loading the hero image makes your main number (LCP) worse.
Asking the AI to "optimize performance" in one prompt. You get a giant diff and no idea what helped. Give it one job at a time.
Chasing a 100 score. A landing page that goes from 45 to 85 on mobile is a real win. The last few points rarely matter to users.
Adding indexes everywhere. Each index slows down writes a little. Add them where the Advisor or a slow screen tells you to.

Your action summary

Record a baseline on your top 3 pages (PageSpeed Insights Mobile plus the Network tab on Fast 4G).
Sort the Network tab by size and write down your top 3 heavy things.
Fix images: resize to WebP, set width and height, lazy-load below the fold, fetchpriority="high" on the hero.
Fix queries: only needed columns, paginate lists, no per-row calls, filter by user.
Check Supabase's Performance Advisor and index unindexed foreign keys and RLS columns.
Visualize your bundle and lazy-load each page.
Re-measure, keep what helped, and add the performance rules to your AI rules file.

A fast app isn't about clever tricks. It's about not sending people things they didn't ask for: giant images, every row in your database, and code for pages they'll never open. Do these seven steps once, write the rules down, and your next feature starts fast instead of slowing everything else down.

How to Validate Your SaaS Idea Before You Build It: A 7-Step Pre-Sell Playbook for Beginners

Vishal Chauhan — Fri, 23 Oct 2026 11:25:18 +0000

You can build an app in a weekend now. That is the good news and the trap. When building is this cheap, it is very easy to spend a month polishing something nobody will pay for, and only find out on launch day.

This guide shows you how to test a SaaS idea before you build the real product, using a one-page site, a short waitlist form and a small paid "founding member" offer. It takes about two weeks, costs close to nothing, and works whether you build with Cursor, Claude Code, Lovable, Bolt, Replit or v0.

The core idea is simple: compliments and email signups measure curiosity. Money, time and effort measure intent. Every step below moves people one rung closer to the second kind.

Quick glossary

Validation: evidence that real people have the problem and will do something (pay, book a call, switch tools) to fix it.
Waitlist: a list of people who left their email to hear when you launch. Useful, but weak on its own.
Pre-sell: taking a real payment (or deposit) before the product is finished, with a clear delivery date and refund promise.
Pass mark: the number you decide in advance that counts as "yes, build it".
Concierge MVP: delivering the result by hand (spreadsheets, email, you doing the work) instead of with software.

Why a waitlist alone can fool you

On X in October 2026, posts like "How do you validate an idea before wasting months building it?" and "How to filter the 'cool idea' and 'I will use this' fake validation?" drew dozens of replies. On r/SaaS, the most common answer in recent threads is the same: a waitlist shows interest, a payment shows intent.

One r/SaaS founder shared their own numbers in March 2026: about 1,200 waitlist signups turned into 89 trials and 12 paying customers, and the product was shut down. A big list is not the same as buyers.

So we will still build a waitlist. We will just make it ask harder questions, and put a real price next to it.

Step 1: Write your bet and your pass mark before you start

If you decide what "good" looks like after seeing the numbers, anything looks like success. Write the bet down first.

Copy this template into a note and fill it in:

WHO has the problem (be narrow):
WHAT they do today to handle it (tool, spreadsheet, person, nothing):
WHAT it costs them today (time, money, mistakes):
MY OFFER in one sentence:
PRICE I will show on the page:

TEST WINDOW: 14 days, from ____ to ____

PASS (build it):  at least __ founding-member payments
                  OR at least __ people book a call AND describe the problem unprompted
MAYBE (change one thing and rerun): __ to __ qualified signups, 0-1 payments
FAIL (stop or pick a new customer): fewer than __ qualified signups

Hypothetical example: a cafe-owner tool that turns messy shift notes into a weekly summary. Bet: "Owners of 1-3 cafes waste about an hour a week reading WhatsApp shift notes." Pass: 5 founding-member payments at a one-time price in 14 days.

If no result could make you stop, it is not a test.

Step 2: Talk to 10 people who have the problem (without pitching)

Before you build a page, have 10 short conversations with people who match your "WHO". The goal is to learn how they handle the problem today, not to hear that your idea is nice.

The book The Mom Test by Rob Fitzpatrick is the classic guide here. Its main lesson: people are polite about your idea, so ask about their past behavior instead of your future product.

Where to find people: communities they already use, your own network, people complaining about the problem in public posts, and people leaving 2-3 star reviews of existing tools. Follow each community's self-promotion rules and ask for a 15-minute chat, not a sale.

Use questions like these:

1. Tell me about the last time you dealt with [problem]. What happened?
2. How do you handle it today? What tools or people are involved?
3. What is annoying or expensive about that?
4. Have you tried to fix it? What did you try, and why did you stop?
5. Are you paying for anything to deal with this right now? How much?
6. If you could wave a magic wand, what would be different?
7. Who else should I talk to about this?

Avoid "Would you use an app that...?" and "Would you pay for this?". Polite people say yes.

After each call, write down the exact words they used to describe the problem. You will reuse them on your page in Step 3.

Good signs: they have already tried to fix it, they pay for a half-working workaround, or they ask "when can I try it?" before you mention a product. A bad sign: the problem only appears when you bring it up.

Step 3: Build one honest page in an afternoon

Now build a single page. Not the app. Just the promise, the price and the next step.

Paste this prompt into Lovable, Bolt, v0, Replit, Cursor or Claude Code (edit the brackets first):

Build a single landing page for a product that is NOT built yet. Keep it honest.

Audience: [who, in their words]
Problem (use these exact customer phrases): [2-3 quotes from my calls]
Offer: [one sentence outcome, not features]

Sections, in this order:
1. Headline: the outcome for this audience. Subheadline: how it works in one line.
2. "Sound familiar?" with the 3 customer phrases as bullet points.
3. How it will work: 3 short steps.
4. Pricing: show the real planned price: [price]. Under it, a "Founding member" box:
   [founding price], limited to [number] spots, delivery by [date],
   full refund if I do not deliver or you are not happy in the first 30 days.
   Button: "Become a founding member" linking to [payment link URL].
5. Waitlist form for people not ready to pay (fields in the next prompt).
6. FAQ: "Is this built yet?" (answer honestly: in progress, ship date [date]),
   "What if it never launches?" (full refund), "Who is building this?" (me, [name]).

Rules: no fake testimonials, no fake user counts, no fake logos, no countdown timers.
Mobile first. One page only. Plain, friendly language.

Two things matter most. First, show a price. If the first time people hear the price is launch day, you never tested the price. Second, say plainly that the product is not built yet, so nobody feels tricked later.

Step 4: Make the waitlist form ask one hard question

A plain email box tells you almost nothing. Add two or three short questions so you can tell buyers from tourists.

Email (required)
What do you use today to handle [problem]? (short text, required)
How often does this happen?  [Daily / Weekly / Monthly / Rarely]
Can I email you a few questions or book a 15-min call?  [Yes / No]

The "What do you use today?" answer is gold. "Nothing, it is not a big deal" is a tourist. "A spreadsheet my assistant updates every Monday" is a potential customer.

No-code option: Tally's free plan includes unlimited forms and submissions under its fair-use guidelines, as of October 2026, and you can embed the form or link to it.

Code option: ask your AI builder to save signups to a database table. If you use Supabase, ask for a table where anonymous visitors can only insert rows and never read them, so nobody can download your waitlist. Our earlier guide on locking down Supabase covers insert-only tables: https://dev.to/siteory/your-vibe-coded-app-might-be-leaking-user-data-heres-how-to-lock-down-supabase-in-30-minutes-327k

Send every new signup a short personal email from your own address within a day. Ask one question: "What made you sign up?" The replies are often more useful than the form.

Step 5: Add a real founding-member offer with a payment link

This is the step that turns interest into evidence. You do not need checkout code. A Stripe Payment Link is a hosted payment page you create in the Stripe Dashboard and share as a URL.

Useful settings from Stripe's docs, as of October 2026:

Product type: a one-time payment is simplest for a pre-sale (for example, "Founding member: first 6 months"). Payment Links also support subscriptions if you prefer.
Limit the number of payments: Stripe can deactivate the link automatically after a set number of payments, and you can customize the message shown afterwards. Perfect for "20 founding spots".
Custom fields: add one short text field such as "What do you most want this to do for you?". Stripe's docs say not to use custom fields for sensitive personal data.
Store policies: you can show your refund policy and support contact on the payment page.

Founding-member copy you can adapt:

Founding member - [Product name]
[Founding price], one-time. Covers your first [6 months / 1 year] once it launches.

- Delivery: first working version by [date]. I will email you progress every 2 weeks.
- Refund: full refund if I do not deliver by [date], or within 30 days
  of launch if it is not useful. Just reply to any email.
- You get: [main outcome], direct access to me, and a say in what gets built first.

Only [number] spots. The regular price at launch will be [price]/month.

Keep your refund promise fast and without arguments. And know that, per Stripe's refund docs, Stripe's processing fees from the original payment are not returned when you refund, so a refund costs you a little. That is a fine price for real evidence.

Not ready to charge? A weaker but useful version is a booked call, or a concierge offer where you deliver the result by hand for a small fee. A January 2026 r/SaaS thread on validation ranked pre-selling and concierge offers above a plain waitlist.

Step 6: Send traffic from where your buyers already are

A test page with zero visitors proves nothing. Aim for a small number of the right people rather than lots of random clicks.

In order of usefulness:

The 10 people from Step 2. Send each a personal note: "You told me about [problem]. I am building this. Here is the page and the founding price. Honest feedback welcome, including no."
Communities where the problem gets discussed. Share what you learned from your calls, not a link dump. Follow each community's promotion rules.
Your network and one-to-one messages to people who match the "WHO" exactly.
Optional small ad test. Only if you already know where the audience hangs out, with a small fixed budget you are happy to lose.

To know which source works, give each one its own link with UTM tags, for example ?utm_source=reddit&utm_medium=community&utm_campaign=validation. Stripe's docs say Payment Links accept UTM codes, and that they are passed through to your redirect URL after payment if you set the confirmation behavior to "redirect". Keep a simple sheet:

date | source | visits | waitlist signups | "what do you use today" answers that sound real | calls booked | payments

Step 7: Score the result and decide (build, change, or stop)

At the end of your 14 days, open the note from Step 1 and compare. Do not move the pass mark now.

PASS  -> Build the smallest version that delivers the main outcome for your payers.
         Email them weekly. They are your first users and your best testers.
MAYBE -> Change ONE thing and rerun for 7 days:
         - lots of visits, few signups: the headline/problem is wrong
         - signups, no payments: price, offer, or trust is wrong (talk to 5 signups)
         - payments, then refund requests: the promise does not match the need
FAIL  -> Stop building this version. Keep the notes. Try a narrower customer
         or the adjacent problem people kept mentioning in your calls.

Then email everyone who signed up but did not pay: "Thanks for joining. Honest question: what stopped you from grabbing a founding spot?" The answers tell you which "MAYBE" case you are in.

Stopping is a good outcome too. Two weeks to learn "not this" beats six months of building.

Common mistakes

Counting signups as validation. A big list with no money and no calls is curiosity. Weigh payments and booked calls far above emails.
Hiding the price. People assume free. Show the planned price from day one.
Pitching in your interviews. If you talk about your idea in the first ten minutes, you will only hear compliments.
Asking friends and other developers. They are kind and rarely your customers. Talk to people who have the problem.
Building the app "just to test". If AI can build it in a weekend, you will be tempted. Build the page first. The app can wait two weeks.
Fake proof. No invented testimonials, user counts or "only 2 spots left" when it is not true. It breaks trust and, in many places, consumer rules.
Vague refund terms. If you take money before delivery, state the date and the refund rule in plain words, and honor them quickly. (This is general guidance, not legal advice.)
Moving the pass mark. Decide the numbers before the test, not after.

Your action summary

Day 1: Fill in the bet and pass-mark template. Pick a narrow "WHO".
Days 2-5: Have 10 no-pitch problem conversations. Save their exact words.
Day 6: Build one honest page with the AI prompt. Show the real price.
Day 6: Add a waitlist form with "What do you use today?".
Day 7: Create a Stripe Payment Link for a limited founding-member offer with a clear delivery date and refund promise.
Days 7-13: Send personal notes to your 10 people, share learnings in 1-2 communities, track each source with its own UTM link.
Day 14: Score against your pass mark. Build, change one thing, or stop.

The goal is not to prove your idea is good. It is to find out, cheaply and quickly, whether strangers care enough to pay, so the next thing you ask your AI to build already has customers waiting for it.

How to Stop AI From Wiping Your App's Database: A 7-Step Backup and Safe-Changes Guide for Vibe Coders

Vishal Chauhan — Fri, 23 Oct 2026 06:33:47 +0000

Your app has real users now. Their accounts, their saved work, maybe their payments all live in one database. And the same AI agent that builds your features can also run commands against that database.

One bad command, like a migration that drops a table or a "reset" pointed at the wrong project, can erase data you cannot get back. Git can undo code mistakes. It cannot undo lost user data.

This guide fixes that in an afternoon: a backup you control, proof that it restores, a separate database for the AI to experiment on, and settings that keep your agent away from production. The examples use Supabase, which many Lovable, Bolt, v0, Cursor and Claude Code apps run on, with notes for Lovable Cloud and Replit.

Quick glossary

Production (prod) database: the one your live app and real users use.
Dev database: a separate copy for building and testing. If it breaks, nobody loses anything.
Restore: loading a backup back into a database. A backup you have never restored is a guess.
Migration: a small SQL file that changes your database structure, like "add a plan column to profiles".
Destructive change: anything that deletes data or structure, like drop table or truncate.

Step 1: Find out what safety net you already have

Here is what the official docs say, as of October 2026:

Supabase Free plan: no daily backups you can rely on. Supabase's backup docs tell free projects to "regularly export their data using the Supabase CLI db dump command and maintain off-site backups."
Supabase Pro / Team / Enterprise: automatic daily backups, kept for 7 / 14 / up to 30 days, under Database > Backups. Point-in-Time Recovery (restore to an exact minute) is a paid add-on.
Lovable Cloud: one backup per day, about 14 days kept, under More > Database > Manage > Backups. You can also export the whole database (once every 24 hours).
Replit: separate development and production databases. Replit's docs say Agent "can't touch" the production database, and the development database can be rolled back to a checkpoint.

Three gotchas apply almost everywhere:

Files are separate. Supabase and Lovable both say database backups do not include files in Storage (uploads, avatars, PDFs).
Deleting the project deletes the backups. Supabase says deleting a project permanently removes its data, "including any backups."
Restores roll back everything. You lose every change made after the backup, and Supabase notes the project is unavailable during the restore.

Ask yourself: "If my database disappeared right now, what is the newest copy I could get back?" If the answer is "none" or "not sure", do Step 2 today.

Step 2: Take a backup you control, today

On Supabase, use the CLI commands from Supabase's own backup-and-restore guide. You need the Supabase CLI and Docker Desktop installed (the CLI runs the dump inside Docker). Get the connection string from the Connect button on your project dashboard. Supabase recommends the Session pooler string by default.

Save this as backup.sh in your project folder:

#!/usr/bin/env bash
# Backs up roles, schema and data into a dated folder.
# Usage: DB_URL="your-session-pooler-connection-string" ./backup.sh
set -e
STAMP=$(date +%Y-%m-%d_%H%M)
mkdir -p "backups/$STAMP"
supabase db dump --db-url "$DB_URL" -f "backups/$STAMP/roles.sql" --role-only
supabase db dump --db-url "$DB_URL" -f "backups/$STAMP/schema.sql"
supabase db dump --db-url "$DB_URL" -f "backups/$STAMP/data.sql" --use-copy --data-only -x "storage.buckets_vectors" -x "storage.vector_indexes"
echo "Backup saved in backups/$STAMP"

Then keep it out of Git, because these files contain your users' data:

chmod +x backup.sh
echo "backups/" >> .gitignore

The connection string contains your database password. Never paste it into a public repo, a screenshot, or an AI chat.

On Lovable Cloud, go to More > Database > Manage > Settings, click Export data, then Export and Start export. Lovable emails you when it is ready and saves it to your project's Storage. Download it and keep it somewhere outside Lovable, since its docs warn that removing the database deletes the export too. Download important Storage files separately from More > Storage.

Step 3: Prove the backup works with a test restore

On Supabase, create a new empty project to restore into. The Free plan allows 2 active projects, so this can be free. Install psql (the Supabase guide has instructions for Mac and Windows), then run the restore command from that guide, using the new project's connection string:

psql \
  --single-transaction \
  --variable ON_ERROR_STOP=1 \
  --file roles.sql \
  --file schema.sql \
  --command 'SET session_replication_role = replica' \
  --file data.sql \
  --dbname "PASTE-THE-NEW-PROJECT-CONNECTION-STRING"

Run it from inside the dated backup folder. Then compare row counts for your most important tables in both projects, using the SQL editor. Replace the table names with your own (profiles and projects are just examples):

select 'profiles' as table_name, count(*) from public.profiles
union all
select 'projects', count(*) from public.projects;

If the numbers match, you have a real backup. If the restore errors out, the Supabase guide has a troubleshooting section (for example, for errors mentioning supabase_admin), plus an extra key-copy step if you use Supabase Vault.

Now delete this test project, because it holds a full copy of real user data. Create a fresh one and restore only roles.sql and schema.sql (leave out the --command and data.sql lines). That empty copy becomes your dev database in Step 4.

Step 4: Give the AI its own database to break

The safest rule in this whole guide: the AI builds against a dev database, never against production.

Supabase (with Cursor, Claude Code, Bolt, v0): use two projects, for example myapp-dev and myapp-prod. Your local .env points at dev. Production keys live only in your hosting dashboard (Vercel, Netlify, and so on). Supabase also offers a local database (supabase start) and paid Branching.
Replit: already split for you. One catch from Replit's docs: when you publish, structure changes Agent made to the development database, including deleted columns or tables, are applied to production. So check what changed before you hit Publish.
Lovable Cloud: since October 5, 2026, Lovable runs every Cloud project on a single database. Its migration guide puts it plainly: "The data you see while building is the data your published app uses." Drafts preview code changes, not a second database. So lean on Steps 2, 3 and 7, test with obviously fake accounts, and keep the Step 5 setting. For a true dev/prod split, Lovable lets you connect your own Supabase project instead.

Habit: before anything touches data, check which project ref is in your connection string or .env.

Step 5: Make every database change a reviewed migration file

Raw SQL fired off by an AI leaves no record. Migration files give you something to read before anything runs. With the Supabase CLI:

# 1. Create a new, empty migration file
supabase migration new add_plan_to_profiles

# 2. Let the AI (or you) write the SQL into that file, then test it locally.
#    "db reset" here rebuilds your LOCAL database only.
supabase db reset

# 3. Compare local and remote migration history
supabase migration list

# 4. See exactly what would be applied, without applying it
supabase db push --dry-run

# 5. Only after a fresh backup (Step 2), apply it
supabase db push

Before step 5, read the migration file. You are not checking every line, just scanning for red-flag words:

drop table        drop column        truncate
delete from ...   (with no where)    alter column ... type
rename            db reset --linked  db push --include-all
migration repair

Two deserve a special warning. Supabase's CLI docs say db reset with --linked or --db-url runs a script that drops all user-created entities in the remote database. And if migration list shows lots of local migrations with no remote match, stop: a push may try to apply old files you did not expect. One r/Supabase post from April 2026 describes exactly that, an agent running db push that replayed old migrations, including DROP TABLE, against a live project.

For destructive changes, prefer an additive version: add the new column, copy the data, switch the app over, and remove the old column later, after a backup.

On Lovable Cloud, its docs say Lovable refuses changes like dropping or renaming a table or column, or changing a column's type, and adds to the database instead. That behavior is controlled by the agent permission Execute backward incompatible database migrations. Leave it at the default, or set it to Ask each time so you see the SQL first. Avoid Always allow.

Step 6: Take away the AI's keys to production

Prompt rules shape what the AI tries. Settings decide what it can do. Use both.

Supabase MCP server. Supabase's docs offer two URL options: project_ref (limit it to one project) and read_only=true (run queries as a read-only Postgres user). Scope it to dev:

https://mcp.supabase.com/mcp?project_ref=YOUR_DEV_PROJECT_REF

If the AI must look at production, use a separate read-only connection:

https://mcp.supabase.com/mcp?project_ref=YOUR_PROD_PROJECT_REF&read_only=true

Claude Code. Add deny rules to .claude/settings.json in your project. Claude Code enforces these itself, whatever the model decides:

{
  "permissions": {
    "deny": [
      "Bash(supabase db push *)",
      "Bash(supabase db reset *)",
      "Bash(supabase link *)",
      "Bash(npx supabase db push *)",
      "Bash(npx supabase db reset *)",
      "Bash(psql *)"
    ]
  }
}

The npx lines matter: Claude Code's docs explain that a rule only matches the command as written. The same docs say deny rules are not a full security boundary, so the dev project and read-only MCP still matter.

Cursor. In Settings > Agents > Approvals & Execution, avoid Run Everything, which runs every command without approval. Auto-review or Allowlist are safer, but Cursor's docs say neither is a security boundary.

Everyone. Add these rules to your AGENTS.md, CLAUDE.md, or Cursor rules file:

Database safety rules:
- Never run commands against the production database.
- Never run: supabase db push, supabase db reset --linked, migration repair,
  or any DROP, TRUNCATE, or DELETE without a WHERE clause.
- All schema changes go in a new file in supabase/migrations/. Stop after
  writing it and tell me what it does in plain English.
- Flag anything that deletes data, drops or renames columns, or changes types.
- Never ask me to paste database passwords or connection strings into chat.

Step 7: Automate backups and schedule a restore drill

Supabase Free: Supabase has an official guide, "Automated backups using GitHub Actions", with a workflow that runs the same three db dump commands every day at midnight (UTC, since GitHub schedules use UTC). It reads the connection string from a GitHub secret named SUPABASE_DB_URL and commits the dump files. Supabase's guide warns: "Never backup your data to a public repository." Use a private repo dedicated to backups.
Supabase Pro: daily backups are automatic. Still export weekly, because deleting the project deletes its backups.
Lovable Cloud: daily backups are automatic. Export before any big change, and download it.

Then add a monthly calendar reminder, "Restore drill": restore the latest backup into a throwaway project (Step 3), compare row counts, then delete it. On the Free plan's 2-project limit, pause your dev project first. It is the only way to know your backups still work.

To set up the workflow, paste this into your AI tool:

Read Supabase's guide "Automated backups using GitHub Actions"
(supabase.com/docs/guides/deployment/ci/backups). Create the periodic backup
workflow from that guide in .github/workflows/backup.yml, but trigger it only
on schedule (daily) and workflow_dispatch, not on push or pull_request.
Do not put any connection string in the file. Tell me exactly which GitHub
secret to create and confirm the repo must be private. Do not run anything.

Common mistakes

Trusting a backup you never restored. Do the Step 3 test once and the monthly drill after that.
Forgetting Storage files. Database backups do not include uploads. Download them separately.
Running db reset while linked to production. Locally it is harmless. With --linked it wipes the remote database.
Saving backups in a public repo. Backups contain emails and personal data.
Restoring to an old backup without exporting first. A restore erases everything after that point, so export the current state before you roll back.

Your action summary

Today:

Answer the Step 1 question: what is the newest copy of my database I could get back?
Run backup.sh (or Lovable's export) and add backups/ to .gitignore.
Restore that backup into a second project and compare row counts.

This week:

Point your AI tools at the dev project only.
Make database changes through migration files, read them, run db push --dry-run, and back up before every push.
Add the Claude Code deny rules, a scoped MCP URL, safe Cursor settings, and the rules block above.
Automate nightly backups in a private repo and put a monthly restore drill on your calendar.

None of this slows you down. It just means that the next time an AI agent gets too confident with your database, you lose a few minutes instead of your users' data.

How to Fix Your App's Link Previews on X, LinkedIn, Slack and WhatsApp: A 7-Step Beginner Guide

Vishal Chauhan — Thu, 22 Oct 2026 11:28:03 +0000

You finally share your app on X, in a Slack community, or in a WhatsApp group. The preview card shows the wrong name, a blank gray box, or the logo of the tool you built it with. People scroll past.

This is common in apps built with Lovable, Bolt, Replit, v0, Cursor or Claude Code, and it is fixable in an afternoon. The same few tags control your link previews and how your pages look in Google, so one round of fixes improves both. Here are 7 steps, with copy-paste tags, AI prompts, and the official tools to refresh old previews.

Quick glossary

Title tag: the page name in the browser tab. Google often uses it as the clickable headline in search results.
Meta description: a one or two sentence summary of the page. Google sometimes shows it under the headline.
Open Graph (OG) tags: og:title, og:description, og:image and friends. Facebook created the standard, and LinkedIn, WhatsApp, Slack, iMessage and many other apps read it to build preview cards.
Twitter card tags: X's own tags. X falls back to your OG tags for title, description and image, but twitter:card picks the big-image card style.
Link-preview bot: the program a platform sends to read your page when someone pastes a link. Most of them do not run JavaScript.
Cache: platforms save a preview the first time they see your link and keep showing it after you fix your page.

Step 1: See what the bots see

Before changing anything, find out what is broken. Paste your homepage URL into two free official tools:

LinkedIn Post Inspector (linkedin.com/post-inspector): shows the title, description and image LinkedIn found.
Facebook Sharing Debugger (developers.facebook.com/tools/debug): shows the tags Meta's crawler found, plus warnings.

Then look at the raw HTML yourself. This asks for the page the way a simple bot would and prints only the tags that matter:

curl -sL -A "facebookexternalhit/1.1" https://yourapp.com/pricing \
  | grep -ioE '<title>[^<]*|<meta[^>]*(og:|twitter:|description)[^>]*>'

If the output is empty or shows the same title on every page, you found the problem. One caveat: some hosts serve pre-rendered HTML only to verified crawlers (Lovable's docs say its older React + Vite apps work this way), so curl may show an empty page while real bots get full tags. When in doubt, trust the platform debuggers.

Write down what you find in a simple table:

PAGE        TITLE              DESCRIPTION     OG:IMAGE        PROBLEM
/           "Vite + React"     missing         lovable.png     wrong brand
/pricing    "Vite + React"     missing         lovable.png     same as home
/blog/post  "Vite + React"     missing         none            no image

Step 2: Write a unique title and description for every page you share

Google's guidance is clear: every page needs its own descriptive title, without boilerplate or keyword stuffing, and a description that accurately describes that specific page.

Start with the pages people actually share: home, pricing, your main use case or feature pages, and blog posts. Use this pattern:

Title tag:       [What this page is] | [Brand]
og:title:        [What this page is]            (no brand; og:site_name holds it)
Description:     [Who it is for] + [what they get] + [one specific detail]

A hypothetical example for a meal-planning app called PlateWise:

Home     Title: Weekly meal plans for busy families | PlateWise
         Description: Plan a week of dinners in 10 minutes and get one
         shopping list. Free for your first 2 weeks.
Pricing  Title: Pricing | PlateWise
         Description: One plan, $6 a month, cancel anytime. See what is
         included and how the free 2 weeks work.

A few rules from the platforms' own docs:

Keep descriptions short. WhatsApp's docs say about 80 characters is enough for its preview, and X lists 200 characters as the maximum for its description tag. Put the important words first.
Leave the brand out of og:title. Apple's Messages guidance says to put the site name in og:site_name instead, to avoid repeating it in the preview.
Do not let logged-in pages say "Sign In". Apple recommends that pages behind a login still describe what the link gives access to, without revealing private content.

Google may still rewrite your title or snippet in results. Good, specific text just makes that less likely.

Step 3: Add the full tag set

Here is the complete set for one page. Swap in your real values and use full https:// URLs:

<title>Pricing | PlateWise</title>
<meta name="description" content="One plan, $6 a month, cancel anytime." />
<link rel="canonical" href="https://platewise.app/pricing" />

<meta property="og:type" content="website" />
<meta property="og:site_name" content="PlateWise" />
<meta property="og:title" content="Pricing" />
<meta property="og:description" content="One plan, $6 a month, cancel anytime." />
<meta property="og:url" content="https://platewise.app/pricing" />
<meta property="og:image" content="https://platewise.app/og/pricing.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="PlateWise pricing: one plan, $6 a month" />

<meta name="twitter:card" content="summary_large_image" />

<link rel="icon" href="/favicon.ico" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />

Why og:image:width and height? Facebook's docs say they let its crawler render the image immediately for the first person who shares your link.

If your app is Next.js (common with v0, Cursor and Claude Code), do not hand-write tags. Use the Metadata API. Set a base URL and a title template once in your root layout:

// app/layout.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  metadataBase: new URL("https://platewise.app"),
  title: { template: "%s | PlateWise", default: "PlateWise" },
  description: "Weekly meal plans for busy families.",
  openGraph: { siteName: "PlateWise", type: "website" },
  twitter: { card: "summary_large_image" },
};

Then give each page its own values:

// app/pricing/page.tsx
export const metadata = {
  title: "Pricing", // becomes "Pricing | PlateWise"
  description: "One plan, $6 a month, cancel anytime.",
  openGraph: { title: "Pricing", url: "/pricing" },
};

metadataBase turns relative paths like /pricing into full URLs. Watch one gotcha from the Next.js docs: if a page sets openGraph, it replaces the layout's whole openGraph object, so repeat any fields you still need. For pages built from your database, such as blog posts, use generateMetadata instead. For icons, drop favicon.ico, icon.png and apple-icon.png into the app/ folder and Next.js adds the tags.

If your app is Lovable, ask in chat. Its docs say it generates titles and descriptions per page, and the page selector above the preview shows a Social card and a Search card for each page.

If your app is a plain React + Vite app (common with Bolt and Replit), the tags go in index.html, and image files go in the public/ folder, which Vite serves from the root of your site. Read Step 5 before you rely on this for more than one page.

Step 4: Make one share image that works everywhere

Each platform has its own rules. Here is what their docs say:

PLATFORM   SIZE / RATIO                          FILE LIMIT     NOTES
Facebook   1200x630 best, 1.91:1                 8 MB           under 600x315 = small thumbnail
LinkedIn   at least 1200x627, 1.91:1             5 MB           under 401 px wide = thumbnail
X          2:1, min 300x157                      5 MB           JPG, PNG, WEBP, GIF; no SVG
WhatsApp   300 px wide or more, max 4:1          under 600 KB   tags in first 300 KB of HTML
iMessage   900 px wide or more                   10 MB total    avoid small text in the image

The safe choice that fits all of them: 1200 x 630 pixels, PNG or JPG, under 300 KB. Lovable's docs warn that WhatsApp shows no preview for larger files.

Design tips:

Keep the important content in the middle. X uses 2:1 and the others use 1.91:1, so the edges may get cropped.
Use your product name and one short promise in big text, or a clean screenshot. Apple warns that small text can become unreadable.
Never reuse your logo or favicon as the share image. Small square images become tiny thumbnails.

Ask your AI tool to build it:

Create a 1200x630 PNG share image for my app [name]. Show the product
name and this promise in large text: "[one short promise]". Keep all
text inside the middle 1000x500 area. Use my brand colors [colors].
Save it as public/og/home.png, keep it under 300 KB, and set og:image
and the image width, height and alt tags to its full https URL.

Next.js users can also place an opengraph-image.png file inside any route folder and Next.js will add the image tags for that route automatically.

Step 5: Make sure the tags exist before JavaScript runs

This is the step that breaks most vibe-coded apps. Many AI-built apps are single-page apps: the server sends one nearly empty HTML file, and JavaScript builds the page in the browser. Link-preview bots usually do not wait for that. Apple's docs state plainly that link previews in Messages do not run JavaScript. Slack's link bot fetches as little of the page as it can. WhatsApp needs the tags within the first 300 KB of HTML.

So if your AI tool added tags with a library like react-helmet, browsers see them but bots do not. Every page previews with whatever is in index.html.

How to fix it depends on your stack:

Next.js: the Metadata API from Step 3 already puts tags in the server HTML. Keep metadata and generateMetadata in Server Components, as the docs require.
Lovable: its docs say new apps use server-side rendering, and older React + Vite apps get pre-rendered pages for verified crawlers, including social-preview bots. You mostly need good per-page tags.
Plain Vite SPA (Bolt, Replit, others): set strong site-wide defaults in index.html so every link at least looks right. For pages you want to share with their own preview, such as pricing, features and blog posts, serve them as real HTML: a static marketing site, a server-rendered framework, or a build-time pre-render step.

A prompt to plan this safely:

My app is a client-side React app. Social link previews only read the
first HTML response and do not run JavaScript. List every public page
I would want to share. For each, tell me whether its title, description
and og:image are in the raw HTML today. Then propose the smallest change
that puts unique tags in the server response for those pages only.
Do not change logged-in app pages. Show me the plan before editing.

Step 6: Clear the old previews

After you deploy, refresh each platform:

Facebook (and Meta apps): open the Sharing Debugger and click Scrape Again. Facebook caches images by URL, so give a changed image a new file name or URL. Old posts keep their old preview.
LinkedIn: paste the URL into Post Inspector. It shows when LinkedIn last updated its data and lets you request a re-scrape.
X: the Card Validator lost its preview feature in 2022, and X's docs said cards are re-read roughly every seven days. Check a card by pasting the link into the post composer. X's troubleshooting docs suggested adding a parameter to the image URL, such as og.png?v=2, so the new image is fetched.
Slack: Slack's docs say responses are cached for around 30 minutes, so just wait and post again.
WhatsApp: there is no official refresh tool. Its docs suggest typing the link into a chat and waiting for the preview above the text box. If it is stale, testing with a harmless parameter like ?v=2 is a common workaround.

Step 7: Check every page, then keep it from breaking

One fixed homepage is not enough. Check every public page for duplicate or missing titles, descriptions and images, using a crawler instead of one URL at a time. Disclosure: I work on Siteory. Siteory (siteory.co) is one free option: it reads your public HTML and flags missing titles and meta descriptions, and duplicate titles, across the pages it crawls. It does not draw social cards for you, so pair it with the platform debuggers from Step 1.

Also check:

Favicon: Google needs a square icon (larger than 48x48 px recommended) at a stable URL, linked from your homepage. It must not be blocked from crawling.
robots.txt: do not block Twitterbot or the folder that holds your images.
Staging links: previews only work for public pages. A password-protected preview URL will always show a blank card.

Paste this audit prompt into your AI tool after every big change:

Check every public route in this project. For each route, list the
title, meta description, og:title, og:description, og:image (full URL)
and twitter:card. Flag: duplicate titles, missing descriptions,
relative or missing image URLs, images that are not 1200x630, and tags
that are only added by client-side JavaScript. Do not edit anything yet.

Common mistakes

Leaving the template defaults. "Vite + React", "Lovable App" or "Your SaaS Name" in the title or preview tells people the app is unfinished.
Relative image URLs. /og.png works in your browser but not for bots. Use https://yourapp.com/og.png.
Same title everywhere. Your pages look identical in Google and in chats.
Tags added by JavaScript only. They are invisible to most preview bots.
Huge or SVG images. X does not support SVG, and WhatsApp needs under 600 KB.
Forgetting the cache. Run the debuggers after every change.
Testing only on one platform. A card that works on LinkedIn can still fail on WhatsApp.

Your action summary

Run Post Inspector, the Sharing Debugger and the curl check on your top pages.
Write a unique title and description for home, pricing, feature pages and posts.
Add the full tag set, or use the Next.js Metadata API or Lovable's Social card.
Create a 1200x630 PNG or JPG share image under 300 KB.
Make sure the tags are in the first HTML response, not added by JavaScript.
Refresh caches on Facebook, LinkedIn and X, and retest Slack and WhatsApp.
Crawl every public page for duplicates and gaps, and rerun the audit prompt after big changes.

Your link preview is often the first thing a stranger sees of your product. Spend one afternoon on it, and every link you share from now on will look like it came from a real, finished product.

How to Know When Your Vibe-Coded App Breaks Before Your Users Do: A 7-Step Beginner Guide to Error Alerts

Vishal Chauhan — Thu, 22 Oct 2026 06:32:21 +0000

Your app is live. You tested signup, you tested the main feature, everything worked. Then a week later someone replies to your launch post: "Is your site broken? I can't log in."

Too often, that is how founders find out their app is broken: from a user, days late, after other people quietly gave up and left. AI tools like Lovable, Bolt, v0, Cursor and Claude Code are great at building the happy path. They usually do not set up the part that tells you when something fails in production.

This guide fixes that in an afternoon. By the end you will have three things: an error tracker that catches crashes and silent failures, an outside uptime check that notices when the app or database is down, and alerts that actually reach you. All of it starts on free plans.

Quick glossary

Error tracker: a service (this guide uses Sentry) that records every error your app throws in a real user's browser or on your server, groups repeats together, and shows you where it happened.
DSN: the address your app uses to send errors to your Sentry project. Sentry's docs say it is safe to keep public, because it only allows sending new events, not reading any data.
Uptime monitor: an outside robot that loads a URL every few minutes and alerts you when it fails or the page looks wrong.
Source map: a file that translates your minified production code back into your real file names and line numbers, so error reports are readable.

Step 1: Write down the 5 things that must never break

Before installing anything, decide what "broken" means for your app. You do not need to watch everything. Fill in this template:

MUST-NEVER-BREAK LIST
1. Signup (new account, new device, logged out)
2. Login and password reset
3. The one core action (the reason people use the app)
4. Saving data (create / edit / delete the main thing)
5. Payment and access after paying (if you charge)

For each one:
- Where does it run? (browser / API route / Edge Function / webhook)
- What does the user see if it fails? (error message / blank screen / nothing)
- How would I find out today? (honest answer)

The last line is the important one. If the honest answer is "a user would tell me", that flow goes to the top of your list.

A hypothetical example: in a habit-tracker app, the core action is "mark today as done". If that save fails quietly, the user sees the checkmark, refreshes the next day, and finds their streak gone. Nothing crashed, so nobody gets told. That is exactly the kind of failure this guide is about.

Step 2: Add Sentry to your frontend

Create a free account at sentry.io, create a project, and pick your framework. Sentry's free Developer plan is for one person and includes error monitoring and email alerts. Check the pricing page for the current limits.

If your app is Next.js (common with v0, Cursor and Claude Code), run the official wizard in your project folder:

npx @sentry/wizard@latest -i nextjs

It installs the SDK, creates the browser, server and edge config files, and wraps your next.config so source maps upload on build. It also asks whether to route browser requests through your own server to avoid ad blockers. Saying yes means fewer missed reports, with one trade-off from Sentry's docs: it can add a little server load and hosting cost.

If your app is React + Vite (common with Lovable and Bolt), install the SDK:

npm install @sentry/react

Then create one small file and import it first:

// src/instrument.ts
import * as Sentry from "@sentry/react";

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,
  environment: import.meta.env.MODE, // "production" on your live build
  enabled: import.meta.env.PROD,     // ignore errors from your laptop
});

// src/main.tsx - this import must be the FIRST line
import "./instrument";

Put the DSN in your host's environment variables as VITE_SENTRY_DSN. A VITE_ variable ends up in the browser, which is fine for a DSN and never fine for secret keys.

Finally, wrap your app so a crash shows a friendly message instead of a white screen, and gets reported:

<Sentry.ErrorBoundary fallback={<p>Something went wrong. Please refresh.</p>}>
  <App />
</Sentry.ErrorBoundary>

Test it properly. Add a temporary button that throws new Error("Sentry test"), deploy, click it on the live site, and check the Issues page. Sentry's docs warn that errors you trigger from the browser DevTools console are sandboxed and will not show up, so use a real button. Delete the button afterwards.

Step 3: Report the errors that do not crash anything

This is the step most guides skip, and it matters most for vibe-coded apps. Sentry automatically catches uncaught errors. But many real failures never throw:

Supabase queries return errors instead of throwing them. The official pattern is const { data, error } = await supabase.from(...).... If the code ignores error, the save fails silently and Sentry never hears about it.
fetch() does not fail on 404 or 500. MDN is clear: the promise only rejects on network-level failures. A 500 from your API looks like success unless you check response.ok.
AI-written try/catch blocks that only console.log the error. The log disappears in the user's browser.

Add one helper and use it everywhere something important can fail:

// src/lib/report.ts
import * as Sentry from "@sentry/react"; // or "@sentry/nextjs"

export function report(where: string, err: unknown) {
  const error =
    err instanceof Error ? err : new Error(JSON.stringify(err));
  Sentry.captureException(error, { tags: { where } });
}

Then use it on your must-never-break flows:

const { error } = await supabase.from("habits").insert(newHabit);
if (error) {
  report("save-habit", error);
  showToast("Could not save. Please try again.");
  return;
}

const res = await fetch("/api/generate", { method: "POST", body });
if (!res.ok) report("generate", new Error(`API returned ${res.status}`));

The user gets a clear message instead of a fake success, and the where tag lets you filter Sentry by flow later.

You do not have to do this by hand. Paste this into your AI tool:

Find every Supabase query, fetch() call and try/catch block in this
project. For each one on these flows: [paste your must-never-break list],
make sure errors are (1) passed to the report() helper in
src/lib/report.ts with a short "where" tag, and (2) shown to the user
as a clear message. Never show success if the operation failed.
Do not change any other behavior. List every file you changed.

Step 4: Cover the backend too

Errors in your server code never reach the browser, so the frontend setup will not see them.

Next.js: the wizard from Step 2 already covers API routes, server components and middleware through its instrumentation.ts file. Nothing extra to do.
Supabase Edge Functions (where Lovable puts most backend logic): Supabase's own docs show adding the Sentry Deno SDK. The short version is to wrap your handler in try/catch, capture the error, and flush before returning:

import * as Sentry from "npm:@sentry/deno@^8";

Sentry.init({ dsn: Deno.env.get("SENTRY_DSN"), defaultIntegrations: false });

// inside your handler:
try {
  // ...your existing code...
} catch (e) {
  Sentry.captureException(e);
  await Sentry.flush(2000); // send before the function shuts down
  return Response.json({ error: "Internal error" }, { status: 500 });
}

Add SENTRY_DSN under Edge Function Secrets in the Supabase dashboard. Sentry recommends one project per part of your app, so create a second Sentry project for the backend and use its DSN here. That way frontend and backend errors do not mix.

Do webhooks (Stripe, auth hooks) first. When those fail, no user is on screen to complain; the work just never happens.

Step 5: Turn on alerts that actually reach you

An error tracker you never open is the same as no error tracker. In Sentry, go to Alerts and create an alert for your project with:

Environment: production only, so local testing never pings you.
Triggers: "A new issue is created" and "A resolved issue regresses". The first tells you about anything new. The second tells you when a bug you fixed comes back, which happens a lot when AI rewrites a file.
A second alert for spikes: trigger "An event or issue activity is captured", then add a frequency filter: number of events more than, say, 10 in one hour. Pick a number that fits your traffic.
Action: the free plan sends email. Add an inbox filter so Sentry emails are never archived, muted or sent to spam.
Throttle: at most once every 30 or 60 minutes per issue, so one bad bug does not send 200 emails.

Use the "Send Test Notification" button before saving, and confirm the email actually lands in your inbox, not spam.

Step 6: Add an outside uptime check

Sentry only sees errors from code that runs. If your host is down, your domain expired, or your database is unreachable, there may be nothing to report. You need something outside your app knocking on the door.

First, add a tiny health endpoint that also touches the database. For Next.js:

// app/api/health/route.ts
import { createClient } from "@supabase/supabase-js";

export const dynamic = "force-dynamic"; // never serve a cached "ok"

export async function GET() {
  const supabase = createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
  );
  const { error } = await supabase.from("habits").select("id").limit(1);
  if (error) return new Response("db-fail", { status: 500 });
  return new Response("ok");
}

For a Lovable or Vite app, ask your AI tool to create the same thing as a Supabase Edge Function named health. Because the uptime robot has no login token, that one function needs verify_jwt = false under [functions.health] in supabase/config.toml. Keep it boring: it reads one row through Row Level Security and returns only "ok" or "db-fail", never data.

Then create a free UptimeRobot account. The free plan includes 50 monitors with checks every 5 minutes, plus keyword monitors. Set up two:

Keyword monitor on your homepage: alert if a word that always appears (your product name or headline) is missing. This catches the "page loads but is blank" problem.
HTTP monitor on /api/health: it alerts when the endpoint returns an error status, which ours does (500) whenever the database check fails.

Five-minute checks are fine for a first SaaS.

Step 7: Make errors readable, then let your AI help fix them

A raw production error often points to something like index-a8f3.js:1:48213, which tells you nothing. Source maps fix that. Next.js users already got this from the wizard. For Vite, run:

npx @sentry/wizard@latest -i sourcemaps

It configures your build to upload source maps to Sentry. Sentry's docs warn that public source maps can expose your source code, so keep the option that deletes .map files after upload. Keep the Sentry auth token in your host's environment variables, never in Git.

Now the fun part. Sentry runs an official MCP server, so your AI tool can read your real errors. In Claude Code:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/YOUR-ORG/YOUR-PROJECT

Cursor can add the same URL in its MCP settings, and Lovable lists Sentry as a chat connector. Then use a prompt like this:

Read the newest unresolved Sentry issue in production. Explain in plain
English what the user was doing and why it failed. Propose the smallest
fix, show me the diff before applying it, and add a check so this
error is reported with report() if it happens again.

Finish with a 15-minute weekly habit: open Sentry, sort by users affected, fix the top issue, mark it resolved, and ignore known noise (like browser-extension errors).

Common mistakes

Testing only while logged in. Many breaks only hit new users. Run your must-never-break list from a private window with a fresh account after every big change.
Leaving Sentry on in development. Your own test errors flood the inbox and train you to ignore alerts. Use the production environment filter.
Swallowing errors. A catch block that only logs, or a Supabase call that ignores error, hides exactly the bugs you most need to see.
Showing success after failure. If the save failed, say so. A fake checkmark is worse than an error message.
Alerting on everything. Too many emails and you will mute them. Start with new issues, regressions and one volume rule.
Checking only the homepage. A homepage can load fine while login, the API or the database is down. Monitor the health endpoint too.
Sending personal data you do not need. Tag users by ID, not email, and leave Session Replay's default masking on if you enable it. Sentry masks all text and blocks media by default.

Your action summary

Write your must-never-break list and answer "how would I find out today?" for each flow.
Add Sentry to the frontend (wizard for Next.js, @sentry/react for Vite), deploy, and test with a real button.
Add a report() helper and use it wherever Supabase, fetch() or try/catch can fail quietly.
Add Sentry to API routes and Edge Functions, starting with webhooks.
Create production-only alerts for new issues, regressions and spikes, and send a test notification.
Add a /api/health endpoint plus two UptimeRobot monitors.
Upload source maps, connect Sentry to your AI tool, and do a 15-minute review every week.

Your users should never be your monitoring system. Set this up once, and the next time something breaks, you will be the first to know.

How to Set Up Onboarding Emails That Bring New Users Back: A 7-Step Beginner Guide for Your First SaaS

Vishal Chauhan — Wed, 21 Oct 2026 11:26:53 +0000

Someone signs up for your app. They click around for two minutes, get distracted, and never come back. You never hear from them again, and you have no idea why.

A short set of onboarding emails is one of the cheapest ways to close the gap between "signed up" and "got value". Not a newsletter, not a sales blast: a few plain, helpful emails that show up at the right moment and point to one next step.

This guide walks you through building that set for your first SaaS, even if you built the app with Cursor, Claude Code, Lovable, Bolt, Replit or v0 and have never written a marketing email.

Three quick terms first:

Onboarding emails: the emails a new user gets in their first 1 to 2 weeks, meant to help them start using the product.
First win (or activation): the one action that shows a new user your product works for them. For an invoicing app, that might be "sent the first invoice".
Trigger: the rule that decides when an email goes out, like "24 hours after signup, only if they have not done the first win yet".

One note before we start: this is not about getting your signup or password reset emails out of spam. If those are not arriving, fix your sending domain setup (SPF, DKIM, DMARC) first. Everything below assumes your app can already send email reliably.

Step 1: Pick your one "first win" action

Every onboarding email you write will point at one thing, so pick it carefully.

Ask yourself: what is the smallest action after which a new user can honestly say "oh, this is useful"? It should be:

Specific: something your database can see, like a row being created.
Early: possible in the first session, ideally in under 10 minutes.
Tied to value: not "completed profile", but "created the thing they came for".

Examples (hypothetical products):

A link-in-bio builder: "published a page with at least one link".
A meeting notes tool: "uploaded or recorded a first meeting".
An AI resume helper: "downloaded a first improved resume".

If you have two candidates, pick the one closer to the result the user signed up for.

Step 2: Track three simple things in your database

You do not need a fancy analytics tool for this. You need to know three facts about each user:

When they signed up.
Whether (and when) they hit the first win.
Whether they said no to these emails.

You also need a record of which emails you already sent, so nobody gets the same one twice. Here is a minimal setup for Postgres (Supabase included). Rename the columns to match your app.

-- On your existing profiles/users table
alter table profiles add column if not exists activated_at timestamptz;
alter table profiles add column if not exists last_seen_at timestamptz;
alter table profiles add column if not exists onboarding_emails_off boolean not null default false;

-- One row per onboarding email sent
create table if not exists onboarding_email_log (
  user_id uuid not null references profiles(id) on delete cascade,
  email_key text not null,          -- e.g. 'welcome', 'nudge_24h'
  sent_at timestamptz not null default now(),
  primary key (user_id, email_key)  -- makes double-sends impossible
);

Then set activated_at in the same code path where the first win happens (for example, right after the first invoice is saved), and update last_seen_at when a signed-in user loads the app. If you use Supabase, keep Row Level Security on for the new table and only write to it from your server code.

Step 3: Map a short sequence with clear stop rules

Beginners often copy a 12-email "drip" from a template site. Start smaller. Five emails over 14 days is plenty, and most users will only get two or three of them because the rules skip emails that no longer make sense.

Email	When it goes out	Who gets it	Its one job
welcome	Right after signup	Everyone	Point to the first win
nudge_24h	About 24 hours after signup	Not activated yet	Remove the most common blocker
help_day3	Day 3	Still not activated	Ask what got in the way
next_step	About 24 hours after activation	Activated users	Show the second most useful thing
checkin_day10	Day 10	Activated, but not seen for 5+ days	Bring them back with a reason

Stop rules (write these down, your code will need them):

The moment a user activates, they stop getting "please get started" emails.
Nobody gets more than one onboarding email per day.
If a user turns these emails off, nothing else in this sequence goes to them.
After day 14, the sequence ends. What happens next belongs to your normal product and billing emails.

This is the key difference from a fixed drip: emails are based on what the user did, not only on the calendar.

Step 4: Write each email like a short note from a person

Plain text, short, one link, and an honest invitation to reply. It is far easier to write than a designed newsletter, and replies are the best feedback you will get this early.

Copy these and fill in the brackets. Keep each one under about 120 words.

EMAIL: welcome
Subject: Your [Product] account is ready - start here

Hi [First name],

Thanks for signing up for [Product]. The fastest way to see if it is
useful for you: [first win, e.g. "create your first invoice"]. It takes
about [X] minutes.

Start here: [deep link straight to that screen]

If anything looks broken or confusing, just reply. I read every reply.

[Your name], founder of [Product]

EMAIL: nudge_24h
Subject: The step most people get stuck on

Hi [First name],

You have not [first win] yet, so here is the part that trips most
people up: [one common blocker, e.g. "connecting your bank account"].

Here is how to do it in [X] minutes: [link to a 60-90 second video or
a short help page]

Or skip it for now and [simpler path], then come back later.

[Your name]

EMAIL: help_day3
Subject: Quick question about [Product]

Hi [First name],

You signed up a few days ago but have not [first win] yet. Totally fine.

Could you hit reply and tell me what got in the way? One line is
plenty: not the right fit, too confusing, no time, something else.

I will use your answer to fix the product.

[Your name]

EMAIL: next_step
Subject: Nice work on your first [thing]

Hi [First name],

You just [first win]. Most people who keep using [Product] do one more
thing next: [second action, e.g. "set up automatic reminders"].

Here is where to do it: [deep link]

[Your name]

EMAIL: checkin_day10
Subject: Your [thing] is waiting

Hi [First name],

Last time you were here you [what they did]. [One concrete reason to
come back, e.g. "Two of your invoices are now overdue."]

Pick up where you left off: [deep link]

[Your name]

You are getting this because you signed up for [Product].
Turn off these tips: [unsubscribe link]
[Your business postal address]

A few rules that make these work:

Deep links, not your homepage. Send people straight to the screen where the next step happens.
One link per email. More choices means fewer clicks.
No fake urgency. No "last chance" in week one.
Subject says what is inside. Not "Re:" or "Fwd:" tricks. Gmail's sender guidelines explicitly say not to use those unless the message really is a reply or forward.

Step 5: Send them with a small scheduled job

You might be tempted to schedule all five emails at signup. Some providers let you do that (Resend, for example, can schedule an email up to 30 days ahead). The problem: the user's behavior changes after you schedule, so you would have to cancel emails every time someone activates.

A simpler pattern for beginners: run one job on a schedule that asks "who should get which email right now?" and sends only those. Two common ways to run it:

Vercel Cron Jobs: a route in your Next.js app that Vercel calls on a schedule. On the free Hobby plan, cron jobs can only run once per day, and the exact time can drift within the hour. That is fine for days 3 and 10, less precise for "24 hours".
Supabase Cron: Supabase supports pg_cron plus pg_net, so Postgres can call an Edge Function on any schedule you set, such as every hour.

Send the welcome email directly from your signup code, since it should arrive right away. The job handles everything else.

Here is the core query for one email, nudge_24h, in Postgres:

select p.id, p.email, p.first_name
from profiles p
where p.created_at < now() - interval '24 hours'
  and p.created_at > now() - interval '3 days'
  and p.activated_at is null
  and p.onboarding_emails_off = false
  and not exists (
    select 1 from onboarding_email_log l
    where l.user_id = p.id and l.email_key = 'nudge_24h'
  );

And the send step, using the Resend Node SDK as an example (any provider works the same way). It writes to the log first, so if the job runs twice, the unique key stops a second send:

// Inside your scheduled job, for each user from the query above
const { error: logError } = await db
  .from("onboarding_email_log")
  .insert({ user_id: user.id, email_key: "nudge_24h" });

if (!logError) {
  await resend.emails.send({
    from: "Sam at Example <sam@updates.example.com>",
    to: user.email,
    replyTo: "sam@example.com",
    subject: "The step most people get stuck on",
    text: nudgeText(user), // your template from Step 4
  });
}

Before turning it on for real users, add a "dry run" mode that only logs who would get which email, and run it against your own test accounts.

Step 6: Stay legal and out of the spam folder

This part is short but important. (Not legal advice; check the rules where you and your users live.)

Know which emails are "commercial". Under the US CAN-SPAM Act, the FTC separates commercial messages (promoting your product) from transactional or relationship messages (like account and transaction details). Onboarding tips that encourage people to use or buy your product may count as commercial, and the FTC says to read the transactional categories narrowly. The simple, safe choice: treat every email in this sequence, except a pure account notice, as commercial.

For commercial email, CAN-SPAM requires:

Accurate From and subject lines.
Your valid physical postal address.
A clear way to opt out, honored within 10 business days.
Your opt-out has to keep working for at least 30 days after you send.

Follow Gmail's sender guidelines:

Only email people who signed up with you.
Make unsubscribing easy. If you ever send 5,000+ messages a day to Gmail, marketing messages must support one-click unsubscribe and show a visible unsubscribe link.
Use the same From address for each category (for example, account emails from one address, tips from another).
Keep your spam rate in Google Postmaster Tools below 0.10%, and never let it reach 0.30%.

In practice: add an unsubscribe link that sets onboarding_emails_off = true, include your postal address in the footer, and keep password resets and receipts in a separate stream so turning off tips never blocks a login email.

Step 7: Measure the right numbers every week

Open rates are tempting, but they are unreliable. Google even notes in its sender guidelines that it does not track open rates and cannot verify third-party open numbers. Track what users do instead.

Once a week, write down:

Activation rate: of the people who signed up last week, how many hit the first win within 7 days?
Time to first win: for those who activated, how long did it take?
Per email: how many people activated within 48 hours of getting nudge_24h or help_day3?
Replies: read every one, and tag them (confusing, bug, wrong fit, no time).

Then change one thing at a time. If help_day3 replies keep saying "I could not find the import button", the fix is probably in the product, not the email.

Copy-paste prompt for your AI coding tool

Paste this into Cursor, Claude Code, Lovable, Bolt or Replit. Adjust the bracketed parts.

I want behavior-based onboarding emails for my SaaS. Before writing code,
read my project and show me a plan. Do not change anything until I approve.

My first win action is: [describe it, e.g. "user creates first invoice"].

1. Add activated_at, last_seen_at and onboarding_emails_off to my users or
   profiles table, and an onboarding_email_log table with a unique
   (user_id, email_key) key. Keep Row Level Security on; only server code
   writes to the log.
2. Set activated_at where the first win happens, only if it is still null.
3. Send a "welcome" email from the signup flow.
4. Create one scheduled job that sends nudge_24h, help_day3, next_step
   and checkin_day10 using these rules: [paste the table from Step 3].
   Insert into the log before sending. Max one onboarding email per user
   per day. Never email users with onboarding_emails_off = true.
5. Add an unsubscribe link and page that sets onboarding_emails_off = true,
   and put my postal address in the email footer.
6. Add a DRY_RUN env var that logs who would get which email without
   sending. Keep all API keys server-side.

Common mistakes to avoid

Sending a feature tour. Five features in one email means zero clicks. One email, one step.
Nagging people who already activated. This is what stop rules are for.
Using a no-reply address. Replies are your best early feedback. Use a real inbox.
Mixing tips with password resets. Keep account emails separate so an unsubscribe never blocks a login.
Judging emails by opens. Judge them by activation and replies.

Action summary

Do this in the next two evenings:

Write down your one first win action.
Add the three tracking columns and the email log table.
Copy the sequence table and stop rules from Step 3.
Fill in the five templates with your product details and deep links.
Send the welcome email from signup and set up one scheduled job for the rest, starting in dry run mode.
Add an unsubscribe link, your postal address, and a real reply-to inbox.
Every week, check activation rate and read every reply.

Your onboarding emails do not need to be clever. They need to show up when someone is stuck, point to one next step, and stop when the job is done.

How to Stop Your AI App From Leaking API Keys and Running Up Your Bill: A 7-Step Beginner Guide

Vishal Chauhan — Wed, 21 Oct 2026 06:26:53 +0000

Your AI feature works and the demo looks great. One question before you share the link: where does your AI API key live?

If you built your app with Cursor, Claude Code, Lovable, Bolt, Replit or v0, there is a real chance the answer is "in the browser". That means anyone who opens your site can copy the key and spend your credits. It is one of the most common mistakes posted in r/vibecoding, usually right after a surprise bill.

This guide shows you how to check, clean up, and make sure it cannot happen again. No security background needed.

Three quick terms first:

API key: a password your app sends to a service (OpenAI, Anthropic, Stripe) to prove it is allowed to use it. Whoever has the key can spend your money.
Frontend: the code that runs in your visitor's browser. Anyone can read it.
Backend (or server): code that runs on a machine you control, like a Next.js route, a Supabase Edge Function or a Cloudflare Worker. Visitors only see what it sends back.

Step 1: Check if your key is already exposed

Open your live app in Chrome and open DevTools (F12, or right-click and choose Inspect).
Go to the Network tab and use your AI feature once.
Look at the request it makes. If it goes straight to api.openai.com or api.anthropic.com, your key is in the browser. If it goes to your own domain (like /api/chat), that is a good sign.
Press Ctrl+Shift+F (Cmd+Option+F on Mac) to search across all loaded files. Search for sk- and the name of your key, like OPENAI.

Then search your project folder too:

grep -rnE "sk-|sk_live|sk_test|sb_secret_|service_role|dangerouslyAllowBrowser|VITE_.*KEY|NEXT_PUBLIC_.*KEY" \
  --exclude-dir=node_modules --exclude-dir=.git .

What each match means:

sk-... or sk_live... written directly in a file: a secret key is hardcoded. Fix it today.
dangerouslyAllowBrowser: the official OpenAI and Anthropic JavaScript libraries refuse to run in a browser unless you set this flag, because it exposes your secret key. If your AI tool set it to make an error go away, that is your leak.
VITE_OPENAI_API_KEY or NEXT_PUBLIC_OPENAI_API_KEY: see Step 3. The prefix itself is the problem.

If nothing shows up and requests go to your own domain, skip to Step 5.

Step 2: If it leaked, revoke the key first

Do not start with your code. Start at the provider.

Go to your provider's API keys page (OpenAI, Anthropic, Stripe and so on).
Create a new key.
Revoke (delete) the old one.
Check the usage page for spending you do not recognize.

Why first? Removing the key from your code does not remove it from copies people already downloaded or from your git history. GitHub's own guide on removing sensitive data says the first step for a leaked password or token is to revoke or rotate it, and that once it is revoked, that may be enough. Rewriting git history is risky and often unnecessary.

Two things worth knowing:

GitHub runs secret scanning on public repositories for free. For keys from partner providers, GitHub notifies the provider, which may revoke the key. OpenAI joined that program in 2021. Do not count on it: private repos are not covered the same way, and bots can use a key before anyone revokes it.
Pasting a key into your coding agent's chat is a common way it ends up in source code. Lovable detects keys pasted into chat and points you to its Secrets feature. With other tools, add keys yourself in the right place (Step 4).

Step 3: Learn which keys are safe to be public

Not every key is secret. Some are designed for the browser, and mixing them up is how many leaks happen.

Key	Safe in the browser?	Why
Supabase anon or publishable key	Yes, if Row Level Security is on	Supabase says so in its docs. RLS is what protects your data.
Stripe publishable key (`pk_...`)	Yes	Stripe says it can't create charges or read account data.
Google Maps browser key	Yes, if restricted to your domain	Lovable's docs call this out as the exception.
OpenAI, Anthropic or other AI keys	No	Anyone can spend your credits.
Stripe secret or restricted key (`sk_...`, `rk_...`)	No	A secret key has unrestricted access to all Stripe APIs.
Supabase service_role or secret key	No	Bypasses Row Level Security, so it can read every row.

Now the trap. Build tools copy some environment variables into the code they ship to browsers:

Vite (used by Lovable, Bolt and many React apps) puts any variable starting with VITE_ into your client code. Vite's docs say plainly that VITE_* variables should not contain sensitive information such as API keys.
Next.js (common with v0 and Cursor) inlines any variable starting with NEXT_PUBLIC_ into the JavaScript sent to the browser.

So .env does not mean "hidden". VITE_OPENAI_API_KEY is public once you build. Rename it without the prefix and read it only on the server.

Step 4: Move the AI call to your backend

The shape you want is simple:

Browser -> your backend (holds the key) -> AI provider

Here is a minimal Next.js route handler. It reads the key on the server only, and the browser never sees it.

// app/api/chat/route.ts
import OpenAI from "openai";

const client = new OpenAI(); // reads OPENAI_API_KEY from the server environment

export async function POST(req: Request) {
  const { message } = await req.json();

  const response = await client.responses.create({
    model: process.env.AI_MODEL!, // set on the server, never sent by the browser
    input: message,
  });

  return Response.json({ reply: response.output_text });
}

Your frontend now calls your own route, with no key anywhere:

const res = await fetch("/api/chat", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ message: userText }),
});
const { reply } = await res.json();

Set OPENAI_API_KEY (no prefix) in your hosting dashboard's environment variables, and in .env.local for local work. Make sure .env* files are in .gitignore.

Not on Next.js? Same idea, different place:

Lovable: store the key in Secrets. Lovable's docs say Secrets are encrypted, injected into Edge Functions or server functions, and never reach the browser.
Supabase (Bolt, Cursor or Claude Code builds): put the call in an Edge Function and set the key with supabase secrets set OPENAI_API_KEY=.... The function reads it with Deno.env.get("OPENAI_API_KEY").
Plain HTML or a mobile app: you still need a small backend, such as a Cloudflare Worker or a Supabase Edge Function.

Step 5: Lock the endpoint so strangers cannot use it

If /api/chat accepts requests from anyone, a stranger can skip your site and call it directly. They never see your key, but they still spend your money.

Add three checks at the top of your route:

export async function POST(req: Request) {
  // 1. Only signed-in users. Use your auth library's server-side check.
  const user = await getSignedInUser(req);
  if (!user) return new Response("Please sign in", { status: 401 });

  // 2. Only reasonable input
  const { message } = await req.json();
  if (typeof message !== "string" || message.length > 2000) {
    return new Response("Message too long", { status: 400 });
  }

  // 3. The server decides the model and the output size, not the browser
  const response = await client.responses.create({
    model: process.env.AI_MODEL!,
    input: message,
    max_output_tokens: 500,
  });

  return Response.json({ reply: response.output_text });
}

getSignedInUser is a placeholder. Replace it with the server-side check from your auth provider (Supabase, Clerk, Firebase, Auth.js and so on). With Supabase Edge Functions, keep JWT verification on for user-facing functions. Supabase's docs warn that turning it off to clear a 401 removes the platform's check.

The third check matters: if the browser can send model or max_tokens, someone can swap in your most expensive model.

Step 6: Add a rate limit and a spending cap

Logged-in users can still abuse a free plan, and one buggy loop can send thousands of requests. You want two safety nets.

A per-user rate limit in your app. A rate limit means "each user gets at most N requests per time window". Upstash Ratelimit is a small library built for serverless setups like Vercel, Cloudflare Workers and Deno. After creating an Upstash Redis database and adding its two environment variables, the code is short:

import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(20, "1 h"), // 20 AI requests per user per hour
});

// inside POST, right after the sign-in check:
const { success } = await ratelimit.limit(user.id);
if (!success) return new Response("Too many requests, try again later", { status: 429 });

20 per hour is an example; pick numbers that fit your product. Limit by user ID rather than IP address, since many real users can share one IP.

A spending cap at the provider. This is your last line of defense if everything else fails.

OpenAI: set a monthly spend limit for your project and turn on hard enforcement. OpenAI's help center notes that spend alerts alone do not stop traffic, and spend may slightly exceed the limit because enforcement is not instant.
Anthropic: set your own spend limit on the Billing page in the Claude Console. Once reached, requests return an error until you raise the limit or the period resets.

Also use a separate key per project, and OpenAI recommends keys with an expiration date plus regular rotation.

Step 7: Stop it happening again

A few habits keep this fixed.

Add rules for your AI tool. Put this in your project rules file (AGENTS.md, .cursor/rules, CLAUDE.md, or Lovable's knowledge settings):

Security rules for this project:
- Never put secret API keys in frontend code, HTML, or any variable starting
  with VITE_ or NEXT_PUBLIC_.
- All calls to AI providers, Stripe, or email services go through server code
  (API routes, server functions, or Edge Functions) that reads keys from the
  server environment.
- Never set dangerouslyAllowBrowser.
- Every endpoint that calls a paid API must check the signed-in user, validate
  input length, set the model and max output tokens on the server, and apply a
  per-user rate limit.
- If a task needs a new secret, stop and ask me to add it. Never write a key
  into a file.

Scan before you push. Gitleaks is a free, open-source scanner that finds secrets in files and git history. On a Mac with Homebrew:

brew install gitleaks
gitleaks git -v .   # scans your git history
gitleaks dir -v .   # scans the files on disk

It can also run as a pre-commit hook on every commit.

Use your platform's checks. GitHub push protection for users is on by default and stops you from pushing supported secrets to public repositories. Lovable runs a quick security scan on every publish and offers a deeper scan that looks for leaked secrets and endpoints anyone can trigger. Helpful, but not a replacement for checking yourself.

Repeat the Step 1 check after every deploy. It takes a minute.

And once your keys are safe, it is worth checking the rest of the live site too: security headers, HTTPS redirects, what search engines see. I build Siteory, a free audit that checks a live site for security, SEO and AI-search issues and gives you a developer-ready fix list, if you want a second pair of eyes.

Copy-paste audit prompt

Paste this into Cursor, Claude Code, Lovable or Bolt to have your AI tool check its own work:

Audit this project for exposed secrets and abusable paid API calls.

1. List every place an API key, token, or secret appears in code, config,
   or env files, and say whether that file is shipped to the browser.
2. Flag any variable starting with VITE_ or NEXT_PUBLIC_ that holds a secret.
3. Flag any direct browser call to OpenAI, Anthropic, Stripe, or other paid
   APIs, and any use of dangerouslyAllowBrowser.
4. For every server endpoint that calls a paid API, check: does it require a
   signed-in user, limit input size, set model and max tokens on the server,
   and apply a per-user rate limit?

Show me the list first. Do not change code until I approve. Never print the
full value of any secret you find.

Common mistakes to avoid

Deleting the key from code but not revoking it. The old key still works for whoever copied it.
Moving the key to the server but leaving the endpoint open. Strangers can still spend your money through your own route.
Relying on spend alerts. Alerts tell you; hard limits stop the spending.
Pasting keys into the AI chat. Add them through your platform's secrets screen instead.

Action summary

Do this today, in this order:

Open DevTools on your live site, use your AI feature, and check where the request goes.
Search your project for sk-, VITE_, NEXT_PUBLIC_ and dangerouslyAllowBrowser.
If any secret was exposed, create a new key, revoke the old one, and check usage.
Move every paid API call to a server route, Edge Function or Lovable Secret.
Require sign-in, cap input size, and set the model and max output tokens on the server.
Add a per-user rate limit and a hard monthly spend limit at your provider.
Add the rules to your AI tool, install Gitleaks, and repeat the DevTools check after every deploy.

Your AI key is a credit card number with no PIN. Keep it on the server, put limits around it, and check it every time you ship.

How to Get Your First Real Testimonials for Your SaaS (Without Faking Them): A 7-Step Beginner Guide

Vishal Chauhan — Tue, 20 Oct 2026 11:31:39 +0000

Your landing page probably has a testimonials section. The question is whether any of it is real.

If you built your first SaaS with Lovable, Bolt, v0, Cursor or Claude Code and asked for "a complete landing page", the AI may have filled that section with friendly quotes from people who do not exist. Something like "This changed how our team works!" - Sarah K., Product Lead (a made-up example, which is exactly the point). It looks finished, so it ships.

That is a problem. Visitors have seen those quotes a hundred times and skip them, and made-up customer quotes on your own site are not a gray area in places like the US and UK. This guide shows you how to replace placeholder proof with real testimonials from your first users, in 7 steps, with templates you can copy.

Quick note: this is practical advice, not legal advice. The rules below come from official FTC, UK legislation, Trustpilot, Product Hunt and Google pages. If you sell elsewhere, check local rules too.

First, two words you will see a lot

Testimonial: a quote you put in your own marketing (landing page, pricing page, ads, emails). The US FTC describes it as an advertising message that people are likely to believe reflects the real opinion or experience of someone who used the product.
Review: something a user posts on a platform built for reviews, like Trustpilot, Product Hunt or an app store.

The difference matters. The FTC says a business that puts testimonials on its own website is "disseminating" them, not just hosting them, so if they are fake or false, the business can be liable.

Step 1: Delete every fake or placeholder quote today

Before you collect anything, clean up what is already there. Search your project for typical placeholder content:

grep -rniE "testimonial|lorem|john doe|jane doe|trusted by|loved by|happy customers|rating" \
  --include=*.tsx --include=*.jsx --include=*.ts --include=*.html --include=*.vue \
  --exclude-dir=node_modules --exclude-dir=.next --exclude-dir=dist .

Then ask your AI tool to do a proper sweep, because invented proof also hides in hero text ("Join 10,000+ founders") and logo strips:

Audit this project for invented social proof. Find every testimonial, customer
quote, reviewer name, avatar, star rating, company logo strip, and user or
customer count ("10,000+ users", "trusted by teams at...").

For each one, list the file and line, and tell me whether it looks like
placeholder content. Do not invent replacements. Remove the placeholder items
and leave a single TODO comment where the testimonials section was. If a
number or logo might be real, ask me instead of deleting it.

Zero testimonials is fine for now. An honest "Free while in beta, built by one developer" beats a page full of Sarahs.

Why this is step one: the FTC's Consumer Reviews and Testimonials Rule (in effect since October 21, 2024) bans fake or false consumer testimonials and lets courts impose civil penalties for knowing violations. In the UK, the Digital Markets, Competition and Consumers Act 2024 made submitting or commissioning fake reviews a banned practice from 6 April 2025, and its definition of "writing" includes "creating by any means". AI-generated quotes are still invented quotes.

Step 2: Find the people who have actually had a win

You do not need paying customers to get your first testimonials. You need people who used your product and got something out of it. Good sources:

Beta testers and early free users
People you helped one-on-one over email, chat or a call
Users who did your product's main action several times (they keep coming back for a reason)

If your app runs on Supabase or Postgres, a query like this finds your most active recent users. It is a hypothetical example, so rename the tables and columns to match your app:

-- Hypothetical example: "reports" is whatever your main action creates
select p.email,
       count(*)          as actions_last_30_days,
       max(r.created_at) as last_active
from reports r
join profiles p on p.id = r.user_id
where r.created_at > now() - interval '30 days'
group by p.email
having count(*) >= 3
order by actions_last_30_days desc
limit 20;

What about friends and family? You can include them, but the relationship has to be clear. The FTC's Endorsement Guides say an ad with a relative or employee as the endorser is misleading unless that connection is made clear. So "My brother, who runs a bakery, uses it for invoices" is fine. Presenting your brother as a random customer is not.

Step 3: Save the nice things people already said

The easiest source of testimonials is your inbox. Support replies, DMs, comments and call notes often already contain the sentence you need, like "oh wow, that took 2 minutes instead of an hour".

Start a simple "proof log" and paste every piece of positive (and negative) feedback into it with the date and where it came from. It can be a spreadsheet or a JSON file in your repo:

[
  {
    "id": "t-001",
    "name": "Priya",
    "role": "Freelance designer",
    "quote": "I sent my first invoice in under five minutes.",
    "source": "support email",
    "said_on": "2026-10-12",
    "permission": "pending",
    "show_name": true,
    "show_photo": false,
    "show_company_logo": false,
    "incentive": "none",
    "relationship": "none"
  }
]

(Priya is a made-up example to show the format.)

Capturing feedback people gave on their own has a bonus. The FTC's FAQ notes that if you tell people in advance their comments might be featured in your ads, that chance of being featured can itself count as a benefit worth disclosing (for example, "Customers were told in advance they might be featured"). Unprompted feedback first, permission second, is the cleanest path.

Step 4: Ask at the right moment, in one short message

Ask right after a specific win: their first export works, a support issue gets solved, they come back for the third time this week. Keep the ask tiny. People ignore requests that feel like homework.

Template A: they already said something nice

Subject: Can I quote you?

Hi [first name],

Thanks again for your note on [date]. You wrote:

"[their exact words]"

Would you be OK with me putting that on the [product] website with your
first name and role ("[role]")? Happy to change the wording or leave your
name off. A simple yes or no is perfect.

[your name]

Template B: they are active but have not said anything yet

Subject: 3 quick questions about [product]

Hi [first name],

You've been using [product] for a few weeks, so I'd love your honest take.
Reply with a sentence for each, good or bad:

1. What were you doing before [product]?
2. What changed after you started using it?
3. What almost stopped you from trying it?

Thanks, this really helps me improve it.

[your name]

Template B does not mention quoting, so the feedback stays unprompted. If an answer is quotable, follow up with Template A. It also asks for criticism, on purpose. The FTC's FAQ says only asking customers you expect to be happy can be misleading if it substantially skews the picture. Trustpilot is stricter: invite everyone "consistently and fairly", at the same point in the journey, whether their experience was good or bad. On your own landing page you choose which quotes to show, but do not present a best-case result as normal (see Step 5).

Step 5: Edit lightly and get a clear yes in writing

You can fix typos and trim a long message down to its strongest sentence. You cannot change what it means. Send the final version back to the person and get approval before it goes live.

Rules of thumb:

Keep their meaning. The FTC says a business shouldn't write the text of a testimonial unless it has a reasonable basis to believe the text truthfully reflects that person's experience. Drafting from their own words and asking for approval is the safe version of this.
Ask separately for name, photo and company logo. A happy user does not mean their employer agreed to appear on your site.
Be careful with big numbers. If a quote says "this saved me 10 hours a week", the FTC says readers will usually assume that is a typical result. "Results may vary" does not change that. Either have proof that most users get similar results, or clearly state what users generally get. With five users, the simpler move is to prefer quotes about the experience ("I sent my first invoice in five minutes") over quotes that promise outcomes.
Record the yes. Update your proof log: "permission": "yes - email 2026-10-14".

Step 6: Know the incentive and review-site rules

Thinking of offering a free month for a testimonial? Here is what the official sources say:

Where	Can you offer an incentive?	Key rule
US (FTC)	Yes, if not tied to a positive opinion	Disclose it clearly. Paying for 5-star reviews is banned even with a disclosure.
UK (DMCC Act)	Only if made obvious	Commissioning a review that hides that it was incentivised is a banned practice.
Trustpilot	No	No discounts, promo codes, prize draws or freebies for reviews. No selective invites.
Product Hunt	No	No asking for or incentivizing upvotes, no mass messaging.

For a first SaaS, the simplest policy is: no incentives at all. Just ask honestly and say thank you. If you do offer something, say so right next to the quote, for example "Got 1 free month for sharing feedback". The FTC says a disclosure behind a link or hover is avoidable, which means it is not clear enough.

Step 7: Show them well and keep them fresh

Display tips:

Put proof next to decisions. Under the signup button, on the pricing page, next to the feature the quote talks about.
Show specifics. First name, role, date and the concrete thing they did. "I sent my first invoice in five minutes" beats "Amazing product!!!"
Real screenshots work. A public post or email (with permission, private details blurred) feels more real than a styled quote card.
Do not add star-rating markup to hand-picked quotes. Google's review snippet guidelines say rating markup is for an aggregate evaluation by many people that users can see on the page, that you should not aggregate reviews from other websites, and that fake or undisclosed incentivized reviews are not allowed. A handful of quotes you picked is not that, so skip the schema.

When you are ready to build the section, give your AI tool strict instructions so it cannot slip invented quotes back in:

Build a testimonials section that reads ONLY from data/testimonials.json.
Show an item only if "permission" starts with "yes". Show the name only if
show_name is true, and the photo only if show_photo is true. If "incentive"
is not "none", show it as visible text under the quote (not a tooltip).
If "relationship" is not "none", show that too. If there are fewer than 2
approved items, hide the whole section. Never add placeholder or example
testimonials, names, avatars, logos, star ratings or user counts.

Then refresh your proof log every month or two. The FTC notes that if your product has changed, it's best to get new endorsements, and a quote that implies someone still uses your product is only fine while you have good reason to believe they do.

Common mistakes to avoid

Shipping placeholder quotes "for now". Now becomes forever.
Inviting only your happiest users to review sites. Trustpilot forbids it.
Polishing a quote into marketing copy. It stops sounding like a person, and may stop being what they said.
Using a company logo because one employee likes you. Get separate permission.
Hiding the disclosure. Small grey text behind a link does not count.
Waiting for big review sites first. Start with quotes on your own site from people you have talked to.

Action summary

Do these in order this week:

[ ] Run the grep and the AI audit prompt, then remove every placeholder quote, logo and fake count
[ ] List 10 to 20 people who had a real win (beta users, people you helped, your most active users)
[ ] Start a proof log and paste in every piece of feedback you already have
[ ] Send Template A to anyone who already said something nice
[ ] Send Template B to active users at their next win
[ ] Get a written yes, and record name, photo and logo permission separately
[ ] Decide your incentive policy (simplest: none) and write it down
[ ] Rebuild the testimonials section from the JSON file using the strict prompt
[ ] Put a monthly reminder in your calendar to refresh old quotes

Three real sentences from three real users will do more for your signup page than a wall of invented praise. Ask at the right moment and keep it honest.

How to Get Your App's Signup and Password Reset Emails Out of Spam: A 7-Step Fix for Beginners

Vishal Chauhan — Tue, 20 Oct 2026 06:31:26 +0000

You built the app with Cursor, Lovable, Bolt or Claude Code. Signup works. You tested it five times. Then a real person signs up, never gets the confirmation email, and you never hear from them again.

It's one of the most common "works on my machine" traps in vibe-coded apps, and it's rarely a code bug. It's about who sends your email and whether inboxes trust that sender. Here is the fix, in order, for apps on Supabase Auth (the login system behind many AI-built apps) or Lovable Cloud.

Three terms first:

Transactional email: email triggered by something the user did, like signing up or resetting a password. The opposite of a newsletter.
SMTP provider: a company whose servers send your app's emails for you.
DNS records: small public settings on your domain (yourapp.com). Inboxes read three of them to decide whether an email is really from you.

Step 1: Find out which problem you actually have

Don't change anything yet. First, test like a stranger.

Open your live app (not the preview) in a private browser window.
Sign up with a Gmail address that is not on your Supabase or Lovable team.
Wait two minutes. Check the inbox, the Promotions tab and Spam.
Open your auth logs (Supabase: Auth logs under Logs; Lovable Cloud: authentication logs).

Why a non-team address? Supabase's built-in sender only delivers to your project's team. Everyone else fails with Email address not authorized, which is why it worked every time you tested it.

What you see	Most likely cause	Go to
`Email address not authorized` in the logs	Still on Supabase's built-in sender	Step 2
Error 429 or "rate limit"	Hourly email limit reached	Steps 2 and 5
Email lands in Spam or Promotions	Domain not authenticated, or content looks like marketing	Steps 3, 4, 6
Link opens `localhost` or says the token expired	Link settings or email scanners	Step 6
Logs say sent, nothing arrives	Bounce or suppressed address at your provider	Step 7

Step 2: Replace the built-in sender

Supabase's default sender is for testing: it only mails your team, is currently limited to 2 messages per hour (which can change without notice), and has no delivery guarantee. Supabase urges custom SMTP for anything beyond demos.

Your own Supabase project (common with Cursor, Claude Code, Bolt and v0 builds, and Lovable apps connected to your own Supabase): plug an email provider's SMTP details into Supabase. Supabase lists Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail and Brevo.
Lovable Cloud: the built-in Emails feature (More, then Cloud, then Emails) sets up your sending domain and DNS records for you. It needs a paid workspace and DNS access, and includes 50,000 transactional emails a month with hourly caps (500 auth emails per hour on Pro). Free plans stay on the default sender.

This guide uses Resend because its free plan fits a first launch: 3,000 emails a month, capped at 100 per day. For example, if a launch post brings 150 signups in one day, the free plan won't cover it, because each signup sends at least one email. Upgrade before a launch, not during it.

Using Firebase, Clerk or Replit's auth instead? The screens differ, but Steps 3, 4, 6 and 7 still apply.

Step 3: Send from your own subdomain

Providers like Resend only send from a domain you own, so a Gmail address is out.

Pick a subdomain just for app email:

auth.yourapp.com   signup, magic links, password resets
mail.yourapp.com   newsletters and announcements (later)

Resend recommends subdomains to isolate your sending reputation. Supabase goes further: separate domains, ideally separate services, for auth and marketing email, so a newsletter can't drag your password resets into spam. Lovable uses a notify subdomain by default.

Use a From address like hello@auth.yourapp.com with your app's name as the sender name. Resend's deliverability checks flag no-reply addresses, so pick one a person can reply to.

Step 4: Add SPF, DKIM and DMARC

In plain terms:

SPF is the guest list: which servers may send mail for this domain.
DKIM is a tamper-proof seal: your provider signs each email, and a public key in your DNS lets inboxes verify it.
DMARC is your instruction to inboxes: what to do with mail that fails, and where to send reports.

Gmail requires SPF or DKIM from every sender, and all three from anyone sending more than 5,000 messages a day to Gmail. Yahoo requires all three from its bulk senders, and Outlook.com from senders of 5,000 or more messages. Google recommends all three at any volume, so do it from day one.

In Resend, open Domains, click Add Domain and enter your subdomain. It shows the exact records to create.
Log in where your DNS actually lives (registrar, Cloudflare or Vercel). Not sure? Look up your nameservers on a site like dns.email.
Copy each record character for character. With Resend, DKIM sits at resend._domainkey and SPF on a send subdomain; domains added after August 2026 may show CNAME records instead. Copy whatever your dashboard shows.
Add DMARC yourself, because Resend doesn't create it. Start in monitoring mode:

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourapp.com

p=none means "report, don't block," and reports go to the rua inbox. Once everything passes, move to p=quarantine. Check for an existing _dmarc record first: under the DMARC standard, a domain with two gets no DMARC at all.

Then click verify. Resend says domains often verify within 15 minutes, though DNS can take up to 72 hours. To check from a terminal, swap in your names:

nslookup -type=TXT resend._domainkey.auth.yourapp.com
nslookup -type=TXT _dmarc.yourapp.com

Step 5: Connect Supabase to your provider

In Supabase, open Authentication, then Emails (under Notifications), then SMTP Settings, and enable custom SMTP. For Resend:

Host:         smtp.resend.com
Port:         465
Username:     resend
Password:     <your Resend API key>
Sender email: hello@auth.yourapp.com
Sender name:  YourApp

Two things beginners miss:

Raise the rate limit. After the switch, Supabase starts you at 30 emails per hour. Go to Authentication, then Rate Limits, and set a number that fits your launch and your provider's plan.
Keep the API key out of your code. Paste it only into the Supabase dashboard, not into your AI chat, frontend code or a public repo. If it leaks, delete it in Resend and create a new one.

Now send yourself a password reset. If the Auth logs mention gomail, Supabase lists the usual causes: a misconfigured domain, the wrong port, provider rate limiting or downtime.

Step 6: Make the emails and links trustworthy

Fix the Site URL. It defaults to http://localhost:3000, and Supabase calls it critical for confirmations and resets. Set your production URL under URL Configuration and add every real domain to Redirect URLs.

Turn off open and click tracking for this domain. Supabase warns that tracking rewrites auth links so they stop working, and Resend says it can hurt transactional deliverability. In Resend it's a per-domain switch.

Plan for link scanners. Some workplace inboxes open every link to scan it (Supabase's example: Safe Links in Microsoft Defender). Supabase links work once, so the real user then sees "Token has expired or is invalid." One fix from Supabase's docs is emailing a 6-digit code instead of a link:

<h2>Confirm your email</h2>
<p>Enter this code in the app: {{ .Token }}</p>

Your app then checks it with supabase.auth.verifyOtp({ email, token, type: 'email' }).

Keep auth emails boring. Supabase's list: no promotions or taglines, few links and images, short subjects with few emojis, and rare template changes. Gmail's guidelines agree: don't mix promotions into other message types. A password reset should say what happened, offer one button or code, and stop.

Step 7: Prove it works, then keep watching

Don't flood your own inbox: Lovable's docs warn that repeated test emails look like artificial traffic.

Gmail "Show original." In Gmail on a computer, open the email, click More (three dots) next to Reply, then Show original. You want PASS next to SPF, DKIM and DMARC. The raw header looks roughly like this (simplified):

Authentication-Results: mx.google.com;
  dkim=pass header.i=@auth.yourapp.com;
  spf=pass smtp.mailfrom=send.auth.yourapp.com;
  dmarc=pass header.from=auth.yourapp.com

Get a spam score. mail-tester.com gives you a one-time address. Sign up in your app with it and read the report. The free version allows 3 tests in 24 hours.
Try one Outlook or Yahoo address. Different inboxes run different filters.
Read your provider's logs weekly. Bounces show up there, and Resend automatically stops sending to addresses that bounce permanently (its suppression list).

With real volume, add your domain to Google Postmaster Tools. Google asks senders to keep the reported spam rate below 0.1% and never reach 0.3%.

New domains start with no reputation, so a few early emails may still hit spam. Lovable's docs call this normal for the first days or weeks.

Sending newsletters later? Give them their own lane

Send them from the other subdomain (mail.yourapp.com), ideally through a separate service. Only email people who opted in (Gmail and Yahoo both say never buy lists) and include a visible unsubscribe link. Bulk senders must also support one-click unsubscribe, and Yahoo wants unsubscribes honored within 2 days.

Copy-paste prompt: have your AI audit the setup

Paste this into Cursor, Claude Code, Lovable or Bolt:

Audit how this app sends auth emails. Report first; do not change code yet.
1. Which service sends signup, magic link and password reset emails?
   Is it still the Supabase built-in sender?
2. List every place an email API key or SMTP password appears.
   Flag any in frontend code, committed files or tracked .env files.
3. Check every redirectTo / emailRedirectTo value. Flag localhost,
   preview domains and relative URLs.
4. Is there a "Resend confirmation email" button with a 60-second
   cooldown (Supabase's default per-user limit)? If not, propose one
   using supabase.auth.resend.
5. Review the email templates. Flag marketing copy, more than one link,
   images, emojis in subjects, and user-provided data.
Give me a numbered list of findings with the exact fix for each.

Common mistakes

Adding a second SPF record. Google's docs say each domain can have one. Merge new senders into it.
Editing DNS in the wrong place. If your nameservers point to Cloudflare or Vercel, records added at your registrar do nothing.
Doubled domain names. Some DNS panels append your domain, creating send.yourapp.com.yourapp.com. Enter just the host part; for values, Resend suggests a trailing dot.
Proxied CNAMEs on Cloudflare. Email CNAME records must be gray-cloud (DNS only).
Starting DMARC at p=reject. One forgotten sender and you block your own mail.
Turning off email confirmation because "emails don't work." Supabase says not to disable confirmations under pressure; without them, anyone can sign up with an address they don't own.

Checklist

[ ] Stranger test passed on the live app
[ ] Custom SMTP (or Lovable Emails) on
[ ] Sending from auth.yourapp.com (or similar)
[ ] SPF and DKIM verified; DMARC at p=none
[ ] Rate limit above 30 per hour; plan covers launch day
[ ] API key only in the dashboard
[ ] Site URL and Redirect URLs on production
[ ] Tracking off for auth email
[ ] Templates short: one link or a code
[ ] Show original: SPF, DKIM, DMARC all PASS

Action summary

Today: run the stranger test and read your auth logs. This week: pick a sending subdomain, add SPF, DKIM and DMARC, switch to custom SMTP and raise the rate limit. Before launch: fix the Site URL, turn off tracking, simplify templates and confirm three PASS results in Gmail. It's about an afternoon, and it means people who want your app can actually get in.