WhereNext.to

Hand-rolled server-side cart and checkout — The hardest and most interesting part of the project, designed and built from scratch before AI assistance was available.

• Cart state lives server-side in Strapi rather than in browser storage, so a cart survives device changes and can be reconciled against live product data at checkout.
• Composed of a deep component tree — cart items with per-item option and traveller inputs, modals, promo code chips and validation, summary line items, and add-to-cart popups surfaced directly from experience pages.
• Checkout is schema-validated end to end (React Hook Form + Yup) before orders are written to the backend's order domain.

Deferred cart merging across authentication — Solving an eventual-consistency problem between two systems.

• When a logged-out visitor with a populated cart signs up, the authenticated user may not exist in Strapi yet, because identity is owned by Clerk and propagation isn't instant.
• Rather than fail the merge or silently drop the cart, the backend stamps a merge_with_auth_id flag onto the anonymous cart and completes the merge later, once the user record materialises.
• A small edge case with an outsized commercial cost if handled naively — exactly the kind of race that quietly loses customers.

A large third-party integration surface — A significant share of total effort went into normalising external data into one coherent content model.

• Viator products are fetched either live via a bulk-product proxy route or from an Algolia mirror index, with a source switch so the same UI works from either path and falls back gracefully.
• A custom Algolia search client suppresses empty queries (returning synthetic empty result sets) and honours an explicit empty-search-trigger sentinel, avoiding wasted search operations on first paint.
• Google Places integration supports both the legacy and new Places APIs behind one function signature, with a field mask tuned to only the place attributes the product actually renders.

Map-driven discovery — Search and browsing are as much spatial as textual.

• Mapbox-based map search with a synchronised sidebar, custom markers, and distinct popup components for countries, destinations, in-house experiences, and Viator products.
• A spiderfier component fans out overlapping markers so dense clusters of experiences remain individually clickable.
• Maps are dynamically imported so the heavy GL bundle never blocks non-map routes.

Content composition and rendering pipeline — Editors assemble pages without developer involvement.

• A block-based renderer maps Strapi dynamic-zone components onto React blocks (two-column text/image, icon-box rows, card rows, flexible rows), so page layouts are content-driven.
• Rich text is rendered with markdown-to-jsx and sanitised through isomorphic-dompurify as a documented, enforced convention.
• Image delivery is tuned with explicit deviceSizes/imageSizes breakpoints, a 90-day minimum cache TTL, and a remote-pattern allowlist covering Cloudinary, Mapbox, and partner CDNs.
• Sitemaps are generated at build time from a webpack server hook, and redirects live in a single versioned data module rather than scattered config.

Infrastructure migration to Dokploy — Recent work moving the CMS off managed hosting onto self-orchestrated infrastructure.

• Container-based deployment of the Strapi backend managed through Dokploy, giving direct control over environments and the database.
• Because the canonical repository sits on the product owner's account and couldn't be connected to Dokploy directly, deployment runs from a maintained fork kept in sync — a deployment artifact rather than a separate codebase.