Snag: production-readiness checklist

Date: 3 October 2026.

Scope: mobile app, backend, VPS and marketing website. Desktop controls apply before that platform launches, not as blockers for a mobile-only launch. Payment controls apply when a paid offering is enabled.

This guide summarizes agreed recommendations and additional launch checks. It is not a current-state audit, security certification or compliance approval. No new VPS, repository or production-build tests were performed for this documentation. All controls remain unverified until evidence is recorded.

Companion: privacy, trackers, valuation and scan statistics. The French guide contains the full 126-item operational checklist; the English guide groups the same control areas for review.

1. Evidence and priorities

Record owner, date, tested version, evidence and result for each control: pass, fail or justified not applicable. A checked box without evidence is not validation.

• P0: launch blocker when a critical data, access, availability or cost risk is demonstrated.
• P1: required before the relevant scope opens; exceptions need explicit acceptance, mitigations and a deadline.
• P2: planned hardening; severity can increase with exposure.

2. API controls, not just client identification

A public mobile API must be reachable from users' networks. Attackers can reproduce requests or use genuine devices. CORS, User-Agent, custom headers and embedded global keys do not prove a legitimate client. Protect operations and data regardless of client.

• [ ] P0 Test two accounts: A cannot read/change/delete B's private data by substituting IDs, including server-managed binders, history, valuations, exports and shares.
• [ ] P0 Test privileged routes and missing/invalid/expired/revoked credentials; account deletion must actually invalidate access.
• [ ] P1 Secure token storage, keep provider secrets out of clients, and verify safe account recovery/device replacement.
• [ ] P1 Limit account/device creation, login/recovery and email flows. Anonymous device accounts do not prevent automated account multiplication.
• [ ] P1 Enforce PRO entitlements and quotas on the server.
• [ ] P0 Bound paid requests, scan concurrency, execution time and budgets; provide a protected cutoff that preserves collections.
• [ ] P1 Combine appropriate account/IP/device signals, handle shared networks and validate trusted proxy/IP headers.
• [ ] P1 Validate types, fields, SQL inputs, pagination, exports, paths, uploads, decoded dimensions and malformed images.
• [ ] P1 If fetching client-supplied URLs, restrict destinations and test internal-network/metadata access. Redact sensitive errors.

Sources: OWASP REST security, API Security Top 10.

Client integrity

• [ ] P2 / risk-dependent Assess Android Play Integrity and iOS App Attest, validated server-side and bound to actions with replay protection.
• [ ] P1 if enabled Test development, store testing, production and attestation outages; observe rejection before enforcing broadly, without a general sensitive-action bypass.
• [ ] P2 Consider obfuscation/hardening as complementary controls, not backend authorization.

Sources: Google, Apple.

3. VPS and administration

• [ ] P0 Check actual exposure externally over IPv4/IPv6, including Docker and provider firewall rules. PostgreSQL, Redis, model services, diagnostics and administration must not be unprotected public services.
• [ ] P1 Use HTTPS for clients, verify renewal/proxy routing and prevent bypass via internal ports.
• [ ] P1 Use SSH keys and private/VPN admin access where appropriate. Test another working access path before lockout-prone changes.
• [ ] P1 Minimize privilege and revoke obsolete access; Docker access usually implies root-level power.
• [ ] P1 Protect GitHub, hosting, DNS and store accounts with MFA and controlled recovery.
• [ ] P1 Check container privileges, mounts, isolation, CPU/RAM bounds and sensitive-file permissions. Review OS/base-image patches; changes require validated scope and backup.

4. Dependencies and delivery chain

• [ ] P0 Scan repositories/history, CI logs, artifacts and mobile bundles for secrets; revoke exposed secrets rather than just deleting files.
• [ ] P1 Audit deployed direct/transitive dependencies, native SDKs, images and OS packages. Assess reachability, exploitation and supply-chain impact, including build tools.
• [ ] P0 Fix or neutralize exploitable critical/high vulnerabilities before opening; document other findings.
• [ ] P1 Use lockfiles and identified versions; avoid untested major upgrades. Check CI permissions, external actions, protected branches and staging/production secret separation.
• [ ] P1 Release the identified, tested artifact: commit, app version and image digest when available. A different rebuild needs new validation.

5. Backup, migrations and rollback

• [ ] P0 Back up DB and recovery-critical files encrypted off-VPS with restricted access; actually restore in isolation and verify accounts, holdings, images and API behavior.
• [ ] P1 Agree RPO/RTO, schedule and retention; monitor missing backups and regularly test recovery. Same-provider snapshots alone do not cover all failures.
• [ ] P0 Test migrations on representative data, locks, duration and compatibility with the previous API.
• [ ] P1 Document deploy, smoke checks and rollback. A Git tag does not restore DB/volumes or undo migrations.
• [ ] P1 Avoid blindly restoring an old DB: it can lose new writes and reintroduce erased data.

Source: CNIL backups.

6. GDPR and retention jobs

• [ ] P1 Inventory actual data/SDKs/flows across relevant platforms; maintain the applicable processing register with justified legal bases, recipients, retention and rights.
• [ ] P1 Assess processor contracts and outside-EEA transfers. EU hosting does not imply every provider stays in the EEA.
• [ ] P1 Publish accurate legal/privacy documents and relevant use/subscription terms. Assess actual necessary/optional trackers; consent must precede non-exempt tracking with easy withdrawal.
• [ ] P1 Separate contracts, optional consent and camera/notification permissions; explain photo upload, diagnostics, model reuse and public sharing.
• [ ] P1 Test applicable access, rectification, erasure and portability with proportionate identity checks. Reconcile Apple/Google declarations and deletion paths, including Google's external web resource.
• [ ] P1 Assess minors, target-country rules, DPIA and DPO requirements rather than assuming applicability/non-applicability. Prepare breach handling, including required 72-hour notification.

Valuation and statistics

• [ ] P1 Separate private valuation, personal history and internal statistics; privacy defaults exclude acquisition data and valuation from sharing unless selected.
• [ ] P1 Prefer account-independent card + day + count; define attempts/success/confirmation, deduplication and abuse handling.
• [ ] P1 Assess reidentification and necessary source data; hashed IDs are not automatically anonymous. Send providers only necessary card characteristics.
• [ ] P1 Contract performance covers necessary service processing, not arbitrary analytics; legitimate interests cannot bypass tracker consent.

Batch safety

• [ ] P1 Agree retention first; purge expired photos, diagnostics, individual events and logs. Handle requested account deletion, derived data, personal caches and justified exceptions.
• [ ] P1 Expire shares/sessions according to policy; jobs must be bounded, idempotent, observable, dry-run tested and protected against unsafe overlap.
• [ ] P1 Test partial failure/retry and DB/file relationships without affecting other users. Address backup aging and erasure reapplication after recovery with minimized tracking data.

Sources: CNIL first steps, retention, DPIA, breaches. See the companion privacy guide for details.

7. Product and data reliability

• [ ] P0 Test holding writes/sync under double taps, retries, interruption and restart without loss or duplicates.
• [ ] P1 Test updates from previous mobile versions and API compatibility; store adoption is not immediate.
• [ ] P1 Preserve card IDs and condition/language/grading/variant context across recognition, holdings and valuation.
• [ ] P1 Benchmark scan accuracy/latency on representative French/One Piece captures, glare, lighting, close variants and out-of-catalog cards. Prefer uncertainty/confirmation over silent wrong additions.
• [ ] P1 Verify quantities, currencies, rounding, missing prices, partial valuations and freshness. Provider failure or missing quotes must not become zero.
• [ ] P1 Test sharing scope, revocation, intended expiration and unintended private fields.

8. Load, outages and costs

• [ ] P1 Agree load, peak margin and latency goals; test representative staging, sustained overload, p95, errors, queues, DB pools and memory.
• [ ] P1 Test slow/unavailable pricing, Redis outages, restarts and disk pressure; bound retries/timeouts and avoid paid fallback stampedes.
• [ ] P1 Coalesce simultaneous quote refreshes; define stale-data behavior. Preserve collection reads when scan/pricing degrades where possible.
• [ ] P0 Enforce paid-call/resource limits, budget alerts and cutoffs. Team-agreed thresholds replace arbitrary numbers.

9. Builds, stores, website and subscriptions

• [ ] P1 Test identified signed production artifacts on launched platforms, not only Metro/emulators. Check production URLs, versions, signatures, permissions and absence of debug/test data.
• [ ] P1 Test permission denial, weak networks, compact displays, large text, dark mode and assistive access. Assess applicable accessibility requirements.
• [ ] P1 At desktop launch, validate signing and secure updates. Check website forms, legal links and external content against consent decisions.
• [ ] P1 if paid Test purchases, restoration, renewal, expiry, cancellation and refunds; validate receipts server-side and signed, duplicate/out-of-order payment events.
• [ ] P1 if paid Legally review trial, tax-inclusive pricing, renewal, cancellation, withdrawal and mediation for actual channels. Remove unavailable promises/offers.
• [ ] P1 Verify commercial, redistribution, cache and attribution rights for images, logos, catalogs and pricing; attribution alone is not authorization.

Sources: Service Public, DGCCRF withdrawal, Apple, Google.

10. Operations and launch

• [ ] P1 Monitor availability, errors, latency, storage, backup/purge outcomes and spend; test alert delivery. Redact and bound logs.
• [ ] P1 Health/readiness must be useful without public sensitive details. Assign alert, rollback and privacy/support owners.
• [ ] P1 Prepare outage, breach, provider failure, takeover and scan-abuse procedures; provide working support and incident communications.
• [ ] P1 Run controlled beta and progressive opening with suspension criteria. No destructive/load production testing without explicit scope/approval.

11. Additional gaps to assess

Recovery/device changes, old-app compatibility, private exports/shares, CI and bundled secrets, decoded upload limits and server fetch destinations, uncertain recognition, incomplete valuations, payment events, source licenses, erasure after restoration, accessibility and operational ownership all require review. Their inclusion is not proof of a defect in deployed Snag.

12. Proposed automation

These jobs are recommendations, not installed schedules. Cadences must match goals, volumes and budget. No VPS changes, migrations or purges are authorized by the guide alone.

Job	Suggested trigger	Evidence / safeguard
Lint, types, unit tests	Each PR	Blocking failures, no weakened rules.
Integration and account isolation	Relevant PR/before promotion	Isolated DB, no production data access.
Dependency/image/secret audit	Relevant PR plus periodic, e.g. weekly	Owner, triage/deadline; no blind major upgrades.
Production build/journey tests	Before delivery	Identified artifact and compatibility evidence.
Deploy and smoke checks	After human approval	Safe migrations and documented recovery.
DB/file backup	According to RPO	Encrypted off-VPS, integrity/missing-backup alerts; daily alone cannot cover an RPO below 24 hours. Assess incremental/WAL options if needed.
Restore drill	Prelaunch, periodically e.g. monthly, after material change	Isolated functional verification and measured recovery time.
Retention/expiry jobs	According to agreed policy, often daily	Dry run, bounded idempotence and overlap protection.
Requested deletion	On request, bounded retries	End-to-end tracking, associated data and backups procedure.
External availability	Continuous, e.g. every 1-5 minutes	Off-VPS, confirmed failure, low cost, synthetic data.
Synthetic scan/collection flow	Bounded cadence/cost	Isolated test account and authorized fixture, no real holding writes.
Certificate/domain expiry	Periodic, e.g. daily	Advance notice and real renewal verification.
Resources, errors and spend	Continuous	Actionable bounded/private metrics.
Health review	Appropriate daily/weekly review	Backup age, purges, incidents, budgets and open actions; not a substitute for paging.

• [ ] P1 Every job needs owner, timeout, success evidence, absence/failure alert and safe retry/concurrency handling.
• [ ] P1 Least privilege, proper secret handling and resource limits keep heavy jobs from starving scans/holding writes.
• [ ] P1 Test failures in isolation. Bound and alert automatic restarts; restart loops are not repairs.

Do not blindly automate reboot, major upgrades, destructive migrations, DB restores, deletion or data-incompatible rollback.

13. SRE goals and degraded operation

Measurable reliability

Measure user journeys rather than just running containers. Agree collection success/latency, scan end-to-end latency/technical failures and independently measured accuracy, pricing coverage/age/cost, RPO/RTO and provider cutoffs. No system guarantees zero incidents.

• [ ] P1 Set realistic SLOs, windows and justified exclusions; never hide server errors. Define an error budget and release suspension rule.
• [ ] P1 Distinguish recognition correctness from technical scan success and align public promises with tested capacity.

Minimal observability

Track API traffic/errors/latency and quota rejects; scan backlog/concurrency/failures; DB pools/slow queries/locks/disk; Redis memory/eviction/hit rates/external calls; CPU/RAM/OOM/inodes/restarts; provider errors/freshness/spend; backup/job age/duration/failures and recovery drills; production app crashes with minimized, appropriately disclosed collection.

• [ ] P1 Avoid unneeded user/token/per-card metric labels; control cardinality, retention, access and costs.
• [ ] P1 At least one probe and alert-delivery path must be independent of the monitored VPS.

Alerting and response

Page for sustained collection/API outage, harmful saturation, threatened data recovery or costs/security emergencies; make nonurgent anomalies tracked work. Alert proactively on disk growth, backup age, purge failures and expiring certificates. Group related alerts and tune sustained thresholds; introduce SLO burn-rate alerts once metrics are trustworthy.

• [ ] P1 Every alert has primary/backup owner, severity, tested delivery, response procedure and agreed acknowledgement/coverage. Do not promise nonexistent 24/7 staffing.
• [ ] P1 After material incidents, record timeline, impact, causes and prevention without blame.

Isolation and fallback

• [ ] P0 Scans/batches cannot consume unbounded resources required by collections.
• [ ] P1 Bound queues, concurrency, DB pools and timeouts; reject overload cleanly. Use bounded progressive retries with jitter and provider circuit breaking.
• [ ] P1 Redis failure cannot trigger unlimited paid calls. Separately decide price and quota failure behavior if both use Redis.
• [ ] P1 Serve stale prices only under an explicit visible-freshness policy; never invent values. Protect and test feature/scan/pricing cutoffs.
• [ ] P1 Test shutdown/restarts with in-flight writes and jobs; reserve CPU/RAM/disk and define scaling triggers.

Start with external probes, essential metrics, bounded logs, recovery and actionable alerts; reuse existing tooling. Kubernetes/multi-region is not a prerequisite. A single VPS remains a single point of failure. Off-VPS recovery is not high availability. If objectives require continuity during host failure, design and test redundant failover.

Sources: Google SRE monitoring, SLO alerting. Cadences/tools/architecture are Snag recommendations, not mandates from these sources.

14. Launch decision and evidence

Order: account isolation > exposure/secrets > tested recovery > abuse/costs > effective privacy > production journeys > operations.

Do not launch with cross-account leaks/modification, unprotected DB/Redis/admin, compromised secrets, untreated exploitable critical vulnerabilities, untested recovery/unsafe migrations, unbounded costly operations, reproducible collection loss, required consent missing, noncompliant deletion or an active paid offering lacking entitlement/contract validation.

Missing attestation/obfuscation is not automatically a blocker when essential protection is verified and risk accepted. Presence of either does not certify backend safety.

Area	Owner	Version/date	Evidence	Result/action
API/account isolation	TBD	TBD	Required	Unverified
VPS/network/dependencies	TBD	TBD	Required	Unverified
Backup/migrations/recovery	TBD	TBD	Required	Unverified
Abuse/load/cost	TBD	TBD	Required	Unverified
GDPR/docs/purges	TBD	TBD	Required	Unverified
Product/builds	TBD	TBD	Required	Unverified
Payments/licenses if applicable	TBD	TBD	Required	Unverified
Alerts/support/launch approval	TBD	TBD	Required	Unverified
Automation/SRE/fallbacks	TBD	TBD	Required	Unverified

Current status: evidence not recorded. Actual missing work requires inspection and tests of the deployed scope. This documentation activates no jobs or infrastructure.