What we were looking at
The founder built this app using Lovable to move fast. The core flow: users create a profile, upload documents, and the app uses AI to match them with relevant opportunities. It connects to several outside services for data, AI matching, and email.
On the surface, the app worked. Users could sign up, upload documents, search for opportunities, and track their activity. The question was whether it was safe to put real users on it.
Not everything was broken
User data was locked down
Data protection rules were in place on every database table. Users could only see their own data. This was set up correctly from the start.
Login checks on most features
Most of the app’s behind-the-scenes features properly checked that users were logged in. The pattern was there, just not applied everywhere.
Usage limits already built
The tools to prevent abuse were already in the app. They just weren’t connected to the features that needed them most.
Good error handling
When outside services failed or were overloaded, the app handled it gracefully instead of crashing. The defensive patterns were solid.
The security patterns already existed in some places. The roadmap focused on applying them everywhere. Targeted fixes, not a rebuild.
What would have caused real damage
The search feature calls paid outside services every time someone uses it, but it doesn’t check whether the person is logged in first. Anyone who figures out the right URL can use it directly. A single script could run up the bill in under an hour.
Request → parse JSON → call third-party API
// No rate limiting, no usage caps, no auth check
Add a login check (the pattern already exists elsewhere in the app), add limits on how often each user can search, and set a daily cap.
The AI matching feature trusts whoever calls it to say which user they are. It then uses a special admin-level connection to read that user’s personal data. Anyone can read anyone else’s personal information just by guessing their user ID.
const client = createClient(url, SERVICE_ROLE_KEY) // bypasses RLS
// Anyone can read any user's skills, job title, location
The audit also found: private keys accidentally saved in the project files and no restrictions on which websites can talk to the app. Both critical, both fixable in under 2 hours combined.
Where it breaks under load
The audit estimated costs from 10 users to 1,000+ and found that without login checks and usage limits, a single script could drain the budget in under an hour. The report included exact cost projections and which features were responsible.
Beyond security
Plus 18 more findings across performance, code quality, architecture, and scalability. Each with severity, evidence, and a suggested approach with effort estimate.
Production readiness roadmap
Close all critical security issues. Login checks, usage limits, website restrictions, and input safety.
Speed, accessibility, and code quality fixes. Make the app faster and easier to use for everyone.
Add a safety net for future changes, speed up loading, and clean up unused pieces.
Keep an eye on things, make the app fully accessible, add thorough testing, review outside services.
The audit turned 26 unknown unknowns into a prioritized, actionable roadmap. Every finding includes severity, code evidence, a suggested approach, and an effort estimate.