Where we actually are.
Most vendors keep this private. We publish it because a general manager who discovers the gap on a demo call is a lost deal, and one who reads it here and books anyway is a club we can serve properly. This page is shorter than it was a year ago, and the order of the buckets has changed — most of the platform is now in the first one.
No calendar quarters on this page. These buckets are a sequence, not a set of delivery dates. A date we cannot hit is worse than no date, and a club planning a migration around a quarter we miss has every right to be angry about it.
Built, tested and running
Every item here has a table, a route, a screen and a test that tries to break it. The same list module by module, with the gaps inside each one named
The financial backbone
- Append-only double-entry general ledger, enforced in the database
- Accounts receivable and member accounts
- One-door idempotent charge intake
- Recurring dues, prorated by days served, preview then commit
- Dues monthly or annually, the member's own choice
- Prepaid dues and initiation fees, deferred and earned monthly
- Itemised statements, one household one statement
- Payments recorded then settled, allocated FIFO
- Credit memos, write-offs, transfers, merchant fees as club expense
- Autopay with a retry policy
- Aging, late fees and the dunning ladder
- Membership ceasing, forfeiture and reinstatement
- F&B minimums with configurable qualifying spend and forfeiture
- Assessments, member vote thresholds and payment plans
- Departmental P&L
- Accounts payable with dated approval thresholds and payment runs
- Purchase orders, receiving and three-way match
- Banking, deposits and reconciliation that refuses to close out of balance
- Tax engine and multi-currency representation, with 17 countries pre-registered and the US pack shipping
The departments
- Tee sheet, booking and conflict resolution
- Rate cards, guest play and sponsorship
- Handicaps, GHIN, digital scorecards, round history
- The scorecard that goes round on a member's phone
- Competitions, leaderboards, countback, a season of standings
- Pin positions, course setup, maintenance queue, conditions
- Chemical and fertiliser application tracking, uneditable
- Frost and rain delay proposals, lightning evacuation
- Pro shop till: variants, stock, move ledger, COGS at weighted average
- F&B terminal: tabs, seats, splits, comps, voids, eighty-sixing
- Kitchen inventory, recipes, plate cost, usage variance
- Racquets: courts, privileges, professionals, ball machine
- Aquatics: deck sheet, lanes, the gate, lifeguard coverage, swim school
- Shooting: squads, waivers, clays, club guns
- Marina: slips, leases, waiting list, fleet, crew, regattas
- Personnel: roster, time, PTO, leave liability, labour cost to the GL
- Governance: by-laws as data, committees, meetings, motions
Around it
- Staff back-office web application — one app, every department
- The member's own half: home screen, account, bookings, consent
- Chart of accounts import — stage, validate, commit; account numbers preserved as permanent aliases
- Member import from the club's existing system
- QuickBooks Online journal export, with an outbox, idempotency keys, leasing and backoff
- Multi-tenant with forced row-level security and composite foreign keys
- Dedicated single-tenant deployment, from the same image and configuration
- A permissions map generated from the code, and a build that fails on an unguarded route
- Departmental authority — a manager of something in particular
- Four background workers, each its own service with a heartbeat
- A published OpenAPI description of the financial backbone; the rest of the API is documented by its generated permissions map rather than by a schema
Half-built, and which half
These exist and are incomplete. The point of listing them separately is that a club evaluating us should know which half it is getting.
Member self-service ordering
An attendant can ring a poolside or cart order and close it to an account today. A member cannot place one from a lounger or a hole — no location targeting, no runner workflow, no offline queue for a cart with no signal.
Facilities ticket queue
A real queue with priority, assignment and a done state, reaching irrigation, equipment and the clubhouse. It lives under grounds, so it is the superintendent's queue rather than the club's.
Document and file storage
The object store is built and speaks S3, R2 or MinIO; member photographs already use it. Meeting documents and uploaded minutes wait on one bucket and one credential.
Daily overtime
The federal forty-hour rule is computed. California, Alaska, Nevada and Colorado daily overtime is not, and the report says so rather than under-reporting quietly. Salaried non-exempt overtime is counted and deliberately not priced.
Stocktakes in the pro shop
Counting, posting and shrink all work and are tested. There is no counting screen, so a physical count in the shop is a script today. The kitchen got its screen first.
Minimum spend, member-facing
The F&B minimum is billed, credited and forfeited correctly. No screen shows a member how they are tracking against it before the quarter ends.
Written down in enough detail to build
In the order we intend to build them, which is a sequence claim rather than a delivery date.
1 Notification delivery
- A carrier — email and SMS
- Templates and translation
- Delivery receipts, bounce and STOP handling
- A member's inbox inside the app
- Self-service password reset, which depends on the same channel
First because it is the most consequential thing on this page. The spine, consent, quiet hours and the outbox are all built; the worker currently logs what it would send and leaves the row queued, because it will not let a fake provider record a delivery that did not happen.
2 Card tender and the kitchen
- Card tender on the processor’s own hardware, tap-to-pay on low-volume surfaces — and choosing the processor, which is still open
- Kitchen and expediter display — prep station already routes as data
- Service charge and tip as separate line types, with a screen that sets them
- Offline capture and replay on the beverage cart
- Inter-outlet stock transfers
3 Member-facing surfaces
- Shareable menus — what is on tonight
- Ordering from a lounger or a hole number
- Minimum spend progress
- Member-managed family charging permissions
Each of these sits on data that already exists. They are screens, not systems.
On the map, and deliberately shown lighter
Named and scoped at a high level. If your club needs one of these this season, that is a reason not to buy from us this season.
Events business
- Weddings and events portal
- External guest and vendor access layer, which it depends on
- Catering, guest lists, vendor coordination
Departments not covered
- Fitness and personal training
- Junior camps outside the pool and the range
- Valet, shoe shining, locker supply
- Fuel dock, launch service, winter haul-out
- Shooting scores, classes and registered shoots
Operations
- Equipment and vehicle maintenance logs
- Preventive maintenance by asset
- A club-wide facilities desk
- Budgeting and forecasting
- Fixed assets and depreciation
Governance & member voice
- Suggestions routed to a committee
- A private complaints channel to the GM
- Membership referrals
- A newsletter composer
- Minutes version history
Integrations & markets
- Reciprocal club access
- Payroll — integrates out, never built in
- Toast and Lightspeed adapters
- QuickBooks Desktop
- E-invoicing transport and fiscalization devices
- EU data residency
The blocker changed. It is still a blocker.
Predictive staffing, predictive food ordering, facility utilisation and member preference intelligence are the payoff for running the whole club on one system. A year ago they were blocked because the modules that feed them did not exist.
They exist now. Orders down to the modifier, bookings across six departments, shifts and worked hours, conditions and a season of weather observations. Predictive staffing is already half-answered by rules rather than a model — thresholds a club edits, priced against the roster — which at least makes "would a model beat this" an answerable question.
What is missing is a season of a real club running on it. So the sequence is unchanged: run the modules in real clubs, then build the models on what they produce. Anything else is a demo trained on nothing, and a board can tell the difference.
You will not find the phrase on our homepage until it is true.
Pick the module you think we are bluffing on.
That is a more useful forty minutes than a slide deck, and it is the one we would rather have. If the gap that matters to your club is on this page rather than the one above it, we would rather you knew before the call than after it.