This app was built the long way — through open-ended exploration, wrong turns, and figuring out the right architecture from scratch. Every edge case surfaced, every decision tested. That exploration is the point. It produced the template and the guided mode prompt — so your version takes a few conversations, not hundreds. Build your own →
What the exploration took
How it unfolded
Trip planning
Phase 1 — Trip planning (no app yet)
It started with a single message: "I want help planning an itinerary for my upcoming travel from San Francisco. Our family of 4: 2 adults, 1 four-year-old, 1 one-and-a-half-year-old, want to go back home to India."
What followed was a deep planning session that covered far more than a rough schedule. Group demographics were established first — two adults on Indian passports with US H-1B visas, two children on US passports, then later four grandparents joining from Bengaluru with their own visa and flight requirements. Budget, travel style, and priorities were agreed. Visa requirements for each passport type in each country were researched and flagged.
Flights were researched live across three legs: SFO → Singapore, Bengaluru → Singapore (for the grandparents), and Singapore → Bengaluru for all eight. Airline options, prices, timings, and layover strategies were compared. Hotel shortlisting covered location (proximity to MRT, family rooms, cribs, early check-in), and then the confirmed booking details were woven into every subsequent part of the plan.
Logistics that a guidebook wouldn't cover: baggage storage at Changi for seven large checked bags, car seat regulations for Singapore taxis, GrabMax capacity for a group of eight plus luggage, which grandparent guide formats work on older Android phones, how the MRT handles strollers, pacing across a multigenerational group with two young children.
Dietary constraints shaped the entire food plan: vegetarian-only before temple visits, no added sugar for the toddler, soft textures only for the 1.5-year-old, low-sugar but vacation-flexible for the four-year-old, halal options noted for a mixed group at shared hawker centres. Activities were chosen and sequenced for an audience that included grandparents with mobility considerations and toddlers with nap schedules.
The key insight that shaped everything that came after: eight people, three generations, two languages, and completely different needs from the same trip. A single shared document was never going to work.
What followed was a deep planning session that covered far more than a rough schedule. Group demographics were established first — two adults on Indian passports with US H-1B visas, two children on US passports, then later four grandparents joining from Bengaluru with their own visa and flight requirements. Budget, travel style, and priorities were agreed. Visa requirements for each passport type in each country were researched and flagged.
Flights were researched live across three legs: SFO → Singapore, Bengaluru → Singapore (for the grandparents), and Singapore → Bengaluru for all eight. Airline options, prices, timings, and layover strategies were compared. Hotel shortlisting covered location (proximity to MRT, family rooms, cribs, early check-in), and then the confirmed booking details were woven into every subsequent part of the plan.
Logistics that a guidebook wouldn't cover: baggage storage at Changi for seven large checked bags, car seat regulations for Singapore taxis, GrabMax capacity for a group of eight plus luggage, which grandparent guide formats work on older Android phones, how the MRT handles strollers, pacing across a multigenerational group with two young children.
Dietary constraints shaped the entire food plan: vegetarian-only before temple visits, no added sugar for the toddler, soft textures only for the 1.5-year-old, low-sugar but vacation-flexible for the four-year-old, halal options noted for a mixed group at shared hawker centres. Activities were chosen and sequenced for an audience that included grandparents with mobility considerations and toddlers with nap schedules.
The key insight that shaped everything that came after: eight people, three generations, two languages, and completely different needs from the same trip. A single shared document was never going to work.
Building the app
Phase 2 — First app, one page
"Can you turn this itinerary into a mobile web app?" One HTML file, tabbed day view. Functional but basic — no audience separation, no food details, no dietary tags.
Phase 3 — Multi-page architecture
"The grandparents need their own simpler guide — one in English, one in Telugu." This expanded the app to four pages. The grandparent pages became progressively simpler: fewer slots, larger text, no logistics they didn't need.
Phase 4 — PWA and installability
"Can this be installed as an app on their phones?" First attempt had a subtle bug:
start_url: "/" pointed to the GitHub Pages root, not the app's subdirectory, so installs silently failed. Fixed to "./index.html". The service worker was also updated to pre-cache all pages on install — so the app works fully offline from the very first visit, with no internet connection needed after that.Phase 5 — Food as a feature
Dish lists with dietary tags (🌿 🍗 👶 🍼 ⭐), stall numbers, sugar flags for the toddler. Then
dishes.js — a single data file powering all three pages so updating one venue updates everywhere.Phase 6 — Polish
Countdown timer, shortened hero, Places and Food split into separate tabs, custom hibiscus icon generated in Python, hotel updated across 14 references in one pass, nav bugs tracked down to orphaned closing divs.
Phase 7 — Depth and distribution
A 58-item gap analysis surfaced everything missing: jet lag recovery notes night by night, a toddler backup plan at every meal, specific shops on Haji Lane, the Telugu moment at Tekka. A Prep tab was added to all three guides. Live Singapore weather via Open-Meteo — current conditions on the home screen, per-day forecast strips on every day tab. Pull-to-refresh, auto-reload on new deploy. The build story and guided prompt split into two separate pages. The prompt itself was rewritten — 5 opening questions, progressive build, 17-item stress-test, hard gates between phases.
Retrospective
✓ What worked well
Plain English is enough. "The nav is broken — clicking Day 2 does nothing" produced a fix faster than any Stack Overflow search. "The grandparents' page is missing content on the Places tab" pinpointed a single missing HTML closing tag that had stumped several debug passes. Describing the symptom in plain language, not the cause, was consistently more effective than trying to sound technical.
✓ What worked well
Small changes, deploy often. The sessions that went smoothest were ones where each change was tested in the browser before the next was requested. When three things changed at once and something broke, isolating the cause took four times as long. One request, one check, one request — that rhythm produced the best results.
✓ What worked well
No framework was the right call. Pure HTML/CSS/JS meant last-minute itinerary changes — switching from ArtScience Museum to Cloud Forest + Flower Dome three weeks before departure — could be made directly on GitHub from a phone. No build step, no local environment, no friction. The simplicity constraint made the app genuinely more useful.
✓ What worked well
Saying exactly what the audience needs. "The grandparents speak Telugu and need a simpler guide — just where to be and when, no logistics" produced a better guide than any amount of tweaking after the fact. The more specific the audience description upfront, the less cleanup later. This turned out to apply to dietary needs, language, and even attention span.
△ Do differently next time — and what the guided mode does instead
Start with a shared data layer from day one. Dish lists were copy-pasted into each HTML file individually and diverged immediately. When stall numbers were added, it meant three separate updates. The
dishes.js architecture — one file, all pages read from it — only arrived after the mess. The guided mode prompts Claude to set this up before writing a single HTML file.△ Do differently next time — and what the guided mode does instead
Verify structure after every major edit. The single most frustrating bug across all sessions: a missing closing tag that caused an entire day's content to bleed invisibly into the wrong tab. It took multiple sessions to catch. Asking Claude to check structural balance after each significant change became standard practice by session 3 — it should have been from session 1. The guided mode includes this as a built-in step.
△ Do differently next time — and what the guided mode does instead
Establish "nothing private in the app" as the first rule. Confirmation numbers and booking references started appearing in the HTML before anyone caught that the repo is public. A rule set on day one would have prevented multiple cleanup passes. The guided mode flags this before generating any content.
△ Do differently next time — and what the guided mode does instead
One consistent structure across all pages from the start. The full itinerary and grandparent guides ended up with slightly different tab attribute patterns (
data-t vs data-day), different hero CSS, different section naming. Every cross-page change required three separate edits. The guided mode uses the architecture from this repo as a template — the consistency is already built in.Ready to build yours?
Build your own trip guide →
Guided prompt · 5 questions to start · no coding needed
View source on GitHub →