Turn a Property Shortlist Into a Decision.
Acquire a property decision and visit application built around the requirements, the unknowns and the evidence behind a purchase. Rebrand it as your own product, or put the workflow inside a business you already run.
Real Estate · A proptech operator, a brokerage with technical capacity and lawful data access, or a technical founder.
- 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.
Real Estate showing three evaluated properties with their prices, Fit scores and open verification needs. Photographed from the application running against a seeded database. The packaged standalone Real Estate repository, running on synthetic property records. House photographs are stock images standing in for a field the application does not have. The house photographs are stock images. Real Estate has no property photo field today, and draws a placeholder in their place.
How it actually works.
State the requirements
Hard requirements and soft preferences are held apart from the start, because they are answered differently. A hard requirement is met or it is not; a preference contributes to a fit score.
Compare the properties that are actually eligible
A violated hard requirement makes a property ineligible however well it scores on everything else. A missing numeric attribute returns unknown rather than zero, so an absent fact never quietly reads as a bad one.
Take a visit brief made of what is unverified
Verification needs are derived from the fields the evaluator actually uses, plus a missing listing status or price. The brief is the list of things the record cannot answer yet.
Record a finding, and watch the evidence change
An observed finding is parsed, written back as a provenanced property value, and moves the refresh timestamp. This is the moment worth showing: the property's record is different after the visit than before it.
Three screens, in the order you meet them.
- Screen 1 of 3, showing
- Screen 2 of 3
- Screen 3 of 3
Fit and Confidence are two separate measurements, so a high Fit is never presented as a good outcome while a hard requirement goes unmet.
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.
Hard constraints evaluated separately from soft fit
A violated hard constraint makes a property ineligible regardless of its fit score. The two are never combined into one number.
A missing attribute returns unknown
Not zero, not a pass, not a neutral default that reads as a fact. Unknown is a state the interface shows.
Verification needs derived from real evaluator inputs
From the fields the evaluation actually uses, plus missing listing status and price — not from a fixed checklist.
A visit finding becomes a provenanced property value
Numeric fields are parsed before writing, the value carries where it came from, and the refresh timestamp moves with it.
A provider licensing gate that fails closed
It blocks the experimental Realfin provider in production and rejects any provider it does not recognise. A buyer standing up a public preview still needs a lawful data mode rather than relying on the production-only guard.
Side-by-side comparison, pursue and pass history, guided visits and attachments
Recorded in the repository's own listing pack alongside a property-question panel grounded in saved state. Demonstrate each from the running interface before treating it as verified; this review read the source, it did not run the application.
Requires Buyer Configuration
In the delivered code, but inert until the buyer supplies an account, a credential, or a deployment of their own.
Manual property entry, which is the lawful default
The application is designed to work with properties entered by hand. That is the mode a buyer can run on day one without any data agreement.
Hosting, a database and file storage
All buyer-owned. Live storage integration is recorded as unverified in the standalone repository.
Model provider credentials
For the property-question panel. Live model integration is recorded as unverified in the standalone repository.
Account recovery and email
The current configuration has no email verification and no transactional email configured, and the handoff records no password reset.
Client invitations and a cross-workspace dashboard
Neither exists. A brokerage deploying this to its own clients builds both.
Billing, if the buyer wants a subscription business
There is no billing or entitlement system. This is only a requirement for a buyer choosing that model; an internal decision tool does not need it.
Operational hardening
Rate limiting is per process. There is no general audit log, no load test and no penetration test on record.
Requires External Licence
Needs rights VoyantIQ does not hold and cannot transfer. The buyer licenses it themselves or does without it.
A licensed property listing feed
No MLS or listing-data rights are included, and none can be transferred. A buyer who wants live listing supply licenses it themselves, on their own terms, in their own market.
The experimental provider in the repository is not licensed supply
The Realfin RapidAPI adapter exists and is deliberately blocked in production by the licensing gate. It is an integration shape, not a data right, and it is never marketed as one.
Not Included
Not in the delivered version. Listed here so it is read before the purchase rather than discovered after it.
Independently verified property facts
Confidence measures how recently a property record was refreshed. Nothing in the application corroborates a listing against an external source.
A listing marketplace
This evaluates a shortlist. It does not list properties for sale, match buyers to agents, or carry inventory.
Property photography
There is no property photo field. Any house image on this site is a stock photograph standing in for one.
The VoyantIQ company, brand, platform or accounts
Not the parent brand, the shared platform, provider contracts, domains, trademarks, hosting accounts, credentials or any user data.
What this page does not claim.
Each of these is a sentence a page like this could easily say about Real Estate, and the reason it would be wrong.
Confidence measures freshness, not verification
It reads the age of the last refresh. It does not corroborate a listing fact against any external source, and must never be presented as accuracy, reliability or verification.
A fit score with no preferences set is not a personal match
Unknown soft constraints contribute neutrally, and a property with no soft constraints at all returns a flat middle score. The interface explains an unset preference state before showing that number as if it meant something about this buyer.
Comparing properties is not a novel capability
RealScout already markets branded collaborative home search, side-by-side comparison, client portals and team workflows. What is specific here is the chain from a missing fact to a visit objective to a revised property record, and that chain has not been established as globally unique either.
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
Property evaluation and visit intelligence engine
PostgreSQL schema and migrations
Listing provider adapter behind a replaceable interface
Architecture and decision documentation
What you can look at first
Synthetic properties evaluated against stated requirements, with eligibility, fit and freshness reported separately and the unknowns left visibly unknown.
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.
- 136 unit tests recorded as passing.
- Six browser tests across two viewport projects.
- A clean-clone transfer check.
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 — 16 tables, 136 passing — 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.
Real Estate is available.
A request starts a conversation. It is not a reservation, it holds nothing, and it commits neither of us to anything.