Travel Bucket List Planner Project Report
1. The Concept
Travel Bucket List Planner is a lightweight, web-based application designed to help users collect, organize, and track the places they want to visit. Users can add destinations, classify them as Dream, Planned, or Visited, and see their travel progress displayed on an interactive world map.
I chose this project for a one-day sprint because it combines several useful frontend challenges in one application: form handling, state management, filtering, sorting, local data storage, responsive design, and map-based data visualization. It was also a good test of a multi-AI workflow, where one AI prepared the product plan and another AI translated that plan into a working application.
2. The Stack
The Stack: HTML5, Vanilla CSS, and JavaScript.
The project was intentionally built without a framework, backend, database, or build tool. All of the HTML, styling, application logic, destination catalog, and map graphics are contained in a single index.html file. Browser localStorage is used to preserve the user's destinations after the page is refreshed.
The AI Assist: ChatGPT handled the initial brainstorming, product planning, feature list, data model, and technical handoff document. OpenAI Codex handled the implementation phase by reading the handoff document and converting it into a functional web application. Codex was also used to test the interface, improve the responsive layout, redesign the dashboard, and revise the world map based on visual references.
3. The One-Day Sprint
Morning (Hours 1-3): Planning and Scope
The project began with brainstorming ideas for a simple but meaningful travel application. We decided to create a personal bucket-list planner that would feel more like a travel magazine than a standard admin dashboard. ChatGPT was used to define the main user journey, destination data structure, map behavior, status system, filters, sorting options, and localStorage requirements.
The planning phase produced a detailed markdown handoff document. It described the layout, color palette, responsive behavior, destination card content, world-map pin logic, and the definition of done. The scope was kept frontend-only so that the application could run immediately without installation.
Afternoon (Hours 4-6): Coding and Core Features
The handoff document was passed to Codex, which created the initial single-file application. The core features were implemented first: adding destinations, search suggestions, Dream/Planned/Visited statuses, priority and budget fields, travel seasons, notes, ratings, visited dates, editing, deleting, filters, sorting, statistics, and persistent browser storage.
A built-in catalog of popular destinations was added so users could quickly search for locations and automatically obtain their continent, latitude, and longitude. These coordinates were then used to position colored pins on the world map. Sample-data and clear-data controls were also added to make the application easier to demonstrate and test.
The Finish Line (Hours 7-8): Map and UI Polish
The final stage focused heavily on visual quality. The first map was too abstract and did not look like the requested educational world map, so it was redesigned several times using the supplied reference images. The final version uses an oval atlas-style SVG with a blue ocean, cream land areas, geographic guide lines, continent labels, ocean labels, and interactive destination pins.
The original header also felt too large and unbalanced. It was redesigned into a cleaner editorial dashboard with a compact title area, a soft travel-inspired background, and smaller statistics tiles for Total, Dream, Planned, Visited, and Explored progress.
The final hours were used for browser testing on desktop and mobile screen sizes. Layout overflow, card stacking, map scaling, form usability, and JavaScript errors were checked before completing the project documentation.
4. The Roadblocks
The biggest roadblock was creating a convincing world map without using an external mapping library or online map service. The application needed to remain a single offline HTML file, which meant the map had to be drawn directly with inline SVG. Early versions looked too simplified and did not match the realistic atlas style shown in the reference images. Several visual revisions were required to improve the projection, land shapes, labels, colors, and overall presentation while keeping the destination pins functional.
Another challenge was translating a broad design description such as "travel magazine" into a professional interface. The first header used oversized typography and large statistic cards, which consumed too much space and made the application feel less polished. Additional feedback and design iterations were needed to create a more balanced dashboard.
The single-file requirement was useful for portability, but it also made the source code long and harder to organize. HTML, CSS, JavaScript, map paths, and the destination catalog all live in the same file. This works well for a small sprint project, but it would become difficult to maintain as the application grows.
5. Key Takeaways
**What worked the best?
**
The planning and feature-implementation workflow worked very well. The handoff document gave Codex a clear data model, function structure, user flow, and completion checklist. As a result, the main application features were implemented quickly, including localStorage persistence, destination management, status updates, filtering, sorting, statistics, and map pins.
**What worked the worst?
**
The visual requirements were the most difficult part of the AI handoff. Written design descriptions were not enough to produce the exact map and dashboard style expected on the first attempt. The interface improved significantly only after reference images and direct feedback were provided. This showed that visual work benefits from a short feedback loop and concrete examples.
My final thought:
If I had one more day, I would separate the application into dedicated HTML, CSS, and JavaScript files to improve maintainability. I would also integrate a real mapping library such as Leaflet with detailed geographic data, add destination photos, and provide import/export or cloud synchronization so a user's travel list could be accessed on multiple devices.
If I could redo the project, I would provide the visual references at the very beginning of the planning phase. The multi-AI workflow was effective for structure and functionality, but keeping design feedback, implementation, and testing in one continuous loop would reduce rework and produce a stronger first version.