Getting ideas across

I started from a hypothesis about performance: the coach couldn’t tell whether the crew had improved or the sea had been kinder. I parsed 9,000 messages from clubs in Rio before building anything: 30% of cycles lost confirmations when two people pasted at once. I corrected my own occupancy number when it didn’t match the club’s prices: the boats ran at 95%, with a waiting list half the days, so filling seats wasn’t what the coach needed.

Three facts seemed to contradict each other: lists fill all year, attendance drops in winter, and the coach complained about no-shows without a single number. They fit once you see that the group records intention and never who got in the boat. 67 times, a rower dropped out less than two hours before a 5:40 session, and lists took a median of 6 hours to reach quorum, so the coach spends every afternoon on watch. 13 of 39 long breaks among regulars had no return, one of them a rower with 51 confirmations, and the departures were sudden. Talking it through with the coach, we understood why: missing one morning and leaving the club are the same decision, the one that saves energy, and what turns it around is looking at the sea and knowing the group is waiting for you.

The group stays, because it holds the club together: one coach tried to close it and had to reopen it, and in Rio a stolen phone takes every app and account with it. So the work went into the process around the group: who opens the list, what moves on its own, when the coach gets the sea call to approve, how attendance gets marked, and how leaving is measured per person, since changing schedule isn’t quitting. During the pilot, which started in September 2026, the channels changed, from messages in the group to a personal link for each athlete, and the coach asked to bring monthly fees into the same cycle. Three rules held: the coach approves, the sea call is never automated, and money stays out of the group.

List apps already exist by the dozen, some of them free. The process fits any water sport with recurring sessions, a fixed number of seats, one coach and a sea that decides whether the session goes out, from dragon boat and surfski to sailing and open-water swimming.

A developer sells through its own team, outside brokers and agencies at the same time. Commission is paid on the closed sale, so the buyer who didn’t buy is nobody’s job: what they could afford and why they walked away gets lost, and the developer pays again to find the same person. Buyers spend months meeting brokers who offer roughly the same units.

Rialop runs two channels on one product: a white-label workspace where the developer owns its leads, and a performance channel where Rialop captures the buyer and lends the lead for a fixed term, recovering it if there’s no sale. In June the proposed data model mixed who owns a lead with who manages it, because of how the system had been built. I asked whether each rule existed because the business needed it, took the open questions to the founder, and wrote the rules in commercial language: a loan with an exclusive term, one manager at a time, origin always recorded, a developer’s own leads never visible to Rialop. Automatic deduplication and instant unlocking stayed out; a 24-hour delay was accepted. Validation with users came before building the rest.

After more than twenty meetings with developers, the founder and I read the market again in September: developers don’t want another tool, they want to sell. RialFit moved from software to managing demand, and the buyer’s side became a matter of time, a qualified answer in minutes for someone used to waiting days.

The work came in bounded projects, each a new financial product to imagine and define with Fidi’s team: research, ideas, conversations with stakeholders, and a product definition, with a UX specialist I led. Virtual accounts, closed wallets, cash pooling and cards, launched by retailers and fintechs under their own brand on banks that are already integrated, with KYC and anti-money-laundering checks built in. Three parties meet on every screen: the company, the partner bank and the end user. I started by defining what the product is, an operations tool for the client’s team, and wrote its rules, all about what a screen may claim before the bank confirms it, with consistency ranked above creativity. Active, blocked, pending and operating mean one thing everywhere, and no screen ships without its empty, loading, error and success states. When the system went to AI prototyping tools, I cut it to three principles and a few hard limits.

The client is the company. HR sends the list of employees, often under Chile’s training tax credit, and needs a progress report back: level, attendance and a pass rule that leads to a certificate. A year earlier operations ran all of this alone. A new platform, scalable but half built, made every enrollment, date change and teacher payment a request to engineering or a spreadsheet. Operations asked for the autonomy it used to have.

I mapped enrollment with operations and engineering together and agreed the rules with the head of operations: the system suggests and a person approves, attendance is the source of truth and teachers are paid for the hours they taught, no change erases history, bulk actions get a second check. The north, set by operations, was cutting 80% of the manual work. The global calendar, search and mobile version stayed out, each spec with its “not included” list. I logged 463 decisions in six weeks, with 30 reversals and 28 of my own proposals rejected, and moved status from dates to milestones such as the end of the hours spreadsheets.

Before the backoffice I worked on the student side: a rewards module I redesigned and prototyped, in production since May 2026; the lottery rules, fixed before anyone tested them; and the community, where we found with operations that students stayed silent for fear of speaking badly in front of colleagues.