A 3-city gym chain in Pune, Nashik, and Aurangabad ran on four separate tools: a membership CRM, a class-booking app, a spreadsheet for attendance, and Razorpay payment links pasted into WhatsApp by hand. The owner paid ₹38,400 a month across the four, and the front desk still spent 40 minutes a day reconciling who had paid. We replaced all four with one custom portal in 6 weeks. This is what we built, the sprint breakdown, and the two numbers that made it worth it — front-desk time down 71%, renewal churn down from 19% to 11%.
71%
Less Front-Desk Admin Time
19% → 11%
Renewal Churn (6 months)
6 weeks
Kickoff to Go-Live
## The Answer in 60 Words
We built a single membership and booking portal: member profiles, plan management with auto-renewals on Razorpay, class scheduling with capacity caps, QR-code attendance, and an owner dashboard showing churn risk per branch. It replaced four subscriptions costing ₹38,400/month. Build cost: ₹4.6 lakh over 6 weeks. Payback on the tooling saving alone: about 12 months, before counting the churn drop.
## Why This Matters Now
Boutique and mid-size gyms in tier-1 and tier-2 India bolt together SaaS tools because each one solves a single problem. The hidden cost is the seams. When membership data lives in one app and bookings in another, nobody knows on a Tuesday morning whether a member who just booked a 7 am class has actually paid this month. By May 2026, per-seat SaaS pricing for fitness tools had crept up again, and the chain's renewal — quoted in March 2026 — pushed their monthly bill past ₹38k. That number is what tipped a build-vs-buy conversation we had been having for a year.
## The Client (Specific Details)
-
Sector: Fitness — 3 gyms, strength + group classes (HIIT, yoga, spin)
-
Locations: Pune (flagship), Nashik, Aurangabad
-
Size: ~2,100 active members across 3 branches, 28 staff (trainers + front desk)
-
Stack on day 0: A membership CRM (₹14,000/mo), a class-booking app (₹11,000/mo), Google Sheets for attendance, Razorpay payment links sent manually over WhatsApp
-
The trigger: Renewal quote in March 2026 pushed total tooling past ₹38,400/month. Owner gave us a fixed ₹5 lakh budget and asked for one login that does everything.
## The Old Workflow (Where the 4 Tools Leaked)
🪪
Membership CRM
Held profiles and plan dates. Did not know about class bookings. Renewals were a manual export-to-Excel job on the 1st of every month.
📅
Booking App
Let members book classes. Did not check whether the member's plan was active or paid. Over-booked the 6 pm spin class twice in one week.
📊
Attendance Sheet
A shared Google Sheet the front desk updated by hand. No link to bookings. Trainers could not see who was coming to their 7 am session.
💸
Manual Razorpay Links
Front desk generated a payment link per renewal and pasted it into WhatsApp. No record tied back to the member's plan automatically. Reconciliation was the 40-minute daily job.
The seams cost real money. A member could book a class with an expired plan, attend, and never be flagged. The chain estimated ₹60,000–₹90,000 a year in "ghost usage" — people training on lapsed memberships because no system joined the dots.
## What We Built (The Single Portal)
We shipped one web portal with a member-facing app and a staff/owner back office. The stack was deliberately boring: Next.js front end, a Node.js API, PostgreSQL, and Razorpay for payments and subscriptions. Boring is what you want when the thing has to run a business every morning at 6 am. We use this same pattern across our
CRM development work, and it is the same shape as the
Radiant Finance portal we built.
👤
Unified Member Profile
One record per member: plan, payment history, bookings, attendance, and branch. The front desk sees everything on one screen.
🔁
Auto-Renewals on Razorpay
Subscriptions via Razorpay's recurring API. Members opt into auto-pay; the system charges on the due date and updates the plan with no front-desk action.
🎟️
Class Booking With Gates
Booking checks plan status first. Expired or unpaid? No booking. Capacity caps per class kill the over-booking problem. Waitlist auto-promotes on cancellation.
📱
QR Attendance
Members scan a QR at the door. Attendance writes to the same profile in real time. Trainers see a live roster for their session.
📉
Churn-Risk Dashboard
Owner sees a per-branch view: who has not attended in 14 days, whose plan lapses in 7 days, and a simple risk score that sorts the list.
🏢
Multi-Branch Roles
A Nashik front-desk login sees only Nashik. The owner sees all three. Trainers see only their classes. Role-based access from day one.
## The Sprint Breakdown (6 Weeks, Copy This)
1
Week 1 — Discovery + data model
2
Weeks 2–3 — Members, plans, payments
3
Week 4 — Booking + attendance
4
Week 5 — Dashboard + migration
5
Week 6 — Pilot + go-live
1
Week 1: Map every plan, every edge case
We listed all 11 plan types — monthly, quarterly, annual, couple, student, corporate, and a few legacy plans grandfathered in. We mapped freeze rules (members pause for travel), the refund policy, and how a member transfers between branches. Verification: the owner signed off on a one-page state diagram of a membership's lifecycle before we wrote code.
2
Weeks 2–3: Members, plans, and Razorpay subscriptions
Built the member profile, the plan catalog, and recurring billing via
Razorpay Subscriptions. We handled the webhook for
subscription.charged and
subscription.halted so a failed card updates the member's status automatically. Verification: a test member's plan flipped to "payment failed" within seconds of a simulated card decline in the Razorpay test dashboard.
3
Week 4: Booking engine + QR attendance
The booking endpoint checks plan status before it writes a booking. Capacity is a hard limit per class slot; the waitlist promotes the next person on a cancellation. QR attendance writes to the profile in real time. Verification: we tried to book a 6 pm spin class as an unpaid member and got a clean "your plan is inactive" message — exactly the gate the old tools never had.
4
Week 5: Owner dashboard + data migration
We exported ~2,100 members from the old CRM as CSV, cleaned duplicates (the same person existed in two branches), and imported with a dry-run mode that reported mismatches before committing. The churn-risk view shipped here. Verification: member counts per branch reconciled to the old CRM's totals, off by 14 — all duplicates we then merged.
5
Week 6: Pilot at the Pune branch, then go-live
We ran the Pune flagship on the new portal for 5 days while the other two stayed on the old tools, so a rollback was trivial. After zero booking-vs-payment mismatches for 3 straight days, we switched Nashik and Aurangabad. Verification: front-desk staff at all three branches logged a full day without opening any of the four old tools.
## What You'll Need (If You Build This Yourself)
- A complete list of every plan type — including the legacy ones nobody talks about
- Written freeze, transfer, and refund rules signed off before any code
- A Razorpay account with Subscriptions enabled (KYC done — it takes days)
- A clean CSV export from your current CRM, with a plan to de-duplicate members
- Role definitions: who at each branch sees what
- A pilot branch where you can run new and old in parallel for a week
- A capacity number for every class slot, agreed with the trainers
## Common Mistakes (When Not to Build This)
You have one location and under 300 members. Off-the-shelf is fine. A single gym with one front desk does not feel the seams the way a 3-branch chain does. The maths only works above roughly 1,000 members or 2+ branches, where the per-seat SaaS bill and the reconciliation time are both real.
You skip the freeze and transfer rules. Every gym has members who pause for a month and members who move cities. If you model only the happy path, the front desk will be filing support tickets in week two. Model the pauses first.
You migrate without a dry run. We have seen a botched import create 400 duplicate members on a different project. Always import in a dry-run mode that reports what it would do, reconcile the counts, then commit.
You build a native app on day one. The chain wanted an iOS app immediately. We pushed back — a mobile-friendly web portal covered 95% of member needs at a fraction of the cost. The app became a phase-two decision once the portal proved itself. If you do need native later, that is a
mobile development scope of its own.
The most expensive mistake in fitness software is letting bookings and payments live in separate systems. Every "ghost workout" on a lapsed plan is revenue you already lost. Join those two things first, before anything else.
## The Numbers After 6 Months
71%
Front-Desk Admin Time Cut
11%
Renewal Churn (was 19%)
₹38,400
Monthly SaaS Bill Removed
~₹80k
Yearly "Ghost Usage" Recovered
The churn drop is the one the owner cares about. The churn-risk dashboard surfaces members who have not shown up in 14 days, and the front desk now makes a 2-minute "we miss you" call before the plan lapses. That one habit — powered by a list the old tools could never produce — moved renewal churn from 19% to 11% over two quarters. On ~2,100 members, that is a few hundred retained memberships a year.
"I used to spend Sunday nights exporting spreadsheets to figure out who hadn't paid. Now I open one screen on my phone and I can see all three gyms. The renewal calls write themselves."
— Owner, 3-city gym chain (name withheld on request)
## A Build-vs-Buy Cost Comparison
| Path | Year-1 cost | Year-3 total | Owns the data? | Fits all plan types? |
|---|---|---|---|---|
| Keep 4 SaaS tools | ₹4.6 lakh (subscriptions) | ₹13.8 lakh+ (with price hikes) | No | Partially — seams remain |
| All-in-one fitness SaaS | ₹2.4–3.6 lakh/yr | ₹7.2–10.8 lakh | No | Mostly, with workarounds |
| Custom portal (what we built) | ₹4.6 lakh (one-time build) | ₹5.6 lakh (build + hosting) | Yes | Yes — modeled to the business |
The custom build is not always the answer. For a single gym, the all-in-one SaaS wins on cost. For a 3-branch chain with 11 plan types and an owner who wants to own the member data, the three-year maths flipped clearly toward building. For a deeper look at that decision, our case study on a
7-city real-estate CRM where Salesforce was overkill walks the same trade-off in a different sector.
## Related Reading
As
Manvi, who led QA on this build, put it during the pilot: the test that mattered was not whether a happy-path booking worked — it was whether a lapsed member got stopped at the door. That single gate is what four separate tools could never enforce.
## Frequently Asked Questions
### How much does a custom gym membership portal cost in India?
For a multi-branch chain, expect ₹4–7 lakh for a first version covering members, plans, recurring payments, booking, and attendance. A single-gym build can come in lower. Hosting runs ₹3,000–8,000/month depending on member volume. We quote fixed scope after a discovery call.
### How long does it take to build a gym booking and membership system?
We shipped a working portal for a 3-city chain in 6 weeks: one week discovery, three weeks core build, one week dashboard and data migration, one week pilot and go-live. Timelines stretch if your plan rules are complex or your old data is messy.
### Can it handle auto-renewals and recurring payments?
Yes. We use Razorpay Subscriptions for recurring billing. Members opt into auto-pay, the system charges on the due date, and webhooks update the member's plan status on success or failure with no manual front-desk step.
### How do you migrate members from our existing software?
We export your current members as CSV, de-duplicate (the same person often exists in multiple branches), and import using a dry-run mode that reports mismatches before committing. We reconcile member counts against your old totals before going live.
### Does each branch get its own login and data view?
Yes. Role-based access is built in from day one. A branch's front desk sees only that branch; the owner sees all branches; trainers see only their own classes. This is standard in our CRM work.
### Will replacing four tools actually save money?
For this chain it removed ₹38,400/month in subscriptions and recovered roughly ₹80,000/year in "ghost usage" from members training on lapsed plans. The build paid back on tooling savings alone in about a year — before counting the churn reduction.
Outgrowing Your Stack of Fitness Apps?
We build custom membership, booking, and attendance portals for Indian gym, studio, and wellness chains in 6–8 weeks. Typical project: ₹4–7 lakh, fixed scope, you own the data. First call is with the engineer who'd lead your build — no slides, just your plan rules and our honest take.
Book a 20-min Call