Journee

Journee sells one promise. You answer a short quiz about your taste, your dates, your budget, and the places you don't want to go. Weeks later you walk into an airport with flights, accommodation, and a week of local experiences already arranged — none of which you picked, and none of which you know about until you open a postcard at the gate.

That promise is simple to say and difficult to run. Every trip is bespoke: a real destination chosen from more than a hundred options, real flights from the traveller's home airport, a real room on real dates, real bookings with local operators who answer the phone in another language. And every one of those real things arrives with a city name stapled to it.

Which is the hard part. Confirmation emails name the airport. Card statements name the hotel. A weather forecast is a destination expressed in three numbers. Running this by hand for a dozen travellers is an enjoyable logistics puzzle. Running it for thousands is a system — and one leaked string ruins the only thing the customer actually bought.

I built the system end to end: the intake quiz and traveller profile model, the destination matching engine, the proposal and checkout flow, the booking and fulfilment pipeline, the timed clue and reveal layer, and the internal console the trip designers work in.

A few minutes of quiz answers become a structured traveller profile — dates, departure airport, budget ceiling, pace, appetite for unfamiliarity, food and activity interests, and a hard exclusion list of places they've already been or don't want to go. That profile drives everything downstream. The matching engine narrows the catalogue to destinations that are genuinely bookable for those dates and that budget from that airport, and a trip designer picks the final one from the shortlist. Once payment clears, the pipeline assembles the real trip — flights, accommodation, local experiences, restaurant picks, and a day-by-day itinerary — and writes it to an operational record the traveller never sees. What they get instead is a clue every few days, a packing list, and a weather forecast with the location stripped out of it.

Matching runs in two stages, in that order. The first stage is elimination and it is not negotiable: anywhere the traveller excluded, anywhere that can't be reached on their dates within their budget from their departure airport, anywhere the season makes a bad trip, anywhere already used for them before. That pass is deliberately blunt, because a wrong answer here is a wrecked holiday, not a mediocre recommendation.

Only what survives gets ranked for taste. Pace, food, nightlife, nature, culture, and how much unfamiliarity someone actually wants are scored against the destination's profile, and the top candidates go to a human trip designer who makes the final call. The system narrows the field; a person still chooses. That split kept the trips feeling curated rather than generated, and it meant an unusual traveller could be handled by judgement instead of by a rule nobody had written yet.

The core design decision was that secrecy is a property of the data model, not a habit of careful staff. Each trip carries two representations: the operational record, which names everything, and the traveller-facing view, which is derived from it and can only expose fields explicitly marked as revealable at the current stage of the journey.

Anything that reaches the customer — email, SMS, the account area, the packing list, the printed pack — reads from the traveller-facing view only. Weather is served as a temperature and precipitation range with the location removed. Clues are written against destination attributes rather than the destination itself, then released on a schedule tied to the departure date. The Reveal Postcard is the single artefact where the boundary opens, and it opens in the traveller's hands rather than in an inbox.

Treating it this way meant a leak would have to be a deliberate override rather than an oversight, and new features didn't each need their own secrecy review.

Normal travel software fails politely: you notice the error and rebook. Here, the traveller can't sanity-check anything, because they don't know where they're going. That asymmetry shaped the engineering.

Bookings were reconciled against supplier confirmations rather than assumed successful, and any trip missing a confirmed leg surfaced in an ops queue with a hard deadline well ahead of departure — early enough to rematch a destination rather than patch one. Disruptions were handled on the operational record and, wherever possible, resolved without the traveller-facing view changing at all, so a rebooked flight didn't accidentally become a spoiler. Support ran on WhatsApp with the full operational record available to the team, so a traveller mid-trip could get an answer from someone who could see everything they couldn't.

The result was a process a small team could run at volume: trip designers spent their time on judgement calls and edge cases, and the pipeline handled the repetitive assembly that used to consume the day.