Read the code, not just the interface
An app that looks finished can hide a lot. Start by reading what has been built: which framework, which database, which external services it calls and which packages it depends on. Look for code that was generated, abandoned and left behind, logic that exists in several places, and functions that only work with the test data. Check that the project builds from a clean copy with documented steps, so that it does not depend on one person's computer or on a tool's editor. That reading is also where help with AI-built projects starts.
Database security rules and row-level security
Apps built in Lovable and similar tools often talk to the database straight from the browser, usually through Supabase. That is safe only if the database itself decides who may read and write each row, through row-level security in PostgreSQL. Check that it is turned on for every table and that the policies say what you mean, for example that users only see their own orders and that nobody can change their own role. Test it by signing in as an ordinary user and trying to reach someone else's data. A table with row-level security turned off is open to anyone who has the app's public key, and that key is in the browser for all to see.
Secrets and API keys
Search the code and the repository history for API keys, passwords and tokens. The public key a Supabase app uses in the browser is meant to be public, but the service role key, the payment provider's secrets and keys to AI providers must only exist on the server, in environment variables or the platform's secret store. Calls to AI models and payment services should go through a server function, never straight from the browser. Keys that have been committed at any point should be replaced, since the history keeps them.
Sign-in with real users
Sign-in usually works for the person who built the app and comes apart at the edges. Go through the full flows with real email addresses: sign-up, confirmation, forgotten password, change of email address, sign-in with Google or another provider, and what happens when a session expires. Check that mail is sent from your own domain with SPF, DKIM and DMARC in place, so confirmation links do not end up in spam. Decide how accounts are deleted and what happens to their data, a question GDPR requires you to be able to answer.
Speed and images
Prototypes tend to load everything at once: large images straight from the upload, every library on the first page and data fetched in several rounds before anything shows. Measure on a mid-range phone over a mobile network, not on the developer's computer. Serve images in modern formats such as AVIF or WebP, in the sizes they are shown at, split the code so each page loads what it needs, and fetch data in as few requests as possible. Google's Core Web Vitals, LCP, INP and CLS, give targets to aim for and show up in Search Console once there is enough traffic.
SEO on sites built as single-page apps
Many AI tools build a single-page app, where the browser receives an almost empty page and JavaScript draws the content. Google can render JavaScript, but it takes longer, and many other crawlers, AI search tools and link previews in social media and chat apps only read the first HTML. Every page that should be found needs its own address, title, description and canonical tag in that HTML, which in practice means server rendering or prerendering. A sitemap, sensible internal links and real text on the pages do the rest.
Own hosting, own repository and maintenance
The code should live in a repository the company owns, with access for more than one person, and the app should run on hosting in the company's own accounts, with the domain, database and backups in its own name. Then the project can move to another tool, developer or provider without anyone having to give permission. After launch come dependency updates, security fixes, monitoring of errors and a tested restore from backup. A review of web, IT and AI can establish where a project stands before you decide who takes it further.