Under the hood

Technology connecting surf with operations.

Bookings, team and sea conditions connected by operational rules. Explore available journeys and what we are still developing.

Discover SurfBooking OS See the four chapters

SurfBooking OS

SurfBooking brings surf schools, surfers and instructors together in one place. Schools use the SurfBooking OS for free, at €0/month; surfers find lessons and see the sea at each beach for their level; instructors have a CV they take from school to school and see their schedule. The assistant is called Kai.

One request, live

You say what you want. The rules decide. You confirm.

Kai understands the request, the system checks the school's rules, and the lesson only changes after you confirm. At the end it reads back what was saved before telling you it is done.

Illustrative example of a request.

Several requests in one sentence

One sentence, several steps. Each goes to what knows it best.

When you ask for several things at once, the system splits them into steps and hands each to the part that knows it: the calendar, the sea, the school's rules, the instructors or the equipment. You see the list and what was done in each step, and anything that changes data waits for your yes.

Illustrative example of a request.

How decisions are made

Not everything needs a language model.

Before any model comes in, the question goes through our own logic, written and tested. If it knows the answer, it answers right away. If it does not, it does not guess: it passes the turn.

This split is the same idea technical literature calls “System 1 and System 2”: the fast reflex and the slow deliberation. At Surf Booking the reflex is our own code, not a model: the arithmetic, availability, scheduling conflicts, ratios and permissions are decided by verifiable rules, and no model replaces them.

Why this way

An assistant with no rules gets it wrong with confidence. A fixed workflow does not adapt.

We combined the two. The assistant understands what you ask, but anything touching money, places and students per instructor is decided by written rules, and nothing changes without a person confirming.

Illustrative example. The first two columns describe ways of building an assistant, not specific products.

All connected

You change a lesson. The system rechecks what that change touches.

Students, instructor, gear, sea, payment and sales channels live in the same system. The result is only announced once it is confirmed.

The sea, beach by beach

The same sea offshore. Three beaches, three readings.

The swell reaches each beach differently. Each one is read with its own exposure and tide, and the score comes out per beach and per lesson level.

Example heights.

SurfBooking
Each school in its own space

One school's data does not cross to the next.

Students, bookings and conversations stay inside the school they belong to. A request that tries to leave is stopped at the wall, whether it comes from a person or an assistant.

The house rules

The same rules for every assistant.

They are fixed on our side and no conversation changes them. Before each release we run attacks against them, and one failed rule stops the release.

The attacks we run are the ones we know: passing them does not prove there is no attack we have not written yet. Meet Kai →

Improves by measurement

A failure becomes a test. An improvement only goes in once measured.

Nothing changes on a hunch. The improvement has to win a test, a person on our team decides to apply it, and it is removed if schools show it got worse.

Three real cases
The late-afternoon lessonWent inThe assistant never suggested the 7 pm lesson, when in summer there is still daylight. It became a test and the hours were extended.
A wrong answer about itselfWent inThe public assistant answered wrongly when asked who made it, and insisted. The question now runs in the tests before each release.
A change to the dashboardWithdrawnIt solved one problem and broke 25 tests elsewhere. It came out the same night and returned days later, done differently.
0
Other-school reads stopped (90 days)
It counts what the wall blocked; it is not a security grade. Zero means nothing hit it in this period — it does not prove there are no flaws, nor that anyone tried.
93
Attack rehearsals before every release
35,000+
Tests before every release
189
Conversation trials launched (7 days)
6
Difficult profiles rehearsed
Each one's rules run before every release; the full conversations are launched separately.
All in one system

What holds your operation up.

Calendar, bookings, staff, equipment and sea conditions wired into the same system. When you change a lesson, the permissions, the timetable and the validations of that operation all come into play.

SurfBooking OS
An operating system for the schoolThe panel opens like a desk: each tool in its own window, the day at a glance and a bar where you type what you want. It stays the way you left it. An assistant in writing and by voiceYou ask in your language. Anything that changes how the school runs only happens after you confirm. Lesson video reviewYou mark each wave on the timeline and add notes and drills. The automatic suggestions appear on their own, and the coach is the one who confirms them. Direct sales and external calendarsThe school sells on its own channel and links the calendars of the platforms it is already on, so the same place is not sold twice. Each person signs in with their roleOwner, staff and instructor each have their own way in. The instructor sees their own lessons, and only theirs.
In six languagesThe site and the school's panel are in Portuguese, English, Spanish, French, German and Italian.
Underneath

The techniques at work for your school.

You do not need to know them to use the system. They are named here, each with what it gives you.

Rule-based decisions
Sums, places, timetable clashes and ratios are decided by written, tested rules. No language model replaces them.
Decision record
Every decision the assistant makes is recorded. When it creates a lesson, the system reads back what was saved and adds the result to the record. That is how we measure where to improve.
Per-beach forecast model
It gives each beach its score, per lesson level, and the confidence hour by hour.
Chained record
For refunds and payments to schools, each line of the record is linked to the one before. A change made afterwards shows.
Computer vision
In video review, surfer and posture detection runs in your browser. When the surfer is lost, a separate image model helps find them, without keeping the frame. The coach confirms what stays.
Where your data lives
The server and the database are in the European Union. In front of them sits a protection layer run by a different operator, separate from the server, which filters traffic before it gets there.
See more detail
The rules of each lesson
Refunds by how early the cancellation comes, no-shows, reschedules that cannot get around the refund policy, sea-condition cancellations with automatic refunds, and split groups without double charging.
Record of payments and refunds
Every payment goes into a record that is never rewritten, and the numbers are reconciled every day. Backups are encrypted and kept in more than one place, away from the database.
External calendars
External calendars are read carefully: a strange or empty file does not wipe your bookings, and a cancellation also reaches the channel the booking came from.
SB ratios and beach notices
SB ratios of students per instructor (1:6 beginner, 1:8 intermediate, 1:4 kids, 1:4 private), with a warning when the lesson goes over the ratio, age confirmed in kids lessons, a price that looks like a mistake is refused, and a beach-notice warning when two or more instructors share the lesson.
Privacy and our team's accounts
Anyone who asks to be deleted is deleted, and only what tax law requires us to keep stays. Photos go with the account. Every sensitive action by our team is recorded, and touching another team member's account requires a code sent by email.
At a glance

Two paths, each with a result you can confirm.

Surfer
  1. Finds a lesson in the app or on the site.
  2. Sees that lesson’s real availability.
  3. Books and pays.
  4. Gets the confirmation, by email and in the app.
Result: a confirmed booking, with the place held.
This path does not depend on Kai.
School
  1. You describe what you need in SurfBooking OS, typed or spoken.
  2. Kai interprets the request and prepares the action.
  3. It asks only for what is missing: a detail, or your confirmation.
  4. The server checks that you are allowed and that the lesson is still as it was, and only then carries it out.
  5. The OS shows the result the server confirmed. When it cannot confirm it, it tells you so and does not count it as done.
Result: what actually changed, shown on screen.
A reply from Kai does not prove something happened: the server does.

The SurfBooking team works in a separate area, apart from Kai and from the schools. When something fails, the failure becomes a test and an improvement, which only goes in after a person reviews it.

Different by design

This is not a feature.
It is how the house is made.

Many parts working together, each one dedicated to a piece of a surf school's day: sea conditions, ratios, liability waivers, payments, external calendars, partners. What matters is that they are connected. Each part alone is known; the way they line up with a school's day is not.

A booking platform with surf on top isn't this. A forecast app with bookings stapled on isn't this either.

Talk to the calendar. The calendar talks back.
Voice in several places: at the top of the calendar to change several lessons at once, on each lesson tile for a single adjustment, and in agent mode to navigate and fill in fields. No commands to memorise: you speak the way you speak at the school.
Voice · working today
The best window of the week
“Move to the best day this week”: the assistant looks at the next 7 days, picks the hour that best suits the lesson level and shows you the conditions before you confirm.
Several lessons at once
“Move all beginner lessons to next week”, “to next month”, “to the best day”. One sentence reschedules several lessons, with each one's conditions in view. If an instructor ends up with two lessons at the same time, you are told before anything changes.
Adjustments to a single lesson
The microphone on the lesson tile already knows which lesson you mean: “Instructor Pedro”, “Price 55€”, “6 students”, “Duplicate to Saturday at 10”. The instructor's first name is enough. The change is proposed and confirmed by you before it is applied, and what you see next is the result that stayed.
Never opens the agent silently
If it does not understand what you said, it shows you examples and you stay in the calendar. Agent mode only opens when you ask for it. It does not try to guess.
Understands spoken Portuguese
Speech recognition often hears “Móvel” instead of “Move-a”, or “Mac me” instead of “Marca-me”. We allow for that. It accepts “dia 24”, “next week”, “next month” and numbers in words (“cinco alunos”), because that is how people speak at a school.
The assistant knows your equipment
Ask “how many M wetsuits do I have?” and the assistant answers with the number in your stock, not an estimate. What is in maintenance shows separately.

The assistant does not stand still. It improves by measurement, not by guesswork.
Most AI features stay as they shipped. Ours keeps what it has learned, tries each improvement in a trial before using it, and shows our team where it is weak.
Tests before every version · a person decides
What is learned is kept
Every rule, every correction and every trial is kept with its date. Nothing starts from scratch each time, and the history can be consulted, including the corrections that were turned down.
Measured improvements
An improvement to the assistant's instructions only moves forward if it wins a measured trial, and it is withdrawn if real schools show it made things worse. Winning the trial applies nothing: applying is a decision by a person on our team. The rule tests run before every version.
A system that shows its weak points
Our team sees on a map where the system is failing: a trial the assistant lost, a proposal that protects no rule. Seeing our own weak points is part of the job.

The agent proposes. The rules decide. A person confirms.
The agent understands a request in plain language, but it is not the one that writes. Capacity, schedules, permissions and money are checked by our own code, on the server, the same way every time. The agent can get a conversation wrong; it cannot write against the rules.
When the agent writes
1 · The request
“move tomorrow's 9am lesson to 11am”
2 · The rules in code
The server checks that the instructor is free, that there are places and that the person asking has permission. It is not a model judging: it is tested code.
3 · The confirmation
You see the before and after and confirm. Only then is it written, and the system reads back what was saved to tell you the result.
What the rules refuse, whoever is asking
  • Two students paying for the last place at the same moment: only one gets it.
  • A lesson for an instructor who already has another at that time: it stops, says why, and only goes ahead if the school says so.
  • A staff member without permission asking to delete a lesson: refused on the server, not in the conversation.

Open to those who want to connect
Partners and other apps can connect to SurfBooking, by the house rules.
See more detail
One session, any signal
A watch, a board sensor and a handwritten note count as the same session, and stay together in the surfer's Passport. Only one location travels, at the start, to confirm you were at the peak, and it is never stored for anyone without a verified age. The full track does not leave the device.
Connections for partners
The per-peak forecast and lesson availability can be looked up by marketplaces, channel managers and AI assistants. Creating a booking is something else: it requires a key the school itself gives the partner, only works for that school's lessons and respects the places that exist.
Answers checked before they reach anyone
Before an answer from the assistant reaches anyone, it is checked: inventing a forecast, promising a refund or showing money figures to a staff member are blocked cases, in Portuguese and in English. We test these cases before every release. They cover what we know, they do not prove the assistant never errs.

Security at the perimeter
What sits at the entrance to the service, and what each request meets after it.
A protection layer at the entrance
We use a protection layer at the entrance to the service. We do not publish its configuration.
Limits against abuse
Sign-in, searches, public listings and the assistant all have limits against abuse: a stolen credential or an automated scraper is stopped long before it can do damage at scale.
Encrypted connection and protected session
All traffic is encrypted. The session is stored where page code cannot read it, and signing out deletes it. Payments go through a certified payment processor — we never see card numbers.
A second step to sign in
School owners and admins can require a second factor — a code from an authenticator app or biometric unlock on mobile. The secrets behind it and the passwords are stored encrypted, and changing an account's email ends all of its sessions.

The path of a lesson
What happens when a school owner creates or edits a lesson:
1
Origin — SurfBooking OS

The owner sets time, level, tide, places and instructor, and saves.

2
Check: SB ratios and sea conditions

The lesson is checked against the SB ratio (1:6 beginner, 1:8 intermediate, 1:4 kids) and against the tide you asked for, and gets the score of the sea conditions.

3
Where the lesson shows up: three outlets
Web · Marketplace
Lesson appears on the public spot page + Surf Today rankings.
Mobile app
Attendance, QR codes and liability waivers. Instructors run the day on the sand.
Partner network
Hotels and partners promote local lessons via link/QR — each booking knows where it came from.

An assistant with rules, not a chatbot
Our assistant is not a chatbot with instructions. It has permissions separated by role, and protections against messages made to trick it and against answers that would carry one school's data to another.
01You askIn writing or by voice, in your own language.
02It identifies the lessonAnd if two look alike it asks which one — it does not choose for you.
03The rules runPermissions, students-per-instructor ratio, timetable clashes.
04You confirmFor changes that touch the operation, the last word is yours.
05You see the resultWhat appears is what the system returned, including when it fails.

This is the path for changes. A question that only reads information does not go through confirmation, because it changes nothing.

See more detail
Guarantee · Coordination
One source of truth
The numbers come from the platform's real state (bookings, calendar, sea), not from the assistant's memory. What comes from outside is checked before it is used. What this does not guarantee is that the assistant always understands the right question: we have caught it answering beside the point, and that is open work.
Guarantee · Network
The network learns, schools stay private
Aggregated, anonymised patterns feed continuous improvement — a network effect — without ever sharing one school's data with another.
Guarantee · Outside data
External sources come in checked
Public data (regulations, official sources) is cleaned before it can influence anything. An outside page does not give orders to the assistant.
Guarantee · Per school
Each school walled off
Each school's assistant works for that school only. It knows the local context (hours, equipment, house rules), and the server only hands it that school's data; the tests cover attempts to read another's.

Walls between schools
The server checks the school and the permissions tied to the request before releasing protected information. The tests check access scenarios between schools and between roles.
See more detail
Filtered before it reaches the screen
Bookings, students, team and forecast arrive already filtered by your school before they leave our side. The screen cannot switch that off. We do not have an audit proving coverage on every path; we have tests for the ones we know.
Rules that cannot be talked around
The assistant works for one school at a time: it does not talk about others, and platform rules hold even when it is asked otherwise.
Your school's notes
Each school writes its own notes — hours, equipment, house rules — and the assistant reads them before answering. They belong to that school only and are never shared with others.
Personal data covered before it reaches the assistant
Emails, phone numbers, tax IDs, IBANs and card numbers are removed from each message before it reaches the assistant, and again from the answer on the way back. We test this before every release.

The sea conditions
Why our 'best window for beginners' isn't just a guess.
01What there is to readSwell, wind, tide and sea state, by the hour.
02What that beach doesEach spot filters the same sea differently. This is where we read the beach.
03The estimate and the confidenceAn hourly number comes out with a confidence level. When it is borderline, we say so.
04The school decidesWhoever is looking at the water always has the last word on going in.

We have not measured this estimate’s error against observations at sea. It is stated at the foot of the page, with the others still missing.

See more detail
Honest confidence, not false precision
When the data isn't certain, the spot gets a 'low confidence' badge instead of pretending we know. We'd rather tell you it's borderline than sell you false precision.
Per-level pedagogical windows
We rate each window of the coming days against SurfBooking's level definitions: a good window for beginners is not what suits advanced surfers. The best window you see when creating a lesson is the one that fits the level you are going to teach.

How we prove what we say
The part nobody copies is not the architecture. It is what we refuse to do.
The trials put the system to work
Reading whether it is right is not enough: our trials repeat the case that failed on the real system. So when we fix it, it stays fixed. And each trial says, in writing, what it proves and what it does not.
Where there is no measurement, it says 'not measured'
It is the house's most tedious rule and the one that buys the most trust: a number nobody measured does not go into a page, a report or an agent's answer. If we read the sea and the reading is borderline, the spot gets a low-confidence mark instead of faking certainty. We would rather tell you we do not know.
Every new part declares which promise it protects
A component that protects no promise is ceremony, and it does not get in. The moment it is born it writes down why it exists, what breaks if it disappears, and how we know it is still alive. That is what stops a large system from filling up with parts nobody remembers the reason for.
Our number is never someone else's number
We do not tune the forecast to match a competitor — agreeing with another model is not being right about the sea. What a school writes for its assistant is information, never instruction: it can tell it where you meet and what to bring, and it cannot change what the assistant is or what it charges. Prices, availability and refunds always come from the same place.

These tests are our own. We do not yet have a security certification from an independent body.

What this page did not measure6
Things this page describes and has not yet proven in operation. Reviewed on 28 Oct 2026.
The production network configuration
Not yet independently verified.
Recovering from a backup
Copies are daily and encrypted. Until we publish a full drill, we talk about copies, not recovery time.
Forecast error against the real sea
We have a per-spot model and an hourly confidence indicator. What we have not published yet is the error measured against observations, with the sample and the period. Agreeing with another model is not being right about the sea.
Deletion across every table
The deletion path exists and is recorded. We do not yet say it is complete across every table.
Sensors and the watch, on a device
Merging sessions from several sources is built. It was not measured on a device in this pass, and what is not measured on a device is not announced as measured.
Answer checking in every language
The checks cover the cases that are written, in Portuguese and in English. Coverage in every language and every possible sentence has not been shown: a check only catches what someone foresaw.

Put to the test before it talks to you
What we throw at our own assistant before it reaches anyone.
Staff
Tries to see colleagues' data
Customer
Demands refund · leaks card
School owner
Pushes the limits
Long conversation
Lulls then strikes
Every message is cleaned before it is read
Before the assistant reads a message, personal data is removed and the known attempts to trick it are neutralised. When a new form of attack shows up, we write a test for it before we call the fix done.
Six difficult profiles, made to put it to the test
We test the assistant against difficult profiles — a frustrated customer, an owner testing limits, a staff member probing colleagues' data, someone trying to trick it over many messages. The rules run before every release; the full conversations run separately, launched by a person.
A failed rule stops the release
A failed rule is not a warning: the release does not go out. Whether it is “no IBAN reaches the assistant” or “a staff member cannot see another instructor's bookings”, the answer is yes or no, with no opinion. We judge behaviour, not marketing copy.

Homework done on every school application
When we verify a school for the “School verified by SurfBooking” badge, an assistant prepares a summary so the person reviewing reads facts, not a blank form.
Confirmation against public data
The assistant looks for public mentions of the school and of the declared licence, and marks each claim as confirmed, not confirmed or contradicted. Each fact carries its source, so the person reviewing can open it.
A look at public reviews
A second pass looks at the school's public reviews for odd signs: coordinated negative campaigns, suspicious spikes of five stars. It is information only and blocks nothing: it reaches the summary for the person to weigh.
The summary stays closed
The summary is seen only by our team. It does not reach another school, does not train models and does not enter another school's assistant. Deleting the case deletes the summary.
A person decides
The assistant neither approves nor rejects. It writes the summary; a person reads and decides. Every approval and every rejection is recorded with the summary, so that what was known at the moment of the decision can be reconstructed.

Data resilience
What we do so your operation outlives a failure.
Records that are not rewritten
Administrative operations (account changes, permissions, deletions on request) go into a record that is only ever added to. For refunds and payments to schools we go further: each line is tied to the one before, so a change made afterwards shows.
Backup replicated off-database
Encrypted copies every day, kept outside the production database, and a second copy kept elsewhere. Recovery depends on the last copy that was completed and verified.
Your data, whenever you want it
Any school can download its operational data as an encrypted ZIP opened with its own account password, which is verified and never stored. It includes bookings, lessons, channel clients, staff, equipment, waivers, reviews, announcements and partners. It excludes app students’ contact and health data and the content of conversations.
What auditors see
Under a confidentiality agreement, when a regulator asks, we show our controls: the proof that privacy, the record of actions and deletions on request work as described. We do not show the content those controls protect: the school's notes, the assistant's instructions, the conversations between schools and the AI.

Connect SurfBooking to ChatGPT or Claude

Add SurfBooking as a connector and ask in your usual chat. The answer comes from SurfBooking data.

  • Surfers
    Ask where to surf today, how the sea is at a beach or which lesson suits your level. Read-only: to book, you get the link and pay on SurfBooking.
  • Schools
    The owner signs in with the school account and sees lessons, bookings and the sea. Anything that changes something arrives as a proposal and only happens when you confirm it in the SurfBooking OS.
  • Instructors
    Each instructor signs in with their own account and sees their lessons, schedule and the sea for those lessons.
Learn more →
About · For schools · For instructors · Support

Log in

SurferFind spots, book lessonsSurf schoolManage lessons & paymentsInstructorPortable CV, school invites

Back to top