An offshore racing team, about twenty people ashore: technical, logistics, administration, communication. Their tools are the ones many teams use today.

  • Google Workspace for the shared Drives, the HR calendar and the “Navigation” calendar that says when the boat is accessible.
  • Monday for the technical job list, read on a phone by the technicians.
  • Asana for management.
  • A spreadsheet for the schedule of the race village.
  • WhatsApp for everything else, which is far too much.

Nothing unusual. Each tool is good at its job. And yet, when the team manager described her mornings to me, the problem was obvious.

The problem: the information exists, it does not arrive

Every evening, someone from logistics compiles tomorrow's programme in a grid, then posts it on the team WhatsApp. It takes a long time. It is not personalised: the technician reads the comms programme, comms reads the yard's. And when an interview moves from 11:30 to 14:00, last night's message is already wrong.

Meanwhile the technicians receive dozens of emails in copy. The two that matter, the weather alert from race direction or the request addressed to them directly, are buried in the middle.

The need fits in one sentence: everyone should know in the morning what concerns them, without opening five tools or reading a long WhatsApp thread.

The wrong reflex: replace everything

The usual answer to this problem is “let's put everything in a new tool”. I ruled it out straight away, for three reasons.

  • The tools in place work. Monday on a phone, for a technician in a shed, is exactly right.
  • A migration in the middle of a season, with a race at the end of it, is the best way to lose information.
  • The problem is not where the data is stored. What is missing is the reading: nobody has time to go round five sources for every person, every morning.

So: no tool changes. We add a reading layer on top.

What I am building: a morning board

One page per person per day, opened on the phone. It reads five sources, read-only, and keeps only what concerns that person on that day.

  • Your day: the slots when the boat is accessible (Navigation calendar), the appointments from the village schedule, the absences planned in the HR calendar.
  • Your tasks: the Monday or Asana tasks assigned to you for today, with their priority, and the overdue ones.
  • Your important emails: only those that pass simple rules. The word [ACTION] in the subject, a key sender such as race direction, or an email where you are a direct recipient rather than in copy.
  • The boat status as a banner at the very top: “Boat closed from 18:00, weather alert”. Visible before anything else.

A meeting that appears both in the Navigation calendar and in the village schedule shows up once. It sounds trivial, but it is the kind of detail that decides whether people trust the page or not.

The manager's view: what is jamming

The person running the team does not need her own day. She needs to see the friction before it turns into a problem. So her page lists, for the day:

  • the conflicts: the electronics engineer is on leave but has a task assigned, or is expected at the 08:30 briefing;
  • the overdue tasks, per person;
  • the day's absences;
  • the important emails and who they concern.

None of this is new. All of it was already in Monday, in Asana and in the calendars. Nobody was cross-checking it, that is all.

In the evening, and when things change

Around 17:00, the same mechanism prepares tomorrow's programme for each person. The collective evening message disappears, or becomes very short.

When something moves during the day, the rescheduled interview, the boat closed for weather, the tool only notifies the people concerned. WhatsApp is kept for real emergencies, which is precisely the point of the usage charter the team is writing.

As little AI as possible

I build tools with AI, and this article sits on a website called NBN IA. Yet in this morning board, AI is almost absent, and that is deliberate.

  • Reading Monday, Asana, the calendars and the spreadsheet: plain code, through their APIs.
  • Sorting by person and by day, spotting conflicts, merging duplicates: written rules that can be read and explained.
  • Deciding whether an email matters: rules first. A small model only for the cases the rules cannot settle.

Three reasons for that choice. Rules are predictable, and a team preparing a race needs predictable. The boat's data is sensitive and stays out of scope. And this team cares about the footprint of AI: I would rather spend it while building the tool than every time a page opens.

One single write, and it is a choice to put to them

At the bottom of every page, one line: “To change something, go through the original tool. This board updates itself.” That is the contract: the tool reads, it does not write. The sources of truth remain Monday, Asana and Google.

I did add a “Done” button, to tick a task from the phone without opening Monday or Asana. It writes to the source tool, and only that. It is a departure from the read-only principle, so I will present it as an option to accept or decline, not as a given.

Where it stands, honestly

It is a prototype. It runs on fictional data I created in a test Monday, a test Asana, test calendars and a test mailbox: around twenty technical tasks, a dozen management tasks, a week of schedule, a few emails including two [ACTION]. It is hosted on Vercel and regenerated each time the sources are read.

The team is racing until the end of November. When they are back, I show them the prototype on a video call, ideally with the people concerned. Only then: a written proposal, brick by brick, a build during the winter refit, and a stable tool for the relaunch in spring. No figures promised, no tool replaced.

What it means for any team

If your team has tomorrow's programme on WhatsApp, technicians copied on everything, and one person spending the evening compiling, you have the same symptom. The answer is not a sixth tool. It is one page per person, in the morning, that reads the other five.

This is the kind of application I describe on the page about custom web applications. And if you want to know why I insist so much on rules before AI, I wrote an article on silent failure, the breakdown nobody sees.