Back to projects

Project

Apex Setup Vault

Problem

Track riders make setup changes under pressure. Notes end up in screenshots, group chats, memory, or disconnected documents. That makes the next session harder to reason about.

Apex treats the iteration loop as the product:

Bike current setup -> Adjustment -> Session outcome -> next Adjustment

Core decision

The system keeps three setup states separate:

• bike.current_setup is the mutable live setup.
• setup_presets are reusable templates, not history.
• sessions.setup_snapshot is the immutable copy of what was run.

That distinction keeps historical sessions from changing when the rider edits a bike later.

Security model

Privacy is enforced in one place: Postgres Row Level Security. The backend sets the authenticated role and request JWT claims inside the request transaction. The app avoids using a privileged service-role key in normal user request paths.

The important part is not that the code has authorization checks. The important part is that the database policy remains the authority when routes, services, or future product surfaces change.

Tradeoffs

Apex is a modular monolith because the product still benefits from simple deployment, shared transactions, and clear boundaries. Search is exact before it gets fuzzy. Shop workflows stay gated until rider retention and shop demand are real.

The boring choice is the point. The system should get more obvious as it grows.