Privacy & trust

Your data should feel safe here.

Burn Board stores personal workout-profile information so the app can become more useful, but we should be clear about the boundary: we do not need to treat your data casually to make the product feel smart. Sensitive profile data stays inside Burn Board systems, and the goal is to keep marketing/email tooling away from body metrics entirely.
Profile-aware, not surveillance-yWe use saved preferences and workout context to make the app more useful before class — not to build some unrelated data profile.
Transactional vs. marketing stays separatedTomorrow-intel emails and product updates should not share more data than necessary just because both happen to be emails.
Boundary
Need-to-know only
The product needs enough data to personalize workouts, forecast efforts, and control alerts. It does not need to turn body metrics into marketing payloads.
Alerts
Separated
Notification settings are treated differently from broader update preferences.
Passwords
Hashed
Credential storage is designed to stay out of plain-text territory.

What Burn Board collects and how it should be treated

The short version: enough to personalize the product, not a bunch of random extra baggage.
What we collect

Only the profile data needed to personalize the app

  • account basics like email and display name
  • preferences like class format and units
  • pace and rowing profile details
  • optional body/performance fields like age, weight, and height
  • workout ratings, attendance history, and notification preferences
What we do not do

We do not use sensitive metrics like marketing fuel

  • we do not sell your personal information
  • we do not send body metrics to email-marketing vendors
  • we do not need your profile details to appear in newsletters or broad audience tools
  • transactional email providers should receive only what is necessary to send the message
How it is used

Product personalization, not creepiness

Your saved profile can help Burn Board generate more relevant workout context, forecasts, benchmark planning, and alert behavior. The purpose is to make the app more useful before class — not to create a shadow profile for unrelated uses.

Email & alerts

Clear preference controls

Burn Board keeps separate controls for workout-intel alerts and product-update emails. That means transactional notifications and marketing updates should not be treated like the same thing.

Security posture

Where the system is headed, and what guardrails matter most right now.
Password handlingPassword data is stored as salted / hashed values rather than plain text.
Storage directionBurn Board is actively moving toward Postgres as the primary datastore instead of flat JSON files serving as the long-term source of truth.
Outbound minimizationTransactional email is handled separately from app storage, and the goal is strict minimization of what leaves the system.
AuditabilityWe want cleaner backups, better operational visibility, and stronger separation between product data and outbound communications.
Burn Board is still in the phase where product quality and infrastructure quality are being tightened at the same time. The direction is straightforward: less ambiguity, less fragile storage, less over-sharing with outside services, and a clearer wall between app intelligence and marketing systems.
Account security

Login/security data should stay tightly separated from product personalization and outbound messaging systems.

Storage direction

The long-term target is a more durable, auditable, backup-friendly app data model with fewer risky runtime artifacts acting like source-of-truth storage.