El Lobo Labs
One platform. Every club its own way.
No two clubs are alike, and almost all of them end up on the same generic system anyway — or on one built for them that nobody else maintains. Lobo One is a single platform each club configures, with no separate version per customer.
No self-service sign-up and no trial: the demonstration is led by somebody from El Lobo Labs.
A club is many things at once
A member at the gate, a court taken, a class full, the restaurant busy, a boat going out. Underneath all of it there is one platform — and each club switches on what it actually uses.
- Members and households
- Belonging to the club
- Bookings
- Bookable services
- Resources
- Classes
- Competitions
- Catalogue and pricing
- Benefits
- Orders
- Billing
- Payments
- Ledger
- Payouts
- Partner contracts
- Hospitality
- Bars and restaurants
- Golf
- Marina
- Audit trail
Every piece above is a real module. A club without a marina does not see a marina.
Five decisions the product rests on
Each one is checked in code rather than promised.
Configuration, never a version of your own
Every difference between clubs is data: a category, a price rule, a field. There is no line of code anywhere that asks which customer is using the system — and an architecture test fails the build if somebody writes one.
tooling/architecture-guard — no runtime source branches on a customerOne club’s data cannot reach another
The isolation is the database’s, not the application’s. Every table carries a policy PostgreSQL enforces — on the table’s own owner too — so a mistake in the application does not become a leak between clubs.
PostgreSQL row level security, forced on every table, proved per contextEvery decision explains itself
A price arrives with the rules that applied and the ones that did not. A refusal says which benefit ran out and when. Somebody at a desk has to answer a member, and "not entitled" is not an answer.
every price and every entitlement decision carries the rules it appliedA lesson books the coach and the court, or neither
Booking something that occupies more than one resource happens in one transaction. There is no outcome where the coach is held and the court is not — proved with two genuinely concurrent bookings rather than asserted in a comment.
@lobo-one/module-services — one transaction, proved under a real raceEach club switches on what it bought
Hospitality, food and beverage, golf, marina: a club without a marina does not see one. Not a hidden screen — the API answers that it does not exist, because for that club it does not.
@lobo-one/module-registry — a club switches on what it bought
Where people use it
Each audience has its own. The ones still being built are labelled.
Club administration
Where a club runs itself: members, services, resources, the diary and the catalogue.
Available
Platform console
El Lobo Labs’ own tool for creating clubs, switching modules on and investigating problems.
Available
Group console
For whoever operates several clubs under one contract.
Available
Partner portal
For the provider that serves the club: contracts, services and settlements.
Available
Member app
Book, see your benefits, and pay.
Available
Staff app
Who arrived, what is scheduled, what to do.
Available
Point of sale
Selling at the desk, the court and the restaurant.
Available
From a first conversation to a running club
There is no self-service sign-up and no trial handed out on the spot. Four steps, and every one of them goes through a conversation.
A conversation
You describe how the club works today: what counts as a booking, what is a subscription and what is a sale at the counter.
The club is created
El Lobo Labs creates the club on the platform and switches on the modules it uses.
The configuration is yours
Categories, prices, resources, benefits and appearance: all of it data, not code.
The first booking
When the first real booking happens, the operation has started.
The platform is an API before it is a screen
Every screen in this product talks to the same public API, with the same scopes and the same isolation rules. Nothing is reserved for our own surfaces.
A versioned REST API
A published contract, problem-details errors and stable pagination.
A TypeScript SDK
A typed client, generated from the same contract the API serves.
Signed webhooks
Signed events, with retries and no silent double delivery.
What people ask us
Do you have clubs using it?
Not yet. Lobo One is in validation with its first clubs, and this site does not invent a success story that does not exist.
What does it cost?
There is no published price list. The commercial shape is being worked out with the first clubs, and we would rather say so than publish a number that would change next month.
Is my club's data kept alongside another club's?
In the same database and never within the same reach: every table carries a policy that PostgreSQL itself enforces, including against the owner of the table.
Do I have to use all of it?
No. A club switches on what it uses, and what is off does not appear — the API answers that it does not exist, because for that club it does not.
Can I bring the data I already have?
Yes, and it is part of the conversation: member records, categories and history come in by import rather than by typing.
Which languages?
Portuguese, English and Spanish, on the screens and in the emails. The club picks the default and each person can change their own.
Want to see it working?
The demonstration runs in the development environment, with sample data, led by somebody from El Lobo Labs.