Skip to main content

This site is not ready to launch — leads are not being delivered

  • Critical: No contact email is configured, so the site has no working way to reach you. Set up the ImprovMX alias, then set email in src/config/site.ts.
  • Incomplete: Team facts (location, stacks) are unset. The About page is showing an explicit placeholder instead of real claims. Get the real details from Benson and fill in team.* in src/config/site.ts. Never invent these.

This banner is generated from src/config/site.ts and disappears by itself once every item is resolved. Run npm run check:launch to verify from the terminal. The full launch sequence is in the repository README.

Vibe Code Engineers

by Lovable

Built it with Lovable?

A prompt-driven builder that generates a complete React web application with a Supabase backend attached, and syncs the code to a GitHub repository you own.

Request a Codebase Review

What it generates

  • React with Vite and TypeScript
  • Tailwind CSS, commonly with shadcn/ui components
  • Supabase for database, authentication, and storage
  • GitHub sync, so the code is genuinely yours

What it’s good at

  • Gets from description to a working, deployed application faster than almost anything else available.
  • The generated frontend code is conventional and readable, which makes it straightforward for an engineer to pick up.
  • Code syncs to your own GitHub repository, so you are not locked out of what you built.
  • The Supabase pairing means the backend is a real Postgres database rather than a proprietary store.

What Lovable leaves you to build

Mostly scope rather than shortcoming — these are the boundaries of what the product sets out to do.

Correct row-level security policies

Supabase enforces data access through row-level security rules written per table. Generating a policy is easy; generating one that is correct for your product's actual rules is not, and a policy that exists but is written permissively provides no protection while looking like it does. This is the single most consequential gap in the stack, and it has a documented history — a 2025 CVE covered exactly this failure in Lovable-generated sites.

Server-side authorization

Interface-level checks decide what a user sees. They do not decide what a user can request. Any rule that matters has to be enforced where the data lives, because the browser is under the user's control.

Business logic that cannot live in the client

Pricing, entitlements, credit balances, and anything a user could benefit from altering need to run on the server. In a generated app this logic frequently sits in the React application, where it is editable by anyone who opens developer tools.

Payment integrity

Taking a card payment is the easy half. Verifying webhook signatures, handling declines and refunds, and making sure an order cannot be marked paid by a forged request is the half that determines whether you lose money.

Tests and a deployment pipeline

Generated projects rarely arrive with meaningful test coverage or a pipeline that runs checks before deploying, which is what makes later changes feel risky.

Signs you’ve outgrown it

  • Prompts are producing changes you did not ask for in parts of the app you were not discussing.
  • You are hitting the same bug repeatedly and each fix moves it rather than removing it.
  • You have real users with real data, and cannot confidently say whether one can read another's records.
  • You want a feature that requires background processing, scheduled jobs, or a third-party integration with its own auth flow.

What a handoff involves

Because Lovable syncs to GitHub, a handoff is unusually clean — an engineer clones the repository and works normally. This is a real advantage over more closed builders.
The first thing worth checking is the Supabase project's policies, table by table, against what your product actually intends.
You can keep using Lovable for interface work while engineers own the database and server side. That split works well; two parties editing the same files does not.

Lovable — questions

Is my Lovable app's exposed API key a security problem?

Probably not by itself, and this is the most misunderstood point in the whole category. Supabase's documentation states that the anonymous key is designed to be public and safe to expose in client code, provided row-level security is enabled on the tables it can reach. The genuine risks are policies that are missing or written permissively, and the service_role key ending up in your frontend bundle — that one bypasses row-level security entirely. Anyone quoting you for a fix because your anon key is visible has skipped the part that matters.

Can I take my code out of Lovable?

Yes. The GitHub sync means the application code is in a repository you control, and your data is in a Supabase project you control. That is meaningfully better than platforms where export is a support ticket.

Do I have to stop using Lovable to work with engineers?

No, and there is often no reason to. The arrangement that works is a clear boundary: you keep iterating on the interface, engineers own data access, authentication, and payments.

Last reviewed 2026-07-20. Lovable ships changes frequently. If something here is out of date, tell us and we will correct it — we would rather be accurate than flattering.

Not sure what your Lovable app needs?

A fixed-price review tells you what's actually wrong, what it would cost to fix, and whether you need us at all.

Request a Codebase ReviewSee pricing
Request a Codebase Review