Keep it focused on independent travellers, city tours, and single sessions.

Keep the capture flow regular and explicit.

Preserve Trips as the main discovery surface.

Keep the CRUD surface narrow.

Use them as supporting inventory.

Do not promote it to a separate commercial root.

Use hero-led sections, city cards, and direct entry cues.

Let the full editor feel like a normal product page rather than a test harness.

Keep the supporting inventory aligned with Trips.

Keep the bridge explicit.

Leave commercial authority in Trips.

Use a conventional landing page, a fuller intake page, a Trips featured-experiences lane, and a narrow bridge into trip execution.

Experiences

Experiences are reusable city-linked commercial units that support Trips, LineItems, and future booking flows.

This feature exists so users can:

• capture a reusable experience record
• associate the experience with a city and product type
• surface the experience inside Trips
• keep a lightweight editor separate from full trip execution

Inside Molino App, this feature exists to:

• preserve reusable experience data
• keep capture and mapping thin
• feed the Trips featured-experiences lane
• provide a support layer for LineItems, Offers, and Orders

• schema entity exists
• /experiences starter capture route exists
• project-scoped CRUD actions exist
• Trips already surfaces featured experiences
• city-linking is part of the domain model

Built / locked

• Prisma Experience has slug, basePrice, currency, externalId, active, featured, cityId, productTypeId, and relation support for line items and trip-city composition.
• saveExperienceDraft() persists starter/mapped experience bundles and revalidates /experiences plus /experiences/test.
• getProjectExperiences(), createExperience(), updateExperience(), and deleteExperience() provide project-scoped CRUD.
• Trips consumes active experiences through getTripsPublicData() and maps externalId into FareHarbor booking hrefs.

Built / partial

• The starter capture and test/editor surfaces exist, but are still lighter than Trips.
• Experience pricing can feed line-item calculations through support code, but Experiences does not own the canonical booking path.

Docs-ahead / pending

• Richer experience-to-trip composition through TripCityExperience is schema-supported but not yet the main production authoring path.
• Duplicate/variant handling for city tours and FareHarbor-linked experiences remains a pending data hygiene concern.

Critical next step

Keep Experiences as supporting inventory: improve city/FareHarbor data quality only where it improves Trips lane projection or the eventual LineItem/Offer path.

• pricing authority is still lighter than Trips
• richer LineItem generation is not the primary home of this feature
• booking authority is not centered here
• action maturity is adequate for capture, not for a full commerce engine

• Experiences is not a canonical commercial pipeline root
• it does not replace Trip execution
• it does not own order authority
• it should not become a parallel booking system

• routes: /experiences, /experiences/[id]
• app folder: app/experiences/
• actions: create, update, list, delete, capture, mapping
• integration points: Trips featured-experiences lane, Trip composition, LineItems, Offers
• models: Experience, TripCityExperience, supporting product-type mapping

• a separate commercial booking engine
• replacing Trips as the primary execution surface
• duplicating pricing authority outside the established pipeline

• keep /experiences as a thin capture and mapping route
• keep Trips as the main consumer of experience inventory
• preserve the featured-experiences lane as the primary surface for discovery

• extend pricing only where it feeds Trip -> LineItem -> Offer -> Order
• keep the execution bridge explicit and deterministic
• avoid introducing a second commerce model

• add filtering or list views only if they help Trips or Offers
• keep the editor and capture flow simple
• defer richer automation until the core pipeline needs it