How the Ripple feasibility engine works
Each line you paste becomes a stop. Ripple reads `drive=`, `visit=`, `opens=`, `closes=` and `tags=` values, falling back to 20 minutes of driving and 45 minutes on site when a line is bare. Party presets then stretch or compress those numbers — a family with young kids gets a rest stop every 110 minutes, a quiet 13:00–14:30 window, and a ten-minute boarding buffer per stop, while a solo traveller keeps long legs. Ripple exhaustively permutes small trips so the order that finishes earliest wins, then simulates the day minute by minute to catch a stop that closes before the visit ends, a plan that runs past the return time, a leg longer than the party allows, a sunset stop that misses golden hour, or an EV charge that cannot fit before the next leg.
Party composition, powertrain and slack settings
Feasibility is not a property of a route alone. Ripple models the travelling party — solo, two adults, a family with young kids, or mixed ages with limited mobility — plus a pace setting that scales every drive and dwell value. Powertrain matters too: an electric vehicle inserts charging segments when the remaining range no longer covers the next leg, which can push a comfortable day into a tight one. Set your departure time, the hard return-by time, and when usable daylight ends, and Ripple scores the plan against those three windows instead of pretending a day is infinitely long.
Reading the feasibility score and conflict log
The score starts at 100 and loses points for time-window overrun, blocked stops, dropped stops, and daylight overrun, so it always moves in a predictable direction when a constraint gets worse. Feasible means the plan lands inside every window with slack left. Tight means the plan fits but a small delay would break it — the HUD names exactly how many minutes of slack remain. At risk means at least one blocking conflict, and the conflict log tells you which stop closes too early or which window you blew past. Every conflict carries a repair suggestion: drop the last stop, leave earlier, shorten a visit, or insert a break.
One link, always the current revision
The Share Contract section encodes your itinerary text, party settings and revision counter into the URL, so sending the link sends the whole plan rather than a screenshot. Every edit bumps the revision, and the recipient re-runs the same deterministic engine, which means the shared plan matches your latest revision instead of freezing an old snapshot. Opening a malformed or unknown share link renders a real missing-plan state with a reset action instead of silently loading the first saved plan, so a broken link never looks like a valid itinerary.
Saved plans and notes stay in your browser
Ripple keeps saved plans and per-stop notes through its Axle adapter boundary. When no backend is running, the adapter writes to local storage on your device, so plans survive a reload and notes you delete stay deleted after a refetch. Nothing about your trip leaves the browser unless you press the share or download button yourself, and no account is required to use the tool.
Frequently Asked Questions
What counts as a time conflict in Ripple?
Ripple proves conflicts from the numbers you supply. A blocking conflict appears when a stop closes before its visit can finish, or when the whole plan runs past your return-by time. Soft conflicts cover a leg longer than the party allows, a day that ends after usable daylight, a sunset or photo stop that lands outside golden hour, an EV charge that cannot fit before the next leg, and a stop that overlaps a quiet window the party needs.
How does the feasibility score move when I change settings?
The score begins at 100 and loses points only for measurable problems: time-window overrun, each blocking conflict, each soft conflict, stops that never got scheduled, and daylight overrun. Switching to a relaxed pace or adding a young child stretches dwell times and inserts rest stops, which pushes the same route toward Tight or At risk — the same route can therefore score differently for different parties, which is the point.
Does the share link freeze my itinerary?
No. The link carries your itinerary text, party constraints and a revision counter, and it re-runs the same deterministic engine when opened. Keep editing and the revision increments, so the latest link always resolves to the latest plan. A malformed link shows a missing-plan error with a reset action rather than quietly loading an unrelated saved plan.
Can I use Ripple for a route with more than six stops?
Yes. Six stops or fewer get an exhaustive permutation search, which finds the best exact order. Above six, Ripple switches to a deterministic earliest-closing-first ordering so the tool still answers instantly on a phone. Both paths run the same minute-by-minute simulation, so the conflict log is equally strict.
Where do travel times and opening hours come from?
They come from what you type. Ripple does not call a maps or traffic API, so it makes no network requests and needs no credentials. That keeps the tool deterministic and fast, and it means you should verify drive times and closing hours before you actually drive.