Every product here starts the same way client work does — with a real problem. This one arrived by email, over and over, from my wife. This paper tells the story of the trip site those emails produced, what it does that trip apps don’t, and how it became TripSync: a product with a live public demo, built with the discipline — and the verification — I bring to client projects. The result is shown, not described.
1. It started with my wife’s emails
My wife planned us a serious trip: sixteen days across the Netherlands, Poland, Hungary, Croatia, and Italy, with four friends joining us. Planning a trip like that generates paper the way weather generates rain. Flight confirmations. Hotel bookings. Tour tickets with entry rules. Train options. Changes to all of the above. Each one landed in my inbox as another email, attachment, or screenshot — dozens of them, months of them.
The organizing started the way it does for everyone: a long document. Ours grew into an eighty-page day-by-day guide, and it was genuinely good — and nearly unusable on a phone in a taxi. The information existed; the access didn’t. What we actually needed at 11 p.m. outside a Kraków train station was tonight’s hotel, the confirmation number, and a directions button — not page 47 of a PDF.
So I built the site. Every email she sent got distilled into structured content, and the content got a purpose-built home: a private website that knows what day of the trip it is and puts that day’s plan one tap away.
2. One link, three modes
The site renders differently depending on where you are in the trip:
- Before you go — a polished showcase: countdown, route, the full browsable itinerary. Built to be shared with family and friends from a desktop.
- While you travel — the site opens on today. Tonight’s hotel with its confirmation number and a maps button, tour passes ready to read at the desk, what to bring, where dinner is, live weather, and who’s with you that day. Designed for one thumb on a six-inch screen.
- If things go wrong — a floating SOS button that knows which country you’re in: local emergency numbers, the right embassy, the hotel front desk, the lost-card line, and the phrases to ask for help.
Around the day pages sit the reference layers a long trip needs: bookings and budget, country quick-reference, customs and phrases, packing guidance, an open-items list that counts down what’s still unbooked, and full-text search across all of it.
3. Built like client work
Under the hood, the trip site is the same architecture I recommend to clients, for the same reasons:
- Statically generated (Next.js) — no database, no server-side code, no admin login to attack, nothing to patch. The whole guide is pre-rendered.
- Installable and offline — a progressive web app that caches the entire guide. Airplane mode, dead hotel Wi-Fi, and roaming-off are all covered.
- Action-first content — every phone number is tappable, every address opens directions from wherever you’re standing, every flight exports to the calendar.
- Verified, not asserted — the same audit pass client projects get: Lighthouse performance and accessibility runs, axe-core scans, keyboard-only passes, and layout checks from 320px to 1440px, on every release.
4. Privacy as a feature, not a filter
A trip site concentrates sensitive information: booking references, loyalty numbers, what was paid and with which card. From the first version, the rule was architectural: card numbers, security codes, and account numbers never enter the site’s content at all — there is nothing to leak because nothing is there.
Everything else is governed by tiers on one shared link. Travelers see everything: confirmations, the pass wallet, the budget. Family sees the full plan with the money removed. A public view shows the showcase and nothing private. The consumer trip apps I compared make sharing all-or-nothing; here, who sees what is a first-class feature — and it’s the one visitors consistently react to in the demo.
5. From family tool to public demo
When the site kept drawing “you should sell this” reactions, I did what I do for client demonstrations: kept the build real and made the data fictional. The public demo follows the Griswold family — six travelers on exactly the same sixteen-day, five-country itinerary — with every identifying detail replaced and verified clean.
The same trip, made safe to show anyone
| Measure | The family site | The TripSync demo |
|---|---|---|
| Travelers | Our real party of six | The fictional Griswold family — party of six |
| Dates | Dates private | August 6–21, 2027 — chosen so every day of the week aligns with the real itinerary |
| Bookings | Real confirmations, visible by tier | Every confirmation, ticket, and loyalty number regenerated as a fake in the matching format |
| Contacts | Real personal numbers, private | Fictional personal contacts; public venue and embassy numbers kept real for credibility |
| Access | Private link, tiered passwords | Fully public — the richness of the traveler view is the demonstration |
| Verification | A zero-leak sweep: builds pass only when no real name, number, or reference from the family site appears anywhere in the demo | |
The demo is live and unlocked. Every feature in this paper can be tapped, installed, and taken offline — the build quality is the point.
6. The TripSync path
- Collect. Once a trip is booked, the confirmation emails, tickets, and notes are gathered — the same pile my wife sent me, from any traveler.
- Build. The pile becomes a structured, day-by-day private trip site: showcase mode for sharing, field mode for traveling, SOS for the bad moments.
- Verify. Automated accessibility, responsive, and performance audits, plus a human read-through of every day page. Nothing ships on trust.
- Travel. One link, installed on every traveler’s phone, working with or without a signal — and a family view safe to share with everyone at home.
Sources
- Parker Technology Solutions — build and verification records for the TripSync product and demonstration sites, including Lighthouse and axe-core audit runs (July 2026).