Founding a Galápagos cruise marketplace

A ship has cabin classes — standard, superior, suite, the thing a buyer picks — and real numbered cabins behind them. Only the operator ever sees cabin 4, the one with the window.

Each ship runs itineraries: named loops that can be cut into shorter segments on the same hull. An itinerary is just a list of day stops — a morning or afternoon at one visitor site.

Buyers don't shop ships or itineraries — they shop departures: a dated, priced sailing. And on availability they only ever get a yes or a no, never the cabin numbers.

The buyer side starts anonymous. A visitor can favourite and inquire without an account; confirming an email promotes them to a buyer, and everything they did follows them across.

An inquiry only exists once the buyer's email code comes back — until then it's an encrypted stash. If the operator says yes, that's a booking invitation: a held cabin, a price, and a link that expires.

Accepting the invitation makes a booking, and the booking consumes exactly one availability slot. The payment is a mirror of what happened on the operator's own rail — BCN is never the merchant.

Every booking has exactly one trip, and the trip owns the manifest: passports, dietary needs, flights. Passenger data is purged six months after the trip ends.

The operator: teams as a tenancy boundary — row-level security scopes every query to one — staff in the portal, and exactly one subscription. Unpaid is a state, not an absence.

That's the cast. Every relationship you just watched is a sentence in a Python file, and the database schema is generated from those sentences. When the model changed, the schema followed.

Everything hung off the ship — seventeen tables directly. The row itself held 45 columns: the spec sheet, ops flags, feature booleans, the sales owner's personal phone number, and an AI-written description.

Beds were mapped to cabin classes twice — a legacy table and its replacement, both live at once. The departures join still read the old one, and the delete cascade still knew it by name.

The bookable thing was a listing: an itinerary plus a date and a price. It also carried its own analytics — view and inquiry counters incremented on every page hit, in the same row buyers were reading.

One user table held travelers and portal staff, with a free-text role column checked in middleware. The entire multi-tenancy story was user_ship: three columns saying who could see which ship.

Then a second identity graph. Anonymous subscribers lived in email_subscriptions with their own favourites and saved searches — and saved_search kept its user_id nullable so it could serve both masters.

Three favourite tables shipped. One worked. The other two were schema only — no route ever read or wrote them. My mockups said wishlist, so the code said favourite, and nobody asked which objects deserved one.

The lead — the thing that paid for everything — was ship_inquiries: 27 columns, two email fields, five UTM columns, and a name that was blank on every production row. The real names landed one table over, in the raw attempts log.

And the leftovers. A visitor-site table with coordinates to ten centimetres and zero routes. A notification queue with no processed flag, so it only grew. And the corpse of the views table, archived after 2.3 million fake rows — still holding a foreign key to ship.

Nine tables nothing wrote to. Twenty-eight routes nothing called. None of it is on Kameron — he built the nouns I gave him, quickly. The nouns were mine, and two years later the rebuild started with a week of refusing to draw screens until they were right.

It starts anonymous. A table of dated, priced sailings with island, wildlife, and cabin filters — no account, no cookie wall. A cabin class says available or not; a buyer never sees a count, so nobody can watch inventory drain.

The inquiry form is stashed encrypted, and nothing exists until the six-digit email code comes back. Only then is there a lead — and it lands in the operator's inbox, where a paid ship sees the whole thing.

A ship that hasn't subscribed doesn't see the inquiry — a teaser at most: first initial, month, party size. The full thing falls through to me, I forward it to the shipowner by hand, and they answer the traveler directly. Every action still writes an audit row.

A subscribed operator replies by email or WhatsApp, then holds a specific cabin class against the inquiry. The hold lasts 24 hours — a cron sweeps the dead ones every hour — and the invitation that follows locks its price at send time.

The buyer gets one link. It holds the cabin at a fixed price for 24 hours, and opening it under their own row-level security is what proves it's theirs. The operator can withdraw the invitation; the buyer can only read it.

Passengers, contact details, the agreement. The total is computed once, server-side, and snapshotted on the booking — then it sits at requested until the operator answers.

Confirming attaches the operator's own payment link. The money moves on their rail — WeTravel, PayPal, or a wire — and BCN mirrors the state without ever holding a dollar.

Passports and dietary needs go on the manifest. Air tickets, vouchers, and the confirmation come back as private documents — the bytes never get a public URL — and six months after the trip it's purged.

That's the happy path. The admin lane never left: I can act as any operator — every write under impersonation audits both identities and shows a banner — and until a ship subscribes, its inquiries are answered by a person. For now, the person is me.