Questions people ask first.

Grouped by what is actually worrying you: what you would own, whether it works, how it reaches you, and what happens once it has. Including the questions with uncomfortable answers, because anybody spending this much recognises a page that only has comfortable ones.

Ownership and price

What does the published price buy?: A one-time acquisition of one application: Mission Control at Price on Request, Real Estate at Price on Request, Family Travel at Price on Request, Teams at Price on Request. These are application asking prices, not valuations of revenue-generating businesses. There is no revenue, no customer base and no trading history behind any of them, and the figures are not derived from one.
How does an offer actually work?: The asking price is published so you can decide whether to start a conversation without asking for a number. You send a request, read the evidence pack and the written transfer scope, and then terms are agreed — including the price. A request is not an offer and an offer is not an agreement. The process is set out step by step.
Who can acquire one?: Anybody who intends to take it to a market and has, or can hire, the engineering capacity to deploy and run it. These are not plug-and-play businesses. The clearest buyers are a technical founder, an operator in the relevant industry, a company adding a capability, or a studio with an engineering owner.
What stops you selling the same application to somebody else?: Each application is sold once. After an acquisition completes it comes off the purchasable catalogue and the listing becomes a record rather than an offer. What exclusivity covers beyond that — specifically whether it restricts VoyantIQ's own related implementations — is written into the agreement, because those are two different promises and only one of them is implied by the word.
Do you retain anything?: For Mission Control, yes, and it is named rather than buried: a separately evolved Mission Control implementation stays in the VoyantIQ platform repository. What transfers is the packaged standalone repository and its application-specific assets. Across all four, shared code ancestry needs a precise rights schedule in the agreement — technical independence is a fact about how the code runs, not a statement about who owns every generic file in it. The Mission Control page states this beside its price.
What is definitely not included?: The VoyantIQ company, the parent brand, the shared intelligence platform, provider contracts, domains, trademarks, customer records and user data. None of those transfers unless that Asset's written scope specifically includes it, and none of them does today.

Technical readiness

Is it finished, or is it a prototype?: Each one runs against a real database, and the screenshots here are photographs of that. Finished means the workflow it claims is in the delivered version and the application can be handed over. It does not mean it is ready to sell to the public on day one. Every detail page says which is which in four states — Demonstrated in This Version, Requires Buyer Configuration, Requires External Licence and Not Included — and all four are linked here.
Why are there no readiness percentages anywhere?: Because a percentage is the easiest number on a page like this to produce and the one you can least check. The four states replace it. 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.
Can I see one running before I commit to anything?: Two different things exist and they are not the same, which this page used to get wrong by describing only one of them. A reasoning scenario is a seeded walkthrough on this site that shows how an application decides; one exists for every application. Mission Control: A seeded sample company: connected-application evidence, a service inventory with recorded costs, and an attention item traced back to what raised it. Real Estate: Synthetic properties evaluated against stated requirements, with eligibility, fit and freshness reported separately and the unknowns left visibly unknown. Family Travel: A seeded household trip: per-person constraints, an explained recommendation, and a tradeoff that costs one traveller something. Amounts shown are simulated. Teams: A seeded group event: travelling households against a roster, hotel quotes compared on total known cost, and the missing components named rather than estimated. Venue distances shown are straight-line. A standalone preview is the packaged application itself, deployed and signed into. None is published for any of the four today; one is arranged during diligence against the actual sale commit. A scenario proves the workflow exists. It does not prove a live integration or a deployed environment.
What do the test and table counts actually prove?: That the application builds, migrates from empty and passes its own suite from a clean clone on a recorded date. They are diligence evidence, not the commercial benefit and not proof of quality or demand. Every count on this site carries its date, and a skipped test is counted separately rather than folded into the passing total — Family Travel's recorded run is 479 passing plus one skipped live routing test, which this site previously rounded to 480.
Can I see what is wrong with it before I commit?: Yes, and you should. Every application ships with a licence inventory for each dependency, a software bill of materials, a secret scan over its full history and its open dependency advisories, plus a known limits document. The known limits are summarised on each detail page rather than held back for diligence, because discovering them afterwards is how a deal falls apart late.
Are the scans and advisories current?: No. The recorded results on each page are dated, and dated results are historical by definition. The transfer process is re-run against the actual sale commit before any handover, and those results are what the agreement refers to.

Transfer

What exactly transfers?: The repository with its commit history, the PostgreSQL schema and its migrations, the deployment configuration, the environment reference, the handoff documentation and the evidence artifacts that exist for that application. Not a zip of the current state.
Is sending a request the same as reserving it?: No. A request records your interest and starts a conversation. It does not take the application off the market and it does not put you ahead of anybody. Where an application is marked Under Offer, a request sent then is recorded as a backup inquiry and labelled as one — on the form, in the confirmation and in our own record.
Is paying the same as receiving it?: No, and the site keeps the two apart deliberately. A recorded payment is one event; the transfer is a separate one. The application is not yours to run until the repository is in your hands and it comes up from a clean clone on a database you provisioned.
Do I need a VoyantIQ account to ask?: No. The request form takes your name, your email, what you would do with it and who would set it up. Acquiring an application has nothing to do with having a VoyantIQ travel account, and we do not make you create one to ask a question.
Who pays for the third-party services it needs?: You do, on your own accounts. Every integration needs the buyer's own credentials, subscriptions and any applicable data or commercial licences. Each detail page names them under Requires Buyer Configuration and Requires External Licence before you ask, not after.
Are the contract documents ready?: No. The licence and intellectual property terms are not finished and no counsel has approved anything. Nothing on this site is a reviewed or approved contract position. It is the slowest part of any acquisition today and we would rather you knew that first.

After the sale

What support comes with it?: A bounded transition, proposed as up to two one-hour handover sessions within thirty calendar days of delivery, plus thirty calendar days to report reproducible defects against the agreed delivered version. A defect reported inside that window stays covered until it is resolved under the agreed process — day thirty closes the reporting window, not an accepted defect. The included and excluded list is here.
What is outside the handover?: New features, changes you make yourself, ongoing operation and hosting, third-party changes after delivery, and continuing dependency maintenance. No indefinite general support and no updates are implied by an acquisition. A continuing relationship is possible and is a separate agreement.
Do I depend on you to keep it running?: No. There is no licence server, no call home and no hosted VoyantIQ component you cannot replace. You run it on your own database and your own hosting. The handover is not complete until the application comes up from a clean clone on an empty database with nothing from our machines involved.
Who is responsible for it after the transfer?: You are. Security patching, dependency maintenance, uptime, data protection obligations, the terms you offer your own customers, and everything the application does in your hands. The acquisition transfers the application and the responsibility for it together.
Can I talk to somebody who has acquired one?: Not yet. None has been sold. We would rather say that than point you at a testimonial from somebody who was given one.

Ask something else See the four applications How an acquisition works