Custom Agents. Not finding the agent you need? Have one built for your business, and it is not finished until it passes the cases you wrote.

Assets

How acquiring an application works.

Buying software outright is an unusual transaction, and what stops most people is not the price but not knowing what the steps are. These are the steps, including the slow ones and the unfinished ones.

  1. You inspect the application

    The detail page says what the delivered version demonstrates, what you configure, what needs a licence we do not hold, and what is simply not there. Where a demonstration exists it is linked, and it names the version it represents.

  2. You request the acquisition

    A short form: who you are, what you would do with it, and who would set it up. It is a request for a conversation. It is not a reservation, it holds nothing, and it commits neither of us to anything.

  3. We send the current evidence and the transfer scope

    The evidence pack with its commit and its verification date, the known limits, the dependency position, and a written scope of exactly what transfers and what VoyantIQ retains. You read all of it before money is discussed, not after.

  4. We agree terms

    The asking price is published; an acquisition still ends in an agreement that names the delivered version, the acceptance process, the remedy for an unresolved defect, and the exact scope of exclusivity. Nothing here has been approved by counsel, and contract drafts are not finished.

  5. You pay, and then the application is transferred

    These are two events, not one. Payment being recorded is not the transfer, and the transfer is not complete until the repository, schema, migrations, configuration and documentation are in your hands and the application comes up from a clean clone on a database you provisioned.

  6. A bounded handover, and then it is yours

    Up to two one-hour sessions within thirty calendar days of delivery, and thirty calendar days to report reproducible defects against the agreed delivered version. After that the relationship ends unless you want a separate one.

Four things that are easy to run together.

Each of these is a pair a reader could reasonably treat as one thing, where doing so would leave them believing something untrue about what has happened or what we owe them.

  • An inquiry is not a reservation

    Sending a request records your interest and starts a conversation. It does not take the application off the market, it does not put you ahead of anybody, and an application marked Under Offer stays available to other buyers while that discussion runs.

  • Payment is not completed transfer

    A recorded payment is one event. The transfer is a separate one, and the application is not yours to run until the repository is in your hands and it starts from a clean clone on your own database.

  • A demonstration is not launch readiness

    A seeded demonstration proves the workflow exists. It does not prove a live integration, a deployed environment, or that a non-technical operator could launch a business on it next week.

  • Technical independence is not a rights schedule

    Each application runs with no VoyantIQ service behind it. That is an architectural fact. What you may do with shared-origin code, and what VoyantIQ retains, is a separate written schedule in the agreement.

The transition has an end date in it.

This is the proposed included transition. It is deliberately bounded: an acquisition that came with indefinite support would be a service relationship wearing a one-time price, and neither of us would have agreed to the same thing.

Included

  • Up to two one-hour handover sessions, within thirty calendar days of delivery.
  • Thirty calendar days from delivery to report reproducible defects against the agreed delivered version and acceptance scope.
  • A defect reported inside those thirty days stays covered until it is resolved under the agreed acceptance and remedy process. Day thirty closes the reporting window, not an accepted defect.

Outside it

  • New features, and changes you make yourself.
  • Ongoing operation, hosting, monitoring or on-call.
  • Third-party changes after delivery, and continuing dependency maintenance.
  • Indefinite general support, and updates. Neither is implied by an acquisition.

The acquisition agreement is what defines the acceptance and remedy process and what happens to a defect that is not resolved. Those are terms to agree, not terms this page has already settled.

What transfers, and what does not.

Transfers

  • The application-specific source

    The repository with its commit history, the PostgreSQL schema and migrations, the deployment configuration, the documentation, and the handover and evidence artifacts that actually exist for that application.

  • The application-specific intellectual property

    The assets VoyantIQ genuinely owns for that application and has agreed in writing to transfer. The agreement names them; this page does not pretend to.

  • Independent operation

    Each packaged application runs with no required VoyantIQ service behind it. That is an architectural finding about the code, not evidence of a buyer-owned deployment and not a commercial launch-readiness claim.

Does not transfer

  • The VoyantIQ company, brand and platform

    Not the parent brand, the shared intelligence platform, domains, trademarks, customer records or user data. None of it is included unless that Asset's written transfer scope says so.

  • Provider contracts and accounts

    Every third-party integration needs the buyer's own accounts, credentials, subscriptions and applicable data or commercial licences. Each application's page names the ones it needs before you ask about it, not after.

  • Rights that have not been settled in writing

    Shared code ancestry still needs a precise rights schedule. For Mission Control specifically, VoyantIQ retains a separately evolved implementation in its platform repository, and whether exclusivity restricts that implementation or only means this Asset will not be sold again is agreed before completion rather than assumed.

One application, one buyer.

Each application is sold once. Every listing carries its real state, and those states mean exactly what they say.

  • Available

    No acquisition has been agreed and none is in progress. A request starts a conversation.

  • Under Offer

    A buyer is in discussion. The application is not reserved by that discussion. A request made now is recorded as a backup inquiry, labelled as one on the form, in the confirmation and in the record we keep.

  • Acquired

    The application has been acquired. No further acquisition is accepted, the request form is removed rather than disabled, and no payment can be started. The listing stays up as a record of what was sold.

What is still being worked out, said plainly.

The licence and intellectual property terms are not finished and no counsel has approved anything. Nothing on this site should be read as a reviewed or approved contract position, and no acquisition document exists in final form today. If that matters to your timeline, say so in your first message rather than discovering it three weeks in.

No application has been sold yet, so there is no completed transfer to point at and nobody to put you in touch with. We would rather write that down than offer a reference from somebody who was given one.