Book Cruise Now
Nobody lets you book a Galápagos cruise online. I founded, designed, and engineered the marketplace that does.
- Role
- Founder, Designer & Engineer
- Timeline
- 2023 – present
- Team
- Me (solo)
- Scope
- OOUX / ORCA domain modeling · End-to-end product design · AI-assisted engineering · Next.js + Prisma + Stripe · Marketplace operations
My role
- Founded and operate a three-sided marketplace for Galápagos and expedition cruises: buyers, ship operators, and platform admin.
- Mapped the entire domain with OOUX before designing a screen — 45 objects, 118 relationships, 635 calls to action.
- Wrote the object model as Python and generated the Zod and Prisma schemas, fixtures, and per-object guides from it.
- Designed and shipped the product solo, working with AI agents against the generated model — live at app.bookcruisenow.com.
- Run operator onboarding, buyer inquiries, and the migration of the legacy inquiry business onto the new platform.
TL;DR
In short
Problem
Every way to book a Galápagos cruise runs through a travel agent's inbox or a single ship's static site — nobody in the category lets a traveler book a cabin online.
Approach
Mapped the domain as objects before flows or screens — Sophia Prater's OOUX — then compiled that object map directly into the codebase and built the marketplace solo with AI agents.
Outcome
24 of 24 MVP object arcs shipped and the marketplace live in production, inheriting a funnel that converts visitors to inquiries at 1.54% — above the industry's 0.5–1.0% norm.
Context and problem
The situation we walked into
Business context
The Galápagos cruise market splits two ways: agencies that sell any ship but only by email and phone, and operator sites that transact for exactly one vessel. Nobody offers real-time availability you can book against — that gap is the business. Book Cruise Now charges operators a flat monthly fee per active ship, no commission: gated routing, not a paywalled platform.
User context
Buyers are planning a once-in-a-lifetime trip averaging $5,316 per booking, and 71% of them arrive on a phone. The status quo hands them a multi-day email thread to learn whether a cabin even exists. Operators sit on the other side of the same gap: in the legacy inquiry funnel, 48% of registered ships received zero inquiries in a month.
Constraints and complexity
One person is research, design, engineering, support, and sales — every hour of modeling competes with an hour of shipping. The platform is never Merchant of Record, so payment is modeled as a mirror over rails like WeTravel and PayPal rather than a ledger BCN owns. Passenger manifests carry passports and dietary data, which forced 6-month PII purge windows and consent surfaces into the object model itself. And a live legacy business — 2,545 future listings — had to keep selling while the replacement was built.
Goals and success metrics
What success looked like
Replace the inquiry-only legacy site with a marketplace where a buyer goes from search to booked cabin without a phone call — designed, built, and operated by one person.
Success criteria
- A buyer completes a booking online with no phone or email step.
- Operators list ships, itineraries, and departures self-serve.
- Every schema, fixture, and object guide generated from one model source — zero hand-edited duplicates.
- The marketplace live in production on app.bookcruisenow.com.
- The 2,545-listing legacy catalog migrated by script, without breaking the live inquiry funnel.
Approach
How we got there
- 01
Foraged 103 nouns into 45 objects
ORCA rounds 1–2: harvested 103 candidate nouns from years of operating the inquiry business, then modeled the domain into 45 objects and filled a 45×45 nested-object matrix — 118 directional relationships written as sentences, 17 junction objects. The matrix surfaced the product's core insight: buyers don't shop ships or itineraries, they shop departures — a dated, priced sailing.
- 02
Wrote the object map as Python
Instead of a spreadsheet that goes stale at handoff, the canonical model lives as Python modules — objects, relationships, attributes, calls to action. One command generates the Zod and Prisma schemas, JSON fixtures, an interactive map viewer, and 30+ per-object guides, with an idempotency check proving source and output never disagree. The map isn't documentation of the system; it compiles into the system.
- 03
Sliced the MVP with a list-click test
ORCA round 3 ran one question against every object: would I see a list of these and want to click in? That test sorted all 45 objects by priority and pulled the P0–P1 core — the objects buyers and operators actually touch — into the MVP, promoting surprises like Expedition Leader and Review over safer-sounding infrastructure. Killed candidates stayed in the model marked Out — Prater's “filter, don't delete” — so every dead end remains auditable.
- 04
Ratified every call, one at a time
AI agents did the heavy modeling, but no decision entered the model silently. Each one surfaced as a plain-English question with options, consequences, and a recommendation; I ratified or overruled, and the outcome went into an append-only decision log. Across the modeling phase, 191 of 198 recommendations were accepted — a running measure of whether the agents actually understood the domain.
- 05
Shipped object by object in arcs
Each MVP object became an arc: schema, then server actions, then representation — with Storybook rendering Card, Detail, List, and Landing views per object so pixels test the model, not just types. 24 arcs closed at 24 of 24. Recurring moves were mined into a pattern library, so later arcs reused proven primitives instead of re-deriving them.
Key decisions
Forks in the road
Model the nouns vs mock the screens
The default solo-founder path is screens first: Figma a booking flow, build it, patch the data model as reality intrudes. But a three-sided marketplace carries four roles, lifecycle state machines, and PII law — complexity that lives in the nouns, not the flows. OOUX's bet is that mapping objects, relationships, and calls to action first makes every later screen a derivation instead of a debate.
- Decision
- Ran the full ORCA process — candidates, matrix, prioritization, representation — before designing a single screen.
- Tradeoff
- Weeks of modeling with nothing visual to demo, on faith that the noun layer would pay it back downstream.
Two objects vs one user model
Buyers and operator staff behave nothing alike — different calls to action, permissions, and lifecycles — but the same human can be both, and the standard call is one User model with role flags. In the matrix, a single USER object kept muddying every cell: half its calls to action applied to half its instances.
- Decision
- Split Buyer and Operator-User into separate objects in the model, backed by a single persisted user row — mental model first, storage second.
- Tradeoff
- A permanent naming gap between model and database that every schema must translate across — carried by the code generator instead of by memory.
Gate the routing vs gate the platform
The industry norm is commission per booking, which makes the platform a merchant in the middle of every payment. A subscription paywall avoids that but strangles supply: operators won't pay to list on a marketplace with no traffic. The third option splits access from routing — listing is free, and payment controls where inquiries and bookings go.
- Decision
- Operators join and list free; a flat monthly fee per active ship routes inquiries and bookings to them, and unpaid operators' inquiries fall through to admin, who services them by hand.
- Tradeoff
- I personally answer inquiries for unpaid ships — manual work accepted because each one is also the sales conversation.
Solution
What we shipped
Outcomes and impact
What it moved
Objects modeled
45
Foraged from 103 candidate nouns and mapped across a 45×45 relationship matrix.
MVP arcs shipped
24/24
Every MVP object taken from generated schema through server actions to rendered views.
Visitor → inquiry
1.54%
vs 0.5–1.0% industry
Conversion on the funnel the new marketplace inherits, measured before cutover.
Avg booking value
$5,316
Average value of a booked cruise in the current funnel.
Business impact
The marketplace runs in production at app.bookcruisenow.com with Stripe subscription billing, operator self-serve listings, and an invitation-gated booking flow. A go-live audit counted 2,545 future listings and 34 operator managers on the legacy system, now moving over on a scripted cutover. The funnel it inherits converts at 1.54% on a $5,316 average booking value.
User impact
Buyers trade a multi-day email thread with an agent for real-time availability they can book against — on the phones where 71% of them arrive. Operators list and update their own ships and departures instead of waiting for an agency to sell on their behalf.
Learnings and reflections
What I’d take with me
The object map's best reader isn't human
I built the map to design the noun layer; its heaviest use turned out to be as agent context. The generated per-object guides are what AI agents load before answering any domain question — and the moment they had them, they stopped inventing fields that don't exist.
Buyers shop 5–7 objects; I modeled 45
Full-ambition modeling made the system coherent, but the list-click test that sliced the MVP came after the full map was built. Next time it comes first: model the handful of objects buyers actually shop, and let the rest earn their way in.
A solo project still needs a paper trail
Every modeling decision was ratified one at a time and logged append-only — 191 of 198 agent recommendations accepted. Months later, “why is Payment a mirror, not a ledger?” takes one search to answer. The log is what makes a one-person project auditable.