Should I vibe code
Build a collaborative itinerary from user-entered places, notes, and reservations
A shared itinerary is a list with dates and a map pin. Pleasant weekend, real payoff.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Collaborative trip planning is small and the offline case is the only genuinely tricky part. Nice project, low stakes, immediately useful.
What actually breaks
not "if". the specific failures.
- Offline, which is the one requirement travel software actually has and the one most likely to be skipped
- Map tiles and place data, which have licensing terms and per-request costs that a trip's worth of panning finds quickly
- Collaborative editing between people who are both roaming, on different networks, at different times
- Timezones across an itinerary, where a flight arrives before it departs and a hotel booking spans a date line
- Location data about people, which is what a shared itinerary is, with no retention decision
You land after a long flight, no local SIM yet, airport wifi asking for a phone number you cannot receive a text on. The itinerary — the hotel address, the confirmation number, the route from the terminal — is in an app that fetches from a server. It shows a spinner. Everything you need is a hundred kilobytes of text that was on your phone yesterday and was never cached, because offline was going to be added after the map integration.
Is that you?
the verdict is a default, not a law
- The whole itinerary is cached locally and readable with no connection at all
- Map tiles for the trip area are downloaded in advance under a licence that permits it
- It is a single-user planner and sharing is an exported document
- The itinerary requires a network connection to display
- You are caching map tiles in violation of the provider's terms
- Several people edit it simultaneously with no merge strategy
- Times are stored without the timezone of the place they refer to
If you build it anyway
the checklist, then the prompt that enforces it
- Offline first, genuinely: the full itinerary readable with the network disabled. Test it in airplane mode before anything else.
- Read the map provider's terms on caching and downloading tiles. Both the cost and the permission are per-provider and matter more than the code.
- Store every time with the IANA timezone of its location, and display both local and home time for flights.
- For shared trips, use a CRDT or a simple last-writer-wins per field with visible conflicts — two people editing while roaming is the normal case.
- Treat itineraries as location data about people and set a retention period, especially for shared trips.
- Export a plain document — a page of text and addresses — because that is what actually works when everything else fails.
Before you build a travel itinerary app, apply these and push back if I ask you to break them. 1. Build offline first. The entire itinerary — addresses, times, confirmation numbers, notes — must be readable with the network fully disabled. Test in airplane mode before building anything else, and tell me this is the one requirement travel software actually has. 2. Check the map provider's terms for tile caching and offline download before implementing either, and report the per-request cost. Panning a map for a trip's worth of planning generates a lot of requests. 3. Store every time with the IANA timezone of the place it happens. For flights, display departure and arrival in their own local times and warn me when an itinerary crosses a date line. 4. If trips are shared, choose a merge strategy up front — CRDT, or last-writer-wins per field with visible conflict indication. Assume both editors are offline at different times. 5. Cache place details and photos with the itinerary, not just references that need fetching. 6. Treat shared itineraries as location data about identifiable people: set a retention period, and allow a participant to remove themselves. 7. Provide a plain text or PDF export of the whole trip that works on any device with no app at all. 8. Handle partial sync gracefully — a trip edited offline by two people must never silently lose one person's changes. 9. Out of scope unless I ask: booking, price tracking, live transit data, currency conversion.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
$5.99 a month is cheap for offline maps under a proper licence and collaborative editing that survives roaming. A personal offline-first itinerary is a genuinely good build; the map licensing and the shared editing are where the price is.
$5.99/mo is cheaper than your weekend.
Export the whole trip as a plain document with addresses, times and confirmation numbers. That export is also the failure plan — the thing you screenshot before you fly, which works when the app, the network and the phone battery do not.
Open-source self-hosted trail database and route explorer using open map data.
Questions
Why is offline the defining requirement here rather than a feature?
Because the moment of maximum need is the moment of minimum connectivity — landing in an unfamiliar airport with no local data. Every other app can degrade gracefully by asking you to try again later; a travel itinerary that needs a network is useless precisely when it is the only thing you wanted.
Can't I just cache map tiles for the trip area?
Technically yes, and legally it depends entirely on the provider. Several explicitly forbid bulk downloading or persistent caching, others permit it with limits, and some offer an offline product separately. It is a licence question to answer before writing the code, not a technical one to solve afterwards.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice