Ayasumar Gym

Ayasumar needed software that worked for three very different users at once: gym members who care about their access code and renewal dates, staff who need to look up anyone in seconds, and the owner who needs real revenue visibility without becoming a data analyst.

Plan logic — eight tiers ranging from a single-day pass to a one-year membership — had to thread cleanly through every layer of the stack, from the Postgres enum down to mobile UI components, without diverging.

The database is the source of truth — not the app. A membership_status view encapsulates the rules for what makes a membership active; the generate_access_code() RPC handles creation atomically; RLS policies enforce who can read what. All three client surfaces read from the same shape, so a change to the model propagates everywhere at once.

Mobile distribution uses a hybrid pipeline: JS-only changes ship over-the-air via eas update --branch production in seconds. Native or config changes go through a signed APK patch workflow (bundle → patch → zipalign → apksigner) with a locally stored keystore.

• ✦
  Eight plan tiers, one schema

  Postgres enum + RPC + view + typed config — plans don't drift between surfaces.
• ✦
  Three client surfaces

  Admin dashboard, member web app, and Expo + TypeScript mobile app.
• ✦
  Row-level security

  Authorization enforced at the database, not just at the UI.
• ✦
  Hybrid mobile delivery

  OTA for fast JS updates, signed APK patches for native changes.