A travel company that runs small group trips for solo travellers aged 18 to 40 needed a website that could sell trips while educating people about them as well. A visitor should be able to easily find a trip they want to go on, see its price in their own currency, reserve a spot, and learn about the culture, festivals and more.
Before the build there was no website, just an idea and a design file with three screens in it: a home page, one trip page and one blog article. Our plan at the start put it like this: the file had a good brand in it, but it couldn’t be built from as it stood, and about fifteen page templates hadn’t been designed at all.
The business model also ruled out an off-the-shelf booking tool. Travellers reserve for free. A departure only goes ahead once enough people have joined, which the owner decides. Only then is each traveller invoiced, in their own currency. The site had to carry that process from the first click to the staff member pressing “confirm”, and it had to hold a large library of guides alongside the trips.
What the business needed:
| Before | Now |
|---|---|
| Three screens, no website | 442 pages live |
| One “from” price in one currency in the design | Every departure priced in up to 7 currencies |
| Deposit at booking, balance later (the first plan) | Free reservation, one invoice once the date is confirmed |
| No way to edit content | Trips, guides, pages and SEO fields edited in one admin |
| No record of who is on which date | Each departure lists its travellers, with one button to confirm and email them |
| No traveller login | Account by emailed link, with reservation status and a group chat |
The site is one system: the public pages, the reservation flow, the traveller account and the staff admin share one database, so a change made by staff shows on the site straight away.
A visitor picks a country and the list of trips narrows as they choose. Each trip has one page with its route map, a day-by-day itinerary and every departure date with its price. One click in the header changes every price on the page to any of seven currencies.
The traveller picks a date, fills in five details and reserves. Nothing is paid. The page confirms the spot, an email goes to the traveller and to staff, and the trip page shows who else has joined that date (first name, country and age range, only for travellers who agreed).
Everyone who has reserved the same date gets a private group chat with the others and with the person hosting the trip. Travellers agree to the group rules before joining, and the chat hides phone numbers and email addresses automatically.
Staff edit trips, departures, guides, festival dates, legal pages and SEO fields in one admin, and published changes appear on the site without a rebuild. Each departure lists the travellers waiting on it; one button confirms the date and emails each traveller once, even if the button is pressed twice. The traveller’s account shows the new status straight away.
The first version followed the original plan: a deposit, then a balance. The business then dropped deposits: reserve for free, one invoice for the full price once the date is confirmed, seven days to pay. At the same time the reservation moved from a pop-up to its own page. Because the booking rules lived in one place in the code, the form, the emails, the terms and the trip pages changed together and stayed consistent.
The trips and guides were written as files outside the admin, more than 400 of them. Our team built an importer that reads those files, uploads only the photos that changed, and updates pages without touching anything staff created by hand. When the address structure was reorganised, the importer and a redirect map moved every page in one pass.
The starting point was three screens: a home page, one trip page and one blog article. About fifteen page templates had not been designed at all. Our team turned those three screens into a design system in code, with shared colours, type and components, and built the remaining templates from it, so the trip finder, the reservation flow, the account and the guides read as one site.
The big decision was to build the website, the content editor and the booking admin as one application on one database. We also looked at a lighter content-site framework with a separate hosted CMS. It would have been a little cheaper to run, but then the booking admin would have had to be built by hand, or bought as a separate booking product and worked around. The booking side was where the risk sat, so we went with one codebase.
| Layer | Choice | Why |
|---|---|---|
| Website and app | Next.js | Pages are prepared ahead of time and refreshed when staff publish, so they load quickly and search engines get the full text. The same code runs the reservation flow and the account |
| Content and bookings admin | Payload CMS | Staff get one login for editing pages and for running departures. It lives inside the site, so there is no second system to pay for or keep in step |
| Database | PostgreSQL (Neon) | Reservations need strict rules, such as one reservation per person per date and no double emails. A relational database enforces them |
| Photos | Cloudflare R2 | Each photo is stored once in seven sizes and served directly, so photo-heavy pages do not slow the server or run up resizing costs |
| Delivery | Cloudflare CDN | Pages and photos are cached close to the visitor. It also tells the site the visitor’s country, which sets the starting currency and the cookie rules |
| Resend | Reservation, confirmation and log-in emails are sent from a dedicated sending address, and every email is logged against the reservation | |
| Traveller log-in | Better Auth | Travellers log in with an emailed link or Google. Their accounts are kept apart from staff accounts, so a traveller can never reach the admin |
| Hosting | Own server, deployed from GitHub | Fixed monthly cost with no usage limits to trip. Each release is built and checked before it replaces the running site, and can be rolled back |
| Checks | Playwright, axe, unit tests | Accessibility rules are tested on every page template at desktop and phone widths, and the booking rules have automated tests |
Next, you send a short brief and we reply with a fixed price and a delivery date in writing. You pay nothing until you sign the order.
