Client context
Fit & Flex is client work, deployed as Fast-n-Fit at fast-n-fit.netlify.app. Introfinity contributed product and engineering on gym membership operations; client-owned brand assets and unpublished internals remain with the client.
Membership software that ignores money
Fit & Flex began as a basic operational system for members, plans, branches, and memberships. On paper, that looks complete. Independent gyms already try to solve the same surface area with spreadsheets, chat threads, and inconsistent desk processes. A product that centralizes those objects can feel like progress immediately.
Real operations exposed a larger issue. Renewals get lost. Partial payments become tribal knowledge. Receipts are afterthoughts. Staff collect cash, UPI, and cards in the same afternoon. A member says “I already paid” and nobody can reconstruct the timeline from the membership row alone.
The original framing was too narrow because it treated membership state as the source of truth for money movement. Then the real rule appeared:
A membership renewal is a financial transaction, not just an expiry-date update.
That sentence changed the product. Once renewal is understood as money movement plus period extension plus an auditable artifact, the system has to become a small operations platform — not a CRM with a date picker.
The modeling lesson behind that rule — payments as events, membership as derived state — is covered in Why Membership Renewal Needed a Payment Ledger.
Why the expiry-date model fails in a gym
An expiry date is a consequence, not an event. It can tell you when access should end. It cannot tell you what was paid, by which method, against which period, by whom at the branch, or what receipt the member was sent.
That missing event history is where gym operations actually live. Desk staff do not argue about elegant membership objects. They argue about payments, pending balances, renewals that were promised, and receipts that need to be forwarded on WhatsApp. If the software cannot speak that language, the spreadsheet returns — and the product becomes a second system that nobody trusts for money.
Membership and renewal as an explicit workflow
Plans were extended with explicit duration. Supported examples included 1 month, 3 months, 6 months, and 12 months. Duration is not decorative metadata. It is the unit of commercial time the gym sells.
Renewal became an explicit workflow:
- payment
- membership period extension
- transaction record
- receipt
- audit history
Each step exists because the previous one is incomplete without it. Payment without period extension creates “I paid but I’m still expired” conversations. Extension without a transaction creates disputes. A transaction without a receipt creates operational noise in chat. History without audit makes every argument unresolvable.
The workflow also forces product honesty. Renewal is not a button that flips a date. It is a commercial event with side effects that must remain coherent across membership state, money, and communication.
The payment ledger as the real system of record for money
A dedicated payments collection was introduced. Payments contain amount, payment method, status, and membership period. That created an actual financial history instead of deriving everything from membership state.
If you reverse-engineer “what was paid” from the current membership row, you lose partial payments, method changes, failed attempts, and branch context. A ledger keeps the events. Membership status becomes derived state rather than a substitute for the event log.
This is also where relational discipline pays off. Money, membership periods, and transaction identity want constraints. Flexibility at the edges is useful. Ambiguity at the center of payments is expensive.
Receipts are a product surface, not a report
The platform introduced structured transaction IDs in the form FNF-YYMMDD-XXXXXX. Receipts could be viewed, printed, generated as PDF, and shared through WhatsApp. Server-side receipt generation was implemented using pdf-lib.
A public receipt route was also introduced so a receipt could be shared without requiring login. That required careful separation between public receipt data and private member data. The artifact staff actually forward cannot drag the whole member record into a public URL.
In gym operations, the receipt is often the product moment. Members keep it. Staff share it. Desk conversations orbit it. Treating receipts as reporting afterthoughts means ignoring the object people already trust. Fit & Flex made the kept object first-class.
WhatsApp is part of the transaction path
Receipt delivery explored multiple paths: WhatsApp Cloud API document delivery, text sharing, and a wa.me fallback. Communication became part of the transaction workflow rather than a manual follow-up chore.
That choice reflects how independent gyms actually operate. The branch does not live inside a polished admin dashboard all day. It lives in chat threads, desk handoffs, and “send me the receipt” moments. If the product cannot meet that surface, staff invent their own process around it — and your system of record becomes incomplete by design.
Payments workspace and dashboards that route work
The branch payments area evolved to support activity history, filters, open balances, transaction lookup, and member transaction history. These are not analytics niceties. They are the screens that prevent money knowledge from living in one person’s head.
Dashboard cards also became operational entry points rather than vanity metrics:
- Active Members → members
- Revenue Today → today’s payments
- Renewals → renewal workflow
- Expired → expired members
- Pending → pending payments
The dashboard stopped reporting the business and started routing the desk into the next action. That is the difference between software that documents operations and software that runs them.
Current direction
Fit & Flex is becoming a small gym operations system covering membership lifecycle, payments, renewals, receipts, branch operations, customer transaction history, and operational dashboards.
The through-line is ledger-first thinking. Money movement is recorded. Membership state follows. The artifacts people share are treated as product surfaces. Branch workflows are designed around how gyms already communicate and collect.
That is how a “membership app” becomes operating infrastructure for modern gyms — not by adding more CRM fields, but by taking renewal seriously as a financial system.
Status: Live at fast-n-fit.netlify.app.