Every department of the club, in one system.
Back office and ERP, personnel and labour, food and beverage, golf and course management, the pro shop, racquets, aquatics, shooting, the marina, operations, governance — and the app in the member's pocket. Most of it is built and running against a real database today. The parts that are not are named on this page, in the row where you would look for them. Every module says what it posts to the ledger, because that is what makes it one system rather than nine.
Live means a club could use it today: there is a table, a route and a screen, and an automated test that tries to break it. It is the same bar the engineering module map uses, and the two documents are kept in step deliberately.
Financial backbone
Built first on purpose, and the place every other module on this page terminates. 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 |
| Dues monthly or once a year, the member's choice | Live | Twelve monthly charges collect exactly the annual figure, to the cent |
| 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 |
| One household, one statement | Live | Dependants and a spouse consolidate onto the account that is actually billed |
| 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 |
| Membership ceasing — resignation, forfeiture, reinstatement | Live | And a report of who is on the edge of it, before the letter goes out |
| 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 |
| Assessments, member vote thresholds, payment plans | Live | A board votes it and the whole receivable exists from that moment |
| Departmental P&L | Live | Separated from the first entry, not allocated backwards at year end |
| Accounts payable — vendors, coding, approval rules, payment runs | Live | Dated approval thresholds; the person who entered an invoice can never approve it, and that part is not configurable |
| Purchase orders, receiving and three-way match | Live | An invoice beyond the order's tolerance is held with the reason attached, and goods received not invoiced is a report rather than a surprise |
| Banking — accounts, deposits, reconciliation, statement import | Live | Reconciliation refuses to complete out of balance and says by how much |
| Cost of goods sold, weighted average, posted per ticket | Live | Retail and kitchen both. Margin is readable inside the month rather than at year end |
| Labour cost posted into the ledger per department | Live | Approved hours against the rate, as an accrual. The largest line in a club's P&L, weekly rather than a month late |
| Pluggable ledger — native or QuickBooks Online | Live | Per-club setting, invisible to every module. Sync cadence is a pricing lever |
| Nightly run — dues, late fees, statements, dunning | Live | Per club, in the club's own timezone, as its own service with a heartbeat |
| Multi-currency representation, 17 countries pre-registered | Partial | The engine, effective-dated rates, gapless document numbering and hash-chained fiscal receipts are all live. Only the US country pack ships — tax codes, rates and a statutory chart. Adding a market is one SQL file and no schema change, but it is a file that has not been written |
| Multi-tenant, plus dedicated single-tenant deployment | Live | Same artifact, different configuration |
| Staff back-office web application | Live | What a controller actually opens. Fifty-two screens across every department on this page |
| Budgeting and forecasting | Not built | No table, no screen. A club that budgets in a spreadsheet will keep budgeting in a spreadsheet for now |
| Fixed assets and depreciation | Not built | Posted by journal entry today |
Still not in scope, and we would rather say so here. QuickBooks Desktop. The OAuth2 connection flow itself. Daily-summary roll-up to QuickBooks — the worker sends per entry. Budgeting. Fixed assets and depreciation. Payroll processing, withholding and filing. Multi-currency settlement and FX revaluation. E-invoicing transport — Peppol, SdI, KSeF, ZATCA. Certified fiscalization devices. And the predictive layer, which is gated on operating data.
Ordering & point-of-sale
Two real point-of-sale systems, both posting through the same door as everything else: a pro shop till with inventory and costing behind it, and an F&B terminal with open checks. The strategy held — build the ordering, rent the payments.
The pro shop till
Live- Catalogue with size and colour variants, SKU and barcode
- Tickets, tenders, discounts, voids, returns, a day's Z-read
- House account, cash, cheque or card — a card row holds processor, reference, brand and last four, and there is no column a card number would fit in
- Stock on hand per outlet, an append-only move ledger, reorder points
- Cost of goods sold at weighted average, posted per ticket
The gap: stocktakes and shrink work through the API and have no counting screen yet, so a physical count in the shop is a script rather than a tablet. The kitchen got its screen first.
The F&B terminal
Live- Open a tab, seats, ring items with modifiers, send to the kitchen
- Close a check to an account, including split by seat — a table of four becomes four charges
- Comps and voids with a reason and an authorising person
- Menus with effective-dated prices per outlet, and eighty-sixing in one tap
- A price change that refuses to backdate, and leaves a rise already booked for next month alone
The gap: service charge is frozen at open and reaches the statement, but no screen sets it, and there is no member-entered tip.
Card tender & the kitchen
Specified- Card tender on the processor’s own terminal hardware, so the PCI scope is theirs; tap-to-pay on low-volume surfaces. No processor is chosen yet, and the gateway sits behind an interface until one is
- Kitchen and expediter display — prep station routes as data, and "send" stamps a time nothing shows a cook
- Offline capture and replay on the beverage cart — the hardest part, and flagged as such
- Inter-outlet stock transfers — the move ledger has the reasons and nothing uses them
"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 — including the compliance-sensitive half that most club software leaves to a clipboard.
- Tee sheet and bookingWith holds, and a rule for when two people want the same eight o'clock
- Rate cardMember, guest, outside, season, holiday and exceptions
- Guest playA guest without a sponsor is refused, not posted to whoever was nearest
- Handicaps and GHIN numbersAnd a GHIN number that survives a hyphen
- Digital scorecard and round historyHole by hole
- The card goes round with the memberOn a phone, one hole at a time, marking the whole fourball. The member's own write, not the shop's
- Carts, lessons and professionalsWith the charges that follow them
- Practice facilityRange and short game
- Pin positions and daily course setupWhere the hole is cut today
- Course conditions and a maintenance task queuePriority, assignment and a done state
- Chemical and fertiliser application trackingOne tank, one record — the products, the rate, every green it covered, the wind and the certified applicator. Nothing can be edited or deleted. Pounds of nitrogen per thousand square feet, per year, comes out as arithmetic rather than a guess
- Frost and rain delays the software proposes and the shop decidesThresholds are rows the club edits, and the proposal is advisory, because the professional walks the course and the software does not
- Course closure and lightning evacuationRaised by the detector, and it closes the pool in the same breath
- Events, entries, pairings and a waiting listIncluding the shotgun draw
- Competitions, leaderboards, countback and a season of standingsA scratch prize is not settled on net
- QR check-inPlace-coded stickers that resolve to a scorecard
Not built: reciprocal club access. Guest play is built and reciprocity with other clubs is not — it is a different problem, because the other club's system has to agree to something.
Racquets, water and the rest of the sport
Golf is rarely the whole club, and at a growing number of clubs it is not even the busiest department. Each of these is its own module with its own rate card, its own revenue account and its own screen — not a tee sheet with the labels changed.
Racquets
Live- Courts, surfaces, lights and seasons
- The court sheet and reservations
- Who may book and when — privileges, guests, overlap rules
- Professionals, lessons and the ball machine
- Players on a reservation, and the charges that follow
Aquatics
Live- The water, its areas, seasons, holidays and the week's hours
- The deck sheet, lane reservations, category privileges
- The gate — waiver, guest sponsor, guest fee to the member's account
- Lifeguards: certificates, posts and coverage
- Swim lessons and the swim school, with a waitlist
- A member books a lane and signs the waiver from their own phone
Shooting sports
Live- The sports a club runs, the ground, the season and the hours
- A versioned waiver and an age gate — nobody shoots who has not signed
- The sign-up sheet and the squad
- Clays, ammunition and the rate card
- Club guns, eyes and ears, on loan
- Blocking the tee sheet, because the skeet house is on the seventh
Scores, classes and registered shoots are not built.
Marina
Live- Docks, slips, boats, the fit rule and billable feet
- Leases, occupancies, absences and availability
- The waiting list, offers and the renewal run
- The transient log and the dock sheet
- The rental fleet, endorsements, checkout and return
- Crew, credentials, instruction and regattas
The fuel dock, the launch schedule and winter haul-out work orders are not built.
Fitness and personal training are not built. Class booking, personal-training scheduling and junior camps outside the pool and the range have no table and no screen. A club whose fitness floor is its busiest department should know that before the call.
Food & beverage
Not a menu screen on top of a till. The kitchen's own inventory, its recipes, what a plate costs, and the one number a food and beverage director actually manages — what the recipes say the kitchen used against what the shelf says it lost.
| Feature | Status | Notes |
|---|---|---|
| Menus, items, modifiers, effective-dated prices per outlet | Live | With a screen that leads on whether an item can actually be sold, because an item with no price cannot be rung |
| Kitchen inventory — units, ingredients, storerooms, receiving, waste, transfers | Live | An append-only stock ledger and a physical count screen |
| Unit conversion, and the refusal that matters | Live | Converts freely within a dimension and refuses across one. Eight ounces out of a shelf held in fluid ounces is a question with no answer |
| Recipes and what a plate costs | Live | A prep is an ingredient, so the demi-glace in a sauce costs what the demi-glace on the shelf cost. Nothing recurses |
| Cost of food and beverage sold | Live | Compute a draft, look at it, post it, reverse it with a reason. Posted per department |
| A dish with no recipe | Live | Counted, never priced at zero. The coverage line sits above the food cost figure, and the caveat is written into the journal entry's own memo |
| Theoretical against actual usage variance | Live | Per ingredient, over a run's span. The reason the physical count was built before the recipes |
| Comps deplete, voids do not | Live | The plate was cooked either way, so the food cost is real even though the revenue is not |
| Poolside, cart and halfway-house ordering — staff-taken | Live | Those outlets are seeded and the terminal opens tabs at them |
| Poolside, cart and halfway-house ordering — member self-service | Partial | An attendant can ring an order and close it to an account. A member cannot order from a lounger or a hole yet — no lounger targeting, no runner workflow, no offline queue for a cart with no signal |
| Minimum spend progress shown to the member | Partial | The minimum is billed and forfeited correctly. No F&B screen shows a member how they are tracking against it |
| Shareable menus — a member-facing "what's on tonight" | Not built | The data is there, including serving hours, and a club can now write a menu worth showing |
| Weddings and events portal | Not built | Needs an external guest and vendor access layer, which is the piece that makes it a larger job than it looks |
| Food and social direction voting | Not built | — |
| Valet, shoe shining, locker supply reorder | Not built | The outlets exist; nothing a member or an attendant would touch |
Operations & back office
- ProcurementPurchase orders, receiving, and a three-way match that holds an invoice outside tolerance with the reason attached
- Goods received not invoicedA report, so the liability only goes up when something actually arrived
- InventoryRetail and kitchen, each with its own move ledger, stocktakes and weighted-average cost
- Grounds and turfMaintenance scheduling by area, condition reporting, and chemical application tracking — the compliance-sensitive half, built
- Door and gate access credentialsCodes hashed, shown once, never stored readable
- Devices and non-person API callersA caller that is not a person still has to say who it is
- Background worker livenessFour workers, each its own service, each with a heartbeat — and a readiness endpoint that says beating, late or silent
- Weather, and what the club did about itObservations, and the decision they produced, kept together
Facilities ticket queue
PartialThe maintenance queue is real — priority, assignment, a done state — and its element list already reaches irrigation, equipment and the clubhouse. But it lives under grounds rather than as a club-wide facilities desk, so a broken dishwasher goes in the superintendent's queue.
Equipment and vehicle records
Not builtTwo tables have misleading names: one holds a member's car for the valet and the gate, the other holds loaned shotguns. There is no maintenance log for club machinery, and no preventive schedule by asset.
Document and file storage
PartialThe object store is built and speaks S3, R2 or MinIO. Its only consumer today is member photographs. Meeting documents and uploaded minutes are waiting on one bucket and one credential — decided, not provisioned.
Everything in this module posts expense and inventory movement by department, into the same departmental P&L the controller already reads.
Personnel & labour
Labour is the largest line in a club's P&L and usually the last one to arrive. It posts here weekly, per department, from approved hours rather than from an estimate.
- Staff recordsPerson, department, job title, dates, employment type and reporting line
- Pay rates, effective-dated, behind an audited doorController-only and logged. The amount is unreadable by the application role — the same treatment as a bank account number
- SchedulingPatterns for the ordinary week, generated onto dates, draft and published, open shifts and coverage
- Time trackingClock in and out, breaks, approval, and the variance against the roster
- Labour cost into the ledgerApproved hours against the rate, rounded once, split at forty, posted per department as an accrual
- PTO and leaveKinds, accrual policy, requests, approval and balances — an append-only ledger with no cached balance anywhere, because "I had four days left" is an argument
- Leave liability on the balance sheetWhat the unused days are actually worth, valued per employee
- A rostered shift on an approved leave dayShown above the approval queue rather than refused, because the roster and the leave were written by two different people weeks apart
- Weather to staffing to dollarsThe frost proposal joined to the roster and the rates, so a held day has a number on it. Advisory — nothing cancels a shift on its own
- Headcount, tenure and leavers by department
Daily overtime
PartialThe federal forty-hour rule is computed. Daily overtime — California, Alaska, Nevada, Colorado — is not, and the report says so rather than under-reporting quietly.
Salaried non-exempt overtime
PartialCounted and reported, deliberately not priced. The regular rate depends on which method the club's payroll processor uses, and guessing costs real money.
Payroll
Not builtScheduling and labour cost are built natively. Withholding, filing and deposit integrate out to Gusto, ADP or Paychex. We do not process payroll, do not withhold tax, and do not file it — and that is a decision, not a gap.
Governance & communication
A member-owned institution runs on its by-laws, and most club software treats them as a PDF in a shared drive. Here they are data the system can cite and, where the club wants it, enforce.
- By-laws as structured textArticles, sections, nested citation, per club — with import, export, and references that re-point across versions
- Rules as dataThe club's own policy values, enforced by the system rather than remembered by staff
- Rules shown but not enforcedA by-law surfaced at the moment it applies. The build fails if a surface a club can choose is rendered nowhere
- Board, committees the club creates itself, positions and terms
- MeetingsOne-off or a recurring series with a date override, and invitees that can be a body, staff, the whole club, a member or a vendor
- Motions and board approvalThresholds per club — a two-thirds club is not offered a simple majority
- Assessments requiring a member voteAbove the club's own threshold it is the members' decision, and the system treats it that way
- Minutes typed into the appEdits overwrite; there is no version history yet
- The notification spineKinds, club policy, quiet hours, per-person consent, and an outbox
- What a member may turn off, and what they may notA topic by channel grid, with the reason as data. Nobody can switch off an emergency
The honest gap, and it is the important one on this page. Nothing is actually delivered yet. The notification spine is built — kinds, consent, quiet hours, an outbox, and a worker — and no carrier is connected, so the worker logs what it would send and leaves the row queued rather than marking it sent. It will not let a fake provider record a delivery that did not happen. Templates, translation, delivery receipts, bounce and STOP handling all wait on the same decision. A member's inbox inside the app is read by an endpoint that no screen calls yet.
Not built: improvements and suggestions routed to a committee; a private complaints channel to the GM with a resolution trail; membership referrals; a newsletter composer. Meeting documents and uploaded minutes are blocked on the object storage bucket above, and Zoom or Teams links are pasted by hand today, shaped so an integration can fill them later.
The member's own half
The reason everything above exists. Half of this platform is a back office a member never sees; the other half is the club in their pocket, under the club's own name. What a member does with it
- A member home screenOne question — what does my week look like — answered from every booking in the club, not one department's
- A member's own accountBalance, statements, payment methods and what the club may send them
- The scorecard on their phoneOne hole at a time, marking the whole fourball
- Booking a lane and signing the waiverWithout finding anyone at the desk
- Contact preferencesA topic by channel grid they control, except the things nobody may switch off
- The member's nav is only the member'sNo link into a screen that would refuse them
- Members, memberships, categories and category history
- Family and dependent sub-accountsA spouse who may charge but is not billed, enforced at the moment a charge is rung along with account status and the credit limit. Per-transaction caps and per-outlet restrictions are stored and editable and not yet enforced — a dependent's cap is a note today, not a refusal. Member-managed permissions are still to come
- People, preferences, photographs, contacts and consentThe browser crops and resizes before upload, so a phone photograph does not arrive at eight megabytes
- Prospective membersApplication, proposer and seconder, the noticeboard period, and the board motion that admits them
- What the club knows about a memberOccupation, employer, school, interests — club-owned fields, so a club that wants "Boat" and "Sail number" adds them without a deploy
- Finding somebody at the deskPreferred name, spouse, dependent, membership number, account number, email, phone, surname-first
- Member import from the club's existing system
- Birthdays for the newsletterConsent-first, and the list returns month and day with no argument that would add a year
Platform & tenancy
- Row-level security on every tenant table, forcedA new table with a club identifier gets tenancy automatically, rather than by somebody remembering
- Every route says who may call itThe permissions map is generated from the code, and the generator refuses to write a map for a codebase with an unguarded route — so a missing guard stops the build
- A manager of something in particularMaking the tennis professional a manager no longer hands them Finance, Banking and every department's labour cost
- Platform operator, audit log, who really did that
- Sample data — a club you can show someone, and take back outThe same club twice, deterministically
- Giving a member a login, and resetting oneA one-time code, shown once. Self-service password reset is not built, because there is no email channel to send one through
- Whether the system is up, said on the sign-in pageSo a member can tell a wrong password from a broken server
- One command that says whether the tree is safe to hand overTwenty-two checks, including the SQL and API suites
The predictive layer
This is the payoff for running the club on one platform rather than four. The tee sheet, the courts, the lanes, the range, the kitchen, the roster, the grounds schedule and the ledger are now the same system — which means the data these need is finally being generated. It has not been generated for a season yet, and that is the only thing standing between here and there.
Predictive staffing
Rules, no modelThe honest status, and the most advanced of the four. The frost and rain rules already propose a delay, and the roster and the rates already price what a held day costs. It is arithmetic on thresholds a club edits, not a forecast. Whether a model would beat the rules is now an answerable question rather than a claim.
Predictive food ordering
Not startedUnblocked. Order data exists now, down to the modifier, and so do recipes, plate costs and a usage variance. What is missing is any analysis of it — forecast covers by outlet and daypart, turned into prep lists and purchase orders.
Facility utilisation
Not startedUnblocked. Tee sheet, court sheet, deck sheet, range sheet, dock sheet, bookings, scores and a season of weather beside them. Wants a season of data more than it wants a technique.
Member preference intelligence
Not startedObserved preferences from charge and booking history, surfaced to the right staff member at the right moment — so a seasonal hire in week two looks like a twenty-year veteran.
A model trained on nothing is a demo, and a board can tell the difference. We will build these on a club's worth of real operating history and not before — which is also why the word "AI" does not appear on the front of this site.
Push on the parts that are finished.
Most of this page is one of them. Bring your controller and your golf professional, and pick the module you think we are bluffing on.