palantir-for-family-trips: a React command center for getting three families to one cabin

A trip planner that dresses up as an operations room

The repository describes itself with a self aware subtitle: a Palantir-ish dashboard for a very non-Palantir problem, namely getting a few families to Pine Mountain Lake and Yosemite without losing the plot. That framing is the point, and it is repeated near the end of the documentation, where the project calls itself a fun UI experiment, a trip planning toy, and a mildly absurd attempt to make a family weekend feel like a live operations room.

What it actually does is narrower and more concrete. It tracks multiple families arriving from different cities, simulates driving routes and convoy departures with day by day timeline playback, and organises the trip into itinerary, stay, meals, activities, expenses and family views. The screenshots in the docs directory show a mission launch overlay, an activity planning surface and a meal logistics surface, and the interface is deliberately dense, dramatic and slightly over the top.

The design decision that defines the project is that a family weekend is treated as an operation. Arrival windows, convoy departures and mission launches are the vocabulary, and the map is the centre of the screen rather than an appendix. Whether that framing helps or gets in the way is a matter of taste, and the project is honest that the density is a choice rather than a requirement.

Three commands to get the dashboard running

The local setup is a normal Vite project, and the documented steps are three lines. Installing dependencies, copying the environment template, and starting the dev server:

npm install
cp .env.example .env
npm run dev

The output is a Vite dev server, which the documentation says to open at `http://127.0.0.1:5173` or whatever Vite prints. The `package.json` confirms the shape of the project: it is an ES module named `palantir-for-family-trips` at version 1.0.0, with `dev`, `build` and `preview` scripts and a Vite 8 toolchain. A `postcss.config.js`, `vite.config.js` and `index.html` sit alongside `src/`, and the dependency list is React 19, Framer Motion, Lucide icons, `clsx`, `tailwind-merge` and the Google Maps JS API loader, with Tailwind 4 in the dev dependencies.

The `cp .env.example .env` step is not optional ceremony. The environment file is the only place the Maps key goes, so skipping it means running the app with no map layer at all.

The Maps key and what the app looks like without it

For the full map experience, the documentation asks you to add a browser Maps key to `.env`:

VITE_GOOGLE_MAPS_API_KEY=your_browser_maps_key_here

There is also an optional custom styled map identifier:

VITE_GOOGLE_MAP_ID=your_optional_google_map_id

The repository's `.env.example` carries the same two variables, with the second one commented out as optional. The failure mode is documented rather than hidden: without a key, the app still renders its UI, but the live Google map layer will not fully initialize. That is a reasonable degradation for a demo, since the timeline, meal planning and activity surfaces do not depend on the map, but it does mean an evaluation of this project has to include a key or it will be looking at a reduced version of the thing.

The billing side is stated too. If you publish the app with your own Google Maps key, usage is billed to your Google Cloud project. Combined with the browser key requirement, the practical reading is that this is a key you keep local, in `.env`, for your own use, rather than something you deploy as a public site on a shared key.

The seeded trip document is the actual content

The most important file for a new user is `src/tripModel.js`, which the documentation points at for the seeded trip document and helper logic. Everything the dashboard shows, the families, the routes, the meals, the activities and the expenses, comes from that seed. This is a template with sample content, not a database, and the project says so plainly.

Two other files matter for hacking on it. `src/App.jsx` holds the main shell, the timeline and the overlays, and `src/CommandMap.jsx` holds route rendering, playback and map behaviour. That split is a sensible one: the map logic is isolated from the shell, so a change to the timeline or the mission launch overlay does not have to go near the map code.

The repository also ships `CLAUDE.md` and `DESIGN.md` alongside the `docs/` directory with the screenshots. Those two files are the ones to read after the README, because they are where the design reasoning and the working agreements for the project are most likely to be recorded, and the README itself is a tour rather than a specification.

State in the browser means state in one browser

The project states plainly that state is stored locally in the browser, and it is optimised for desktop and large screen dashboard use. Put those two facts together and the constraint becomes clear: this is a single screen running on one machine, not a collaborative service. A family member on another laptop does not see the same state unless somebody exports and reimports it, and the documentation does not describe a sync mechanism, a backend, an account system or any persistence beyond the browser.

That is not a defect for the stated use case. A command centre that lives on one big display in one house is exactly what the project set out to build. It does mean the failure mode to plan for is a refresh or a cleared browser cache losing the trip you had edited, and the data privacy note reinforces the picture: the trip data is intentionally sanitized for public sharing, with family names as demo names, a generalized basecamp address, and access instructions, Wi-Fi, host details and other private trip notes removed.

For the same reason, the seed document is a starting point to edit rather than a template to ship. If you take this code further than a weekend, replacing the seeded trip with your own data is the first task, and deciding where that data lives is the second.

A toy next to a spreadsheet, and a plain itinerary app

The realistic alternatives are the two obvious ones. A shared spreadsheet solves the coordination problem for the small case, with the advantage that several people can edit it and that it needs no installation. The cost is that it does not do the things this project is for: no map, no timeline playback, no convoy route simulation, and no sense of where the whole weekend stands at a glance.

A conventional trip planner or booking tool is the other comparison, and it goes the other way. It is a hosted product that stores data on someone else's server, supports multiple travellers, and can hand you a bookable itinerary. It will not give you a dark operations dashboard, a mission launch overlay, or the ability to fork the code and change how the timeline plays back.

The difference in approach is ownership and scale. This project gives you a local React application, a seed document you edit, and a map key you supply, with no account, no server and no vendor. The trade is that none of the coordination conveniences of a hosted product come with it. The project's own status line is the fairest summary of where it sits: built for fun, surprisingly usable, and explicitly not pretending to be enterprise software.

Editorial conclusion

Adopt this project if you want a single shared screen that makes a family weekend legible, you are willing to run a local Vite dev server, and you are comfortable supplying your own browser Google Maps key, because without that key the live map layer does not fully initialize. Do not adopt it as a booking or itinerary system, since there is no backend, state is stored locally in the browser and the trip data is a sanitized seed document, so two people editing it at once will not see each other's changes. Verify first that your `.env` holds a valid `VITE_GOOGLE_MAPS_API_KEY`, that the sanitized seed data in `src/tripModel.js` is replaced with your own trip, and that the last push on 2026-04-13 still matches the React and Vite versions you intend to run.

Frequently asked questions

Official sources

1. andrewjiang/palantir-for-family-trips on GitHub
2. Issues
3. License: MIT
4. README