A Family Trip, With Everyone's Constraints in View.
Acquire a family travel planning application with traveller profiles, constraint-based recommendations, explainable tradeoffs and a documented handover. Build the customer experience and the business around it.
Family Travel · A travel-product founder, or an existing agency or operator with technical capacity.
- Asking price
- Price on Request
- One-time acquisition.
- Availability
- Available
- No acquisition has been agreed, and none is in progress.
This is an application asking price. It is not a valuation of a business: there is no revenue, no customer base and no trading history behind it, and none is implied by the figure.
Family Travel showing seven planned trips with their traveler counts and readiness states. Photographed from the application running against a seeded database. The packaged standalone Family Travel repository. Prices in the scenario are simulated and are not retrieved from a live provider.
How it actually works.
Describe the household, not the trip
Each traveller carries their own confirmed preferences and constraints. A preference that was never confirmed is held as unconfirmed rather than assumed, and that distinction survives into the scoring.
Evaluate the whole trip together
Flights, lodging, ground transport and activities are evaluated against the budget, the dates and every traveller at once. Feasibility, fit, friction and confidence stay four separate measurements throughout.
See who the tradeoff costs
Family Fit is the minimum individual score, never the average, so one traveller's bad trip cannot hide behind everyone else's good one. A traveller with no confirmed preferences is shown as insufficient profile information rather than as a match.
Change the budget and watch the package rebuild
A supported budget change re-evaluates the package and writes a real decision record. The planning commands shown are only the ones that actually execute.
Three screens, in the order you meet them.
- Screen 1 of 3, showing
- Screen 2 of 3
- Screen 3 of 3
Every trip carries its own readiness state, so the one that needs attention is visible without opening it.
What you are actually buying, in four states.
No readiness percentages. A capability either runs in the version being sold, waits on something you supply, waits on rights we do not hold, or is not there at all.
Demonstrated in This Version
Present and working in the packaged repository this sale delivers, confirmed against its source.
Family Fit is the minimum, never the average
The overall score is the lowest individual score in the household. Averaging would let one person's unmet constraint disappear into everyone else's satisfaction.
Individual matches are built from confirmed preferences only
From confirmed preference keys and positive recommendation factors. An unconfirmed preference does not quietly become evidence.
Feasibility, fit, friction and confidence stay separate
Through candidate ranking and whole-package evaluation alike. Confidence answers how good the evidence is, never how good the option is.
Real budget, date, destination, transport and decision transitions
These planning commands execute. Eight further declared command types are recorded in the handoff as unreachable, including manual constraint mutation, traveller mutation and undo or restore, and the interface must not demonstrate them.
Replaceable provider adapters with deterministic fixtures
Flight and lodging search, rental vehicles, activities, electric vehicle charging and routing, each behind an interface, each with a fixture path. An adapter existing is not evidence that the buyer has live supply, rights or a configured account.
Export and a booking handoff that preserves state
Selections, required ordering and verification state are preserved for a handoff. Nothing is booked and nothing is paid for.
Requires Buyer Configuration
In the delivered code, but inert until the buyer supplies an account, a credential, or a deployment of their own.
Hosting and a database
The standalone repository has no recorded hosted deployment, load test or penetration test. A buyer-owned deployment is the first piece of work.
Model provider credentials, and the running cost of using them
The model router is provider-agnostic and degrades to a deterministic parser with nothing configured. A production experience needs real keys and a real budget for them.
A live price path, verified
Provider failures fall back to fixtures and a fresh install uses simulated prices. Any retrieved price needs its own verification before a customer sees it as real.
Operational hardening
Rate limits are per process. Dependency audit findings in the pack are historical and should be rescanned rather than repeated as current facts.
Requires External Licence
Needs rights VoyantIQ does not hold and cannot transfer. The buyer licenses it themselves or does without it.
Live travel inventory and the right to sell it
Supplier agreements, inventory access, content rights and the commercial terms behind them are all the buyer's to negotiate. None of it is held by VoyantIQ and none of it transfers.
Not Included
Not in the delivered version. Listed here so it is read before the purchase rather than discovered after it.
Booking
Nothing in the application reserves, holds or confirms anything with a supplier.
Payment
No payment capability and no merchant-of-record behaviour. The application plans, decides and hands off.
Live inventory or supplier relationships
The adapters describe the shape of an integration. They do not carry an account, a contract or a rate.
Customers
There is no customer base, no revenue and no retention history.
The VoyantIQ company, brand, platform or accounts
Not the parent brand, the shared platform, provider contracts, domains, trademarks, hosting accounts, credentials or any traveller data.
What this page does not claim.
Each of these is a sentence a page like this could easily say about Family Travel, and the reason it would be wrong.
A score of 100 can mean we know nothing about that traveller
A traveller with no confirmed preferences receives a numeric 100 with its preference-data flag false. Every surface that shows a per-person score reads that flag first and shows insufficient profile information instead. It is not a perfect match and it is not a satisfaction prediction.
Prices in any demonstration are simulated
Labelled beside the amount, not in a footer. A fresh install uses simulated prices and a provider failure falls back to a fixture.
Conversational trip planning is not a distinctive capability
Mindtrip already markets conversational planning, personalised recommendations, collaborative trips and booking-backed functionality; Wanderlog gives collaborative planning away free. What is specific here is inspectable constraint handling and explicit per-person tradeoffs in an application somebody can own.
The recorded test run is 479 passing plus one skipped
The skipped one is a live routing test. This site previously said 480, which rounded a skipped test into a passing one.
What you receive
Built on Next.js, TypeScript, PostgreSQL, Drizzle ORM. A transfer check runs against a clean clone before any of it changes hands.
Full application source, commit history included
Trip intelligence, evaluation and explainability engine
PostgreSQL schema and migrations
Replaceable model router across local and hosted providers
Architecture and decision documentation
What you can look at first
A seeded household trip: per-person constraints, an explained recommendation, and a tradeoff that costs one traveller something. Amounts shown are simulated.
A deployed, standalone preview of the packaged application is not published. One is arranged during diligence, against the actual sale commit, rather than kept running here. A reasoning scenario and a deployed preview are different things, and naming both is better than letting one stand in for the other.
The recorded transfer evidence, dated.
Recorded 24 to 25 October 2026.
- 479 unit tests recorded as passing, plus one skipped live routing test.
- 19 browser tests, exercising some real PostgreSQL paths.
- 47 tables in the shipped schema.
- No recorded hosted deployment, load test or penetration test.
These are the repository's own recorded results from that date, not a fresh verification. The transfer process is re-run against the actual sale commit before any handover, and the current results are what the acquisition agreement refers to.
The schema and test counts shown elsewhere on this site — 47 tables, 479 passing, 1 skipped — were measured on 30 October 2026. A skipped test is never counted as a passing one.
None of this establishes product quality, demand or revenue, and the pack itself says so. It establishes that the application builds, migrates and passes its own tests from a clean clone.
Family Travel is available.
A request starts a conversation. It is not a reservation, it holds nothing, and it commits neither of us to anything.