Cayo Basecamp

Problem

Independent operators answer the same guest questions repeatedly: arrival directions, safety, food, water, tours, airport transfers, and property details. Those answers are retyped over messaging apps, in multiple languages, at all hours. Static guidebooks become stale and separate property sites duplicate the same local knowledge.

My role and ownership

I shaped the product from firsthand operating needs and built the shared application, tenant model, public marketing surface, private portal, bilingual content system, and deployment workflow.

Constraints

• Guests use the private portal briefly and should not need a permanent account.
• Arrival and safety guidance must remain accurate across languages.
• Two properties share regional knowledge but need different branding and stay content.
• The protected information is operational guidance, not payment or identity data.
• The operator must be able to update content without forking the product.

Architecture or walkthrough

A shared Next.js core renders a public discovery surface and a booking-code-protected guest portal. Tenant configuration supplies branding, stays, and scoped content for each property. English and Spanish content follow the same structured model, while activities and constraints are reused across itineraries.

Important decisions

1. One core, configured per property

Context: A second property needed the same product with different branding, stays, and some different recommendations.

Choice: Keep structure and behavior shared while tenant-scoping the content.

Reason: The expensive asset is maintained local knowledge; a fork would duplicate every correction and eventually drift.

Tradeoff: Every feature needs an explicit shared-versus-tenant boundary.

2. Booking codes instead of guest accounts

Context: A typical guest needs the portal for only a few days.

Choice: Let the existing booking reference unlock the private surface.

Reason: Account creation and password recovery are disproportionate friction for a short relationship.

Tradeoff: The access model is weaker than full authentication and must be revisited if the portal ever stores payment or identity information.

3. Bilingual content is first-class data

Context: Safety and logistics instructions can become wrong or misleading when treated as an automatic translation pass.

Choice: Maintain English and Spanish as parallel content with reviewable fields.

Reason: Some instructions require deliberate translation, and some guidance genuinely differs by audience.

Tradeoff: Every change becomes two edits, with translation drift as an operating risk.

4. Itineraries compose structured activities

Context: One-, two-, and three-day plans reuse the same sites, operators, packing rules, and safety constraints.

Choice: Model activities once and compose them into itineraries.

Reason: The constraint belongs to the activity and should remain identical everywhere it appears.

Tradeoff: Structured authoring is heavier than writing a few independent prose pages.

Defensible outcome

The product is live in a pre-launch state and serves two property brands from one codebase. The shipped surfaces demonstrate public discovery, private booking-code access, structured itineraries, and bilingual content. No guest-volume or revenue claim is made.

What I would improve

I would reduce the manual pre-arrival messaging step. The operator currently copies the unique portal link into the booking platform and records that it was sent. A supported integration—or a carefully scoped browser extension—could remove that fragile handoff.