How the service is wired to handle customer and Strava data.

Core commitments

• Use only the data needed to create, review, and fulfil an order.
• Respect Strava authorization and data-scope boundaries set by the athlete.
• Delete Strava-derived personal data on valid deletion requests or revocation events, unless law requires retention.
• Do not use Strava or customer order data for targeted advertising or resale.

Systems used by the service

• Strava for athlete authorization and activity data that powers artwork generation.
• Supabase for persisted order records when database-backed ordering is enabled.
• Stripe for checkout sessions, payment processing, and payment webhooks.
• Resend for transactional order, gift and approval emails when email delivery is configured.
• Bicep Press for print fulfilment, receiving the finished artwork, print specifications and delivery/contact information.
• Optional Sanity content tooling when the site is run in Sanity-backed CMS mode.

Security controls in the app

• Secrets such as API credentials and signing values are kept in environment configuration rather than page code.
• Stripe webhook payloads are verified before order-state updates are accepted.
• Internal render pages require a signed render access token instead of public access.
• Admin routes can be protected with HTTP basic auth when an admin password is configured.

Export handling

Final production exports are generated server-side and written into order-scoped export folders. Public static serving is blocked for those order export paths, and customer-facing order views expose status rather than open directory access.