Every department of the club, in one system.
Back office and ERP, food and beverage, golf and course management, the pro shop, racquets and aquatics, personnel, operations, governance and the member app. Group one ships today; the rest is in build, designed, or on the map — and it is labelled that way here so you do not find out on the call. Every module says what it posts to the ledger, because that is what makes it one system rather than nine.
Financial backbone
The only group that ships today, and the one everything else terminates in. The full ledger story
| Feature | Status | Notes |
|---|---|---|
| Double-entry general ledger, append-only | Live | Enforced by database constraints and triggers, not application code |
| Club chart of accounts, with import and export | Live | From Jonas, Clubessential, Northstar, QuickBooks or a spreadsheet. Account numbers survive as permanent aliases |
| Accounts receivable and member accounts | Live | People, memberships and billing accounts are modelled separately, because they genuinely are |
| One-door idempotent charge intake | Live | Every module posts here; a new outlet is one configuration row |
| Recurring dues billing, prorated by days served | Live | Preview then commit. Every membership appears in the run, including the ones not billed and why |
| Prepaid dues deferred and earned monthly | Live | Same engine as initiation fees, gift certificates and capital assessments |
| Itemised member statements and history | Live | Verified figure by figure against a real club's printed statement |
| Payments — record, then settle, FIFO allocation | Live | Overpayment shows as unapplied cash, not as an error |
| Credit memos, write-offs, transfers | Live | Each posts differently, on purpose |
| Merchant fees as a club expense | Live | The member's balance falls by exactly what they paid |
| Autopay with a retry policy | Live | Gateway behind an interface; the manual gateway is the default for clubs taking cheques |
| Aging, late fees, dunning ladder | Live | One rung per run; paying in full reinstates in the same transaction |
| F&B minimums with configurable qualifying spend and forfeiture | Live | The club-specific mechanic no general accounting system models |
| Initiation fees — equity, deferred revenue, or split | Live | Set per membership category, not per club |
| Departmental P&L | Live | Separated from the first entry, not allocated backwards at year end |
| Accounts payable | Live — stub | Phase one scope only. The full approval workflow is not built |
| Pluggable ledger — native or QuickBooks Online | Live | Per-club setting, invisible to every module. Sync cadence is a pricing lever |
| Multi-currency representation, 17-country tax engine | Live | Effective-dated rates, gapless document numbering, hash-chained fiscal receipts |
| Multi-tenant, plus dedicated single-tenant deployment | Live | Same artifact, different configuration |
| Staff back-office web application | Live | What a controller actually opens |
Not in phase one — and we would rather say so here. QuickBooks Desktop. The OAuth2 connection flow itself. Daily-summary roll-up to QuickBooks. Inventory valuation and COGS. The full AP approval workflow. Payroll processing. Fixed assets and depreciation. Budgeting. Multi-currency settlement and FX revaluation. E-invoicing transport — Peppol, SdI, KSeF, ZATCA. Certified fiscalization devices. And the predictive layer.
Ordering & point-of-sale
The strategy is decided — build the ordering, rent the payments. Phase A is order capture, and it ships before any card terminal exists, because a member ordering from a lounge chair does not need a terminal. It is also the most demonstrable thing in the suite.
Phase A — order capture
In build- Poolside ordering, location-aware, tab to account
- Course ordering — beverage cart and halfway house, delivered to a hole number
- Locker supply reorder
- Valet request and pull-up
- Shoe shine drop-off with a ready notification
Posts F&B, retail and service revenue by outlet, through the one door.
Phase B — the terminal
Specified- Staff terminal: item grid, tabs, seats, splits, transfers, voids, comps
- Card tender through Stripe Terminal; Tap to Pay on low-volume surfaces
- Kitchen and expediter display
- Service charge and tip as separate line types
- Offline capture and replay on the cart — the hardest part, and flagged as such
Phase C — retail
Specified- Pro shop: SKUs, size and colour matrices, inventory, receiving
- Member and guest price books
- Real-time charge authorisation against AR balance and credit hold
- Family and dependent charging permissions with per-outlet caps
"We love our Toast." Then keep it. The adapter seam is designed so a club can keep an existing point-of-sale and still land its revenue in this ledger. The interface exists; the adapter itself is deliberately unbuilt until a club needs it. We would rather tell you that than imply an integration that does not exist.
Golf & course management
Both halves of the golf operation — the member's side and the superintendent's. Tee times are the highest-priority unspecified item in the whole product, and they are next after order capture.
- Tee time bookingHighest priority of everything not yet specified
- Digital scorecard, handicap tracking, round history
- Course data — yardages, par, slope and rating, GPSEither licensed or digitised from the club's own scorecard
- QR check-in for events and play days
- Guest passes and reciprocal club accessPosts green fees and guest charges to the sponsoring member's account
- Tournament managementPairings, flights, live leaderboards
- Turf & course managementMaintenance scheduling by area, chemical and fertilizer application tracking, equipment logs, course condition reporting to members
The rest of the club's athletics
Golf is rarely the whole club, and at a growing number of clubs it is not even the busiest department. Racquets and aquatics run on the same primitives as the tee sheet — a bookable resource, a programme roster, an instructor's schedule and a charge — so they are built on the same booking engine rather than as separate products.
Racquets
- Court booking — tennis, paddle, pickleball, squash
- Ball machine, lights and court-time charges
- Clinics, leagues, ladders and round robins
- Professional lesson scheduling and lesson billing
Posts court fees, programme fees and lesson revenue by outlet.
Pool & aquatics
- Poolside ordering with chair or cabana location
- Cabana and lane reservations
- Swim lessons, swim team and guest passes
- Lifeguard scheduling into the same roster as everyone else
Poolside ordering is part of module two, phase A, and is in build now.
Fitness & programmes
- Class and personal-training booking
- Junior camps, clinics and holiday programmes
- Registration with per-programme capacity and waitlists
- Programme revenue and instructor cost in the same departmental P&L
These sit alongside golf in the module map rather than inside it, because a club whose racquets programme is bigger than its golf programme should not have to run it inside a tee sheet.
Food & beverage, and social
Shareable menus
A content layer that doubles as a marketing surface — the menu a club posts to its members is the same one it sends to a prospective wedding party.
Direction voting
Members vote on food and social direction, with an opt-out "surprise me" toggle for the members who would rather the chef simply decided.
Weddings & events portal
Booking, catering, guest list, vendor coordination and billing. Needs an external guest and vendor access layer, which is the piece that makes it a larger job than it looks. Posts event revenue and deposits.
Operations & back office
- ProcurementPurchase order creation, and receiving that matches the order against what actually arrived
- Inventory by departmentPro shop, F&B, grounds, locker room
- Grounds & turfMaintenance scheduling by area, and chemical application tracking — compliance-sensitive, and a real selling point to a superintendent
- Equipment maintenance logs
- Course condition reporting to membersThe greens are punched on Tuesday and every member knows before they book
- Facilities and maintenance ticket queue
Posts expense and inventory movement by department, into the same departmental P&L the controller already reads.
Personnel
- Staff schedulingBy department and by shift
- Time tracking, clock in and out
- Labor cost reporting into the general ledgerWhich is the point — labour is the largest line in a club's P&L and it usually arrives a month late
- PTO and leave tracking
- Basic HR recordsRoles, pay rates, department
- PayrollIntegrated out to Gusto, ADP or Paychex. We do not process payroll, do not withhold tax, and do not file it
Governance & communication
- CommitteesRosters, meetings, a minutes archive, and action tracking that survives a change of chair
- Member suggestionsRouted to the right committee, with a status the member can see
- ComplaintsA private channel to staff and the GM — deliberately not committee-visible — with a resolution trail
- Membership referralsA member-initiated vouch flow, which is how exclusivity is preserved rather than eroded
- Announcements and push notificationsClosures, events, news
Member account structure
Family and dependent sub-accounts with shared or separate billing permissions — a spouse who may charge but is not billed, a nineteen-year-old with a fifty-dollar cap at the halfway house and no bar privileges at all.
The schema support for this is live today: the person-to-membership relationship, the may-charge flag, per-transaction limits and allowed outlets are all in the database and enforced. What is planned is the member-facing management of it — today those permissions are set by staff in the back office.
The predictive layer
This is the payoff for running the club on one platform rather than four. When the tee sheet, the courts, the kitchen, the roster, the grounds schedule and the ledger are the same system, the club can stop reporting on last month and start anticipating next weekend.
Predictive staffing
Weather, the tee sheet, court and lane bookings, the event calendar and last year's covers, read against the roster. Two more servers on Saturday, one fewer at the turn, decided on Wednesday. Needs modules three, five and six.
Predictive food ordering
Forecast covers by outlet and daypart, turned into prep lists and purchase orders. Needs order history from module two and procurement from module five.
Facility utilisation
Where the course, the courts, the lanes and the dining room are genuinely at capacity and where they only feel it — the question behind every capital decision a board makes. Needs booking data from module three.
Member preference intelligence
Observed preferences from charge and booking history, surfaced to the right staff member at the right moment. Needs a season of module two and three data.
Every one of these is fed by operating data the platform has not generated yet, and we are not going to pretend otherwise. A model trained on nothing is a demo. We will build these when there is a club's worth of real operating history to train them on, and not before — which is also why "AI" does not appear on the front of this site.
See the part that is finished.
The backbone is real, tested and running. Come and push on it.