Prompt to production
The prompt-to-production pipeline is how Journeys booking experiences are built today, operated with your Kaptio team during private beta. Self-serve access is rolling out to private beta tenants.
You don't build a booking frontend from scratch, and you don't wait on a platform UI roadmap. You describe the booking experience you want — brand, layout, tone, flow, channels — and the pipeline generates it, reviews it, tests it, and deploys it to a branded domain. Iterations that used to be a release cycle become a prompt.
The pipeline
1. DESCRIBE 2. BUILD + REVIEW 3. DEPLOY
Natural-language AI generates config + Live on a branded
prompt: brand, UI in your tenant repo. domain, connected to
layout, tone, Kira (our AI reviewer) your inventory and
flow, channels reviews the change; pricing, across any
automated tests run channel
against the quality bar
Describe. A prompt like "a two-step booking flow for our expedition brand: trip browse with deck-plan cabin selection, deposit payment, dark palette, our logo" is a complete cruise specification. A group-touring prompt can instead ask for "dated departures with Twin and Single room choices, optional excursions, deposit payment, and no deck plan". Existing flows are the same — "add a solo-traveller toggle to the departure step" is an iteration, not a project.
Build + review. The pipeline generates the journey.yaml configuration and the React UI source in your tenant config repository, opens a merge request, and puts it through the same gates as human-written changes: Kira reviews the code, and the automated test harness verifies the flow against the quality bar before anything ships.
Deploy. The platform bundles and serves the result — at /{tenantId}/ or your own booking domain — connected to live inventory and pricing through the Journeys API. See Tenant UI source for the hosting mechanics.
What you own, what we run
| You | The platform |
|---|---|
| The description of the experience — and final say on every merge request | Code generation, review (Kira), automated testing |
The tenant config repo — journey.yaml + UI source, readable and hand-editable | Bundling, hosting, TLS, custom domains |
| Your brand, your UX decisions, your channels | The booking engine underneath: catalog, pricing, baskets, payments, checkout |
The output is not a black box. Everything the pipeline generates lands in your tenant repository as configuration and readable source — your team can inspect it, edit it directly, or prompt the next iteration. If you ever want to take over the UI entirely, it's yours; the API contract underneath doesn't change.
One foundation, every channel
Because every generated experience runs on the same Journeys API, a channel is a frontend variation — not a new build:
| Channel | What changes | What doesn't |
|---|---|---|
| Guest-direct website | Branding, step order, content | |
| Conversational chatbot | The UI becomes a dialogue | Catalog, pricing, |
| Sales workbench | Embedded in your agents' single view | baskets, payments, |
| Advisor / partner portal | B2B channel with advisor identification | checkout, inventory |
| White-label brands | Per-brand theming on the same flow |
This is the practical answer to "how long does a new channel take": the booking logic already exists, so a new channel is a description of how it should look and behave there.
Where to go next
- Evaluate the engine underneath: Quickstart — curl from catalog to a confirmed booking
- The contract everything runs on: Journeys API reference
- The hosting model for generated UIs: Tenant UI source
- Runtime agent access for your own bots: MCP & SDK