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.