▤
The roster was a chat thread
Membership was whoever happened to have been added. We built organisations with real membership records, custom roles and permissions, invites, join requests and bulk import and export.
Our work
One project, described properly.
We would rather show you one thing we can talk about honestly than a wall of logos we can't. Client work is under NDA and stays that way — so here is the product we built for ourselves, which we can open up completely.
A membership, payments and check-in platform for clubs and academies
Built, shipped and operated end to end by this team: React Native on iOS and Android, a Node and TypeScript API, MongoDB, Razorpay for money, and a browser back-office.
2app stores shipped to
10kinds of organisation supported
7event templates
~1,800automated tests passing
The problem
Coordination is free. The record is not.
Clubs, academies and community groups already coordinate perfectly well in a chat thread. What no chat has ever held is the roster, the money, and the answer to "who actually turned up" — which is exactly the part that has to survive a change of committee.
₹
The money was forty screenshots
We built collection through Razorpay with refunds handled in-app, and made every movement write an append-only ledger entry — so the treasurer's view and the bank statement can be reconciled a year later.
✓
Attendance was never recorded
Check-in by tapping a name or scanning a QR pass, made idempotent so a double tap is harmless, and queued locally so it works on a ground with no signal.
The hard parts
The four problems that took the longest.
These are the ones worth telling you about, because they are the ones that recur on client projects — and having solved them once with our own name on the outcome is what we are actually selling.
01 · Money
A ledger you cannot quietly edit
Anyone can store a payments table. The difficulty is guaranteeing that what the treasurer sees in November matches what the bank saw in March — including refunds, partial states and failed webhooks. We made every movement an append-only entry and reconciled from the ledger rather than from the UI.
What that took
- Idempotent webhook handling so a retried callback can't double-post
- Refunds as new entries, never as edits to the original
- A per-org audit log covering who changed what, and when
- Exports that reconcile against a bank statement line by line
02 · The door
Offline is the normal case, not the edge case
Check-in happens in a car park, a ground or a hall — places with one bar of signal and forty people waiting. Treating connectivity as an exception produces software that fails exactly when it is needed, so the offline path was designed first and the online one fell out of it.
What that took
- Optimistic local writes with a queue that survives app restart
- Idempotency keys so replaying the queue is always safe
- Conflict rules decided up front, not at sync time
- A find-by-name fallback for when a QR won't scan in sunlight
03 · Access
Roles that a committee can actually configure
Every organisation splits responsibility differently — a coach who takes attendance but must never see collections, a treasurer who isn't the admin. Fixed role names would have forced every group into one shape, so permissions are composable and the org defines its own roles.
What that took
- A permission catalogue rather than hard-coded role checks
- Server-side enforcement on every route, never UI-only
- Custom roles composed by the organisation itself
- An owner who cannot lock themselves out of their own org
04 · Shipping
Two stores, and everything they demand
Getting the build right is the easy half. The half that eats schedules is signing, provisioning, privacy nutrition labels, the Data Safety form, account-deletion requirements, universal links and staged rollout. We ran all of it ourselves, which is why we can now estimate it for you instead of guessing.
What that took
- CI-driven build numbering that can never reuse a version
- Release signing wired through CI with keys held by the owner
- In-app account deletion plus a public deletion URL
- Universal links and app-site association on both platforms
- Crash reporting and release health from the first build
Where it is now
Feature-complete, in pilot, and honest about the rest.
Shipped and working
Organisations and custom roles, discovery by map and category, events with templates and waitlists, collections through Razorpay with refunds, the append-only ledger and treasurer view, offline check-in, public share pages, and a browser back-office.
Deliberately not built
We decided against building our own group chat. It would have been the largest thing on the roadmap, aimed at a free product every member already has open. Saying no to it is the single most valuable product decision in the project.
What that gives your project
When we tell you that offline sync is harder than it looks, that store review will eat a week, or that a reconciled ledger is worth building properly the first time — it is because we paid for each of those lessons on our own product, not on yours.
Client work
Yours won't be on this page.
Client projects stay confidential unless you tell us otherwise — we will not put your name on a website to win someone else's business. Happy to walk you through relevant work on a call, under NDA if you'd prefer.