Snapshot, launch review or deep review: which do you need?
Choose a review by the question you need answered—not by buying the largest report. A public snapshot, source-assisted review and penetration test provide different evidence and require different levels of access and authorisation.
Choose a snapshot for public exposure
A snapshot answers: “What can an ordinary visitor discover or observe?” It is appropriate for a marketing site, early prototype or quick external baseline. It can identify exposed files, browser-visible secrets and configuration weaknesses, but it cannot assess private code, authenticated permissions or business logic.
Choose a launch review before real users or payments
A launch review combines the live application with focused, read-only source access. It is a better fit when the product has sign-in, customer data, Supabase or Firebase rules, APIs or a payment flow. The objective is a short, prioritised list of issues that could materially affect launch—not an exhaustive assessment of every component.
Choose a deep review for sensitive or multi-role systems
A deep review is appropriate when the application holds sensitive information, moves money, serves multiple organisations or has complex permissions and background workflows. More time is spent tracing trust boundaries, tenant isolation, privileged actions, provider callbacks, error paths and production configuration. The result should include evidence, affected code locations and an ordered remediation plan.
Choose a penetration test when you need controlled exploitation
A penetration test attempts to demonstrate exploitable weaknesses within written rules of engagement. It requires confirmed ownership or authorisation, named targets, test accounts, exclusions and an agreed window. A fixed-price test can only remain credible when the application and API surface fit a clearly bounded scope.
Three questions that make the choice clearer
- What could be harmed? Consider customer data, money, operational access and contractual commitments.
- What access can you provide? Public URL, read-only repository, test accounts and a safe test environment reveal different risks.
- What evidence do you need? A founder's launch checklist, customer assurance request and formal penetration-test report are different deliverables.
If the smallest review uncovers a wider risk, the next step should be scoped before more work or payment is requested. Compare ByteAssure's published scopes.