ShipReady vs Lovable's built-in scan

Findings appear as an in-editor list tied to the project rather than a public score.

Source: https://docs.lovable.dev/features/security (read 2026-09-14)

No score, no grade, no badge. Every finding shows the request that produced it and the date it was read.

Findings are shown inside the Lovable editor to project members. There is no shareable public result.

Source: https://docs.lovable.dev/features/security (read 2026-09-14)

The full free result is shown to anyone with the check id. Nothing is gated behind a paywall or an account.

Reads project configuration and generated database rules directly. It does not sign in as your end users.

Source: https://docs.lovable.dev/features/security (read 2026-09-14)

Deterministic outside requests only. Never signs in, never executes a function on your database, never reads another account's data.

Neither an outside scanner nor a public research report can prove these from a URL. They need code, account, runtime or operational access.

• Rollback and recovery. Whether you can put the previous version back, and how long that takes.
• Error monitoring. Whether a failure in production reaches a human rather than sitting in a log nobody opens.
• Sign in and account flows. Whether sign in, password or code reset, and session expiry behave under real use.
• Rate limiting and abuse controls. Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down.
• Key rotation. Whether you can replace a leaked key quickly and know everywhere it is used.
• Certificate expiry date. Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request.
• One account reading another account's data. Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside.
• Payment handling. Whether payment events are verified, replay safe, and matched to the right customer record.
• Customer data handling. Whether stored personal details are limited, deletable on request, and out of your logs.
• AI feature controls. Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill.
• Database row rules. Whether the row rules behind the app actually stop one signed in account reading another's rows.

The editor can propose fixes into the project itself. It is scoped to Lovable projects.

Source: https://docs.lovable.dev/features/security (read 2026-09-14)

Every finding carries five fix prompts for Lovable, Bolt, Base44, v0 and generic coding assistants, hand written per finding.

Source: https://docs.lovable.dev/features/security (read 2026-09-14)

Apply the suggested fix inside the editor and re-run the scan on the same project.

Source: https://docs.lovable.dev/features/security (read 2026-09-14)

You can stop at the free check, or buy the Release Gate at $49 for the package, the Launch Review at $199 for a person, or the Hardening Sprint at $1,750 for the fix work.