Tolin Tide
27.
Designing an operating system for a 50-person vacation.
Build the infrastructure required to manage the group — and make sure nobody realizes they’re interacting with infrastructure.
Planning a group cruise for roughly 50 friends and family members should have been simple.
Pick a ship. Share the dates. Book some rooms. Go on vacation.
Instead, the moment people started joining, the trip became an increasingly complex coordination problem.
Different cabin configurations had different pricing and deposit requirements. Travelers needed to provide personal information, room preferences, arrival plans, shirt sizes, and roommate details. Some people had booked. Some were interested but undecided. Some needed travel help. Others needed nothing except to know where to show up.
And everyone needed enough information to participate without one person becoming the permanent human help desk.
So I did what I tend to do when something starts getting complicated: I built a system around it.
The challenge wasn’t simply organizing information.
It was designing an experience that could manage complexity without feeling complicated.
I didn’t want travelers digging through old group texts to find cabin prices.
I didn’t want our travel agent answering the same administrative questions over and over.
I didn’t want personal information floating around unnecessarily.
And I definitely didn’t want a spreadsheet becoming the customer experience.
The system needed to handle the operational side of the trip while still feeling like part of the fun.
Treat the trip like a small product.
Instead of thinking about a website as an announcement page, I started mapping the experience from the traveler’s perspective.
Someone hears about the trip.
What do they need next?
They need to understand the itinerary, see cabin options and pricing, decide whether they’re interested, and know how to proceed.
Once they join, the questions change.
Who is traveling? What information do we need from them? Have they booked? When are they arriving? Do they need a hotel? What’s their shirt size? Who is in their room? Where can they find trip information later?
Then there was an entirely different user:
me.
I needed to see the group as a whole.
That required an administrative layer capable of turning dozens of individual submissions into something usable.
The resulting platform became TolinTide.com, a custom WordPress-based hub designed around the trip rather than around a generic website template.
I defined the requirements, information architecture, workflows, user experience, administrative logic, and priorities while using AI-assisted development to rapidly translate those decisions into working functionality.
The public-facing side handles the information travelers actually care about: trip details, cabin categories, pricing, itinerary, updates, and ways to join.
Behind that sits a growing operational system.
Traveler profiles capture the information we need without forcing people through one enormous form. Separate workflows manage rooming, arrivals, shirt sizes, travel requests, overnight stays, and other trip logistics.
A private Crew Portal gives confirmed travelers access to information that doesn’t belong on the public site.
On the administrative side, the data can be organized into useful categories — interested, going, booked, and other statuses — rather than living across text messages, email chains, notes, and spreadsheets.
Each new problem became another requirement.
And each requirement had to fit the larger system rather than becoming another disconnected workaround.
Then I made it unnecessarily fun.
Because if fifty people are going on vacation together, the operating system doesn’t need to look like enterprise software.
The trip developed its own visual identity: Tolin Tide 27, built around a retro cruise aesthetic.
That identity now extends well beyond the website.
It appears across welcome materials, crew credentials, lanyards, water bottles, cabin-door decorations, stickers, apparel, and other pieces of the travel experience.
The website also became the foundation for things that have absolutely nothing to do with traditional trip administration.
There is a private Tide Cup competition.
There are scavenger hunts.
There is a crew directory.
There are plans for shared photo uploads.
Travelers can contribute to the cruise playlist.
Even the welcome bags are being designed as an extension of the same experience rather than as a collection of random promotional items.
The operational infrastructure and the brand experience aren’t separate projects. They’re part of the same system.
Requirements did not arrive neatly.
They arrived more like:
And then another thought.
And another.
And occasionally something we had already built needed to change because actual people started using it in ways we hadn’t predicted.
Cabin pricing changed.
New occupancy categories appeared.
Guaranteed cabins needed clearer labeling.
A feature that made sense conceptually turned out to be confusing in practice.
Real-world use exposed things the original design hadn’t anticipated.
So the platform evolved iteratively.
That became an important part of the process: don’t defend the original design just because you built it.
Watch what happens.
Fix what doesn’t work.
Keep what does.
Tolin Tide 27 is a little less than a year away.
But the trip already has something most informal group travel never gets:
Instead of relying on one organizer’s memory, the information has somewhere to live.
Instead of travelers needing to know who to ask, they have a central place to go.
Instead of the administrative system and the trip experience competing with one another, they reinforce each other.
And because the platform was designed around the actual problem rather than purchased as a fixed solution, it can continue evolving as the trip does.
This isn’t really a case study about cruises.
And it isn’t a case study about building a website.
It’s about what happens when a loosely defined idea becomes complicated enough that someone has to create structure.
I tend to start with the desired experience and work backward.
What should people be able to do?
What information is required to make that possible?
Where should that information live?
Who needs access to it?
What happens when something changes?
What happens when someone uses the system incorrectly?
And how do you make all of that feel simple to the person on the other side?
The technology is just the implementation layer.
In this case, the system just happens to include tropical drinks, matching credentials, a secret competition, and approximately fifty people on a very large boat.