Run a club on one system — even when the network drops.
QR check-in, verified payments and member records for Indian clubs. Built to keep working when the connection doesn't.
Three roles. One club. One record.
What a club runs on today
Four things break in almost every club we visit.
Attendance lives in a notebook.
Nobody can tell you who trained yesterday, or when a member quietly stopped coming.
Payment status is a screenshot.
The desk lets a lapsed member in because nobody at the door can see the dues.
Renewals are remembered, not tracked.
The member who lapsed in March gets found in July, three months of revenue later.
The wifi drops and the desk stops.
Cloud-only tools fail at exactly the moment the queue at the counter is longest.
- 3
- roles, each with its own app
- 1
- record per club, enforced in Postgres
- paise
- the unit money is stored in
- 0 bars
- needed to check a member in
How it works
One member, from the door to the ledger.
Six steps, and the same six screens a club actually uses. The two that matter most are where the network fails and then comes back.
The dip is the point. Everything above the line needs a connection; the club keeps running below it.
New member
Rahul's club · Coimbatore
Full name
Nithya Sundaram
Mobile
+91 98••• ••210
Plan
Quarterly · ₹5,400
Starts
Today
One record, scoped to this club.
- 01
A member joins.
The owner adds them at the desk, or the member registers themselves and the club approves it. One record, one club.
- 02
They get their QR.
The member's code lives in their app, tied to their membership. Nothing to print, nothing to lose, nothing to reissue.
- 03
The desk scans.
Reception scans the code, or searches by name or phone and checks the member in by hand. Dues show at the door, before the member walks in.
- 04Degraded, and saying so
The network drops.
The check-in is written to the phone's own database and marked queued. The desk keeps moving. Nothing is shown as synced that isn't.
- 05Reconciled
The connection returns.
The queue replays in order, idempotently. A retry cannot double-count a check-in, and it cannot double-charge a rupee.
- 06
The owner sees it.
Attendance, dues, collections and renewals resolve into one dashboard — reconciled from the backend, not from the phone that made the payment.
Three roles
Everyone gets the screen their job needs, and nothing else.
Runs one club, end to end.
The owner sees the whole club in one place: who is training, who has not paid, and what came in this month.
- Members, staff, plans and the unpaid and inactive lists
- Collections, invoices and revenue reports in integer paise
- Their own Clubync subscription and club settings
Your club
- Collected142 payments₹4,86,200
- Outstanding23 members₹78,400
- Active membersof 341 total318
- Renewals duenext 7 days19
- Check-ins todaypeak 6–8pm127
Illustrative figures, not a real club.
What it does
Six things, built properly, instead of thirty half-built.
QR attendance
Members carry their code in the app. Reception scans it, or falls back to search and manual check-in when a phone is flat.
Verified payments
Razorpay orders are created in a server function and finalised by webhook. Cash is recorded by the owner and lands in the same ledger.
Offline check-in
Check-ins are written to on-device SQLite and replayed in order with idempotency keys. A queued entry is labelled queued until the backend confirms it.
Multi-tenant by design
Every read and write is scoped to one club and enforced by row-level security in Postgres, not by a filter in the app.
Revenue and invoices
Collections, outstanding dues, payment mix and invoices, computed in integer paise so a total never drifts by a rounding error.
WhatsApp and SMS reminders
Renewal reminders go out on the channel members actually read, so a lapse is caught in days rather than months.
Every screen
Seven screens, three roles, one record underneath.
- OwnerThe month at a glance
- OwnerEvery member, filtered
- OwnerAdding someone at the desk
- Front deskWho has arrived
- Front deskStill owing
- MemberTheir pass
- MemberTheir attendance
Illustrative figures, not a real club. Every label, tab and state is the app's own.
Offline-first
The connection is not a prerequisite.
A club's busiest hour is often its worst hour for signal. Clubync treats that as normal, not as an edge case.
- Check-ins are written to the device's own SQLite database the moment they happen.
- Each queued entry carries an idempotency key, so a replay cannot double-count it.
- The queue replays in order when the network returns, then the screens refresh from the backend.
- A queued entry reads as queued in the app. Nothing is ever shown as synced before it is.
Trust
A club's records are not something to be casual about.
- Row-level security
- Every query is scoped to one club in Postgres. Tenant isolation does not depend on the app getting a filter right.
- Roles come from the database
- A user never picks their own role. It is resolved server-side after sign-in, then the app routes accordingly.
- Payments settle by webhook
- The device that made the payment does not get to declare it successful. Razorpay's webhook reconciles it.
- Money is integer paise
- No floats anywhere in the money path, so a report and an invoice cannot disagree by a rounding error.
- Logs carry no PII
- No phone numbers, no OTPs, no payment payloads, no raw QR contents. Identifiers are redacted before they are logged.
- Errors are tracked
- Sentry captures failures in production with PII scrubbing on, so a bug at a club's front desk is visible to us.
Pricing
Priced per club, not per member.
Starter
One club, one desk.
₹1,499/ month
- Up to 200 members
- Up to 3 staff
- Up to 5 plans
- QR and manual check-in
- Online and cash payments
- Offline check-in queue
- Member app
Growth
Most clubs start hereA club that is filling up.
₹2,999/ month
- Up to 750 members
- Up to 10 staff
- Unlimited plans
- Everything in Starter
- Revenue and payment-mix reports
- Invoices
- WhatsApp and SMS reminders
Pro
A club that runs like a business.
₹5,999/ month
- Unlimited members
- Unlimited staff
- Unlimited plans
- Everything in Growth
- Inactive and renewal tracking
- Priority support
- Onboarding assistance
Every club starts on a trial. If a subscription lapses the club keeps read access to its own data — records are never held hostage.
Questions
The ones owners actually ask.
The front desk keeps checking members in. Each check-in is written to the phone's own database and marked queued, and the queue replays in order once the connection returns. The one thing the app will not do is pretend a queued entry is already synced — it stays labelled queued until the backend confirms it. Payments are the exception: those need a live connection, because a payment nobody can verify is worse than a payment that has to wait.
The club's. Members, attendance and payment records belong to the club that collected them. You can export them, and if you stop paying, the club keeps read access to its own history rather than losing it.
They don't need one. Sign-in is an SMS OTP to the member's phone number. There is no password to reset and nothing for the front desk to look up.
Yes. The owner records a cash payment and it lands in the same ledger as an online one, so collections, dues and the payment mix stay accurate. Nothing forces a member online.
The club, its plans and its staff can be set up in an afternoon. Importing an existing member list is the part that takes real time, and how long depends on what shape your current records are in — we help with that.
There is no class or trainer scheduling, no diet or workout plans, no biometric hardware integration, and no web dashboard — Clubync is a mobile app today. We would rather say that plainly than have you find out in month two.
See it running against your club's real numbers.
Half an hour, your members, your plans. If it does not fit how your club works, we will tell you.