Product. Status as of September 2026
HomeBid originates plots from a housebuilder's ERP, qualifies and verifies every bidder, gates acceptance so that no unverified buyer can be accepted, and hands a schema-validated digital twin to whoever completes the transaction. Everything after acceptance belongs to the panel firm or a settlement rail.
What we do
Our package is an accelerant for the receiving firm's due diligence, not a substitute; they re-verify under their own obligations. Completion mechanics we have coded are parked as optionality, outside the pitch and the numbers.
Platform status
Five labels, used consistently across every investor document: production, pilot, staging, coded, parked. Counts of models, routes and pages are not evidence and are not used.
| Status | Capability | Note |
|---|---|---|
| Production | Listing, bid management and the 100-point qualification score, served server-side | Sell and bid spine hardened June 2026; 30 suites, 882 tests passing |
| Production | Fail-closed acceptance gate: identity, source of funds, source of wealth, PEP and sanctions | No reservation is accepted without all four; the buyer sees why |
| Production | PDTF v3.5.0-subset handoff package at acceptance, JSON and PDF | Schema-validated on generation; OPDA Property Data Trust Framework |
| Production | Buyer, developer and conveyancer journeys; messaging, notifications, internal e-signature | Role-based access across the parties to a reservation |
| Pilot | Pilot-customer environment on the hardened build | Gated demo running the customer's own developments; live late October 2026 |
| Staging | UK and EU resident staging, error monitoring, credential rotation | In progress ahead of the pilot |
| Coded | COINS connector: plots and sales originated from the housebuilder's ERP | Awaiting live client credentials; not used in the first pilot |
| Coded | HMLR Business Gateway title data | Test environment today; live official copies are a funded milestone |
| Coded | Lender decision-in-principle and broker rail | Switched off pending FCA perimeter advice; no revenue in the Base case |
| Coded | Open-banking balance verification (Plaid) | Wired; pairs with explicit source of funds and wealth capture |
| Parked | Phase 2 completion mechanics: conveyancing workflow, deed execution, chain visibility, card payments in the acceptance path | Retained as optionality; not in the pitch, not in the numbers |
Architecture
Stack
A Node.js and Express application with PostgreSQL behind Sequelize, Redis for caching and rate limiting, and a React and TypeScript front end. Real-time updates over Socket.io; branded PDFs generated server-side from templates; email, SMS and in-app messaging; an internal e-signature flow; Winston logging.
Security
JSON Web Token authentication with bcrypt hashing and role-based access across buyer, developer, conveyancer, surveyor, agent and administrator roles. Helmet headers, rate limiting, input sanitisation and CORS on every endpoint. Every acceptance, verification result and document generation is written to an audit trail. Pilot environments sit behind Cloudflare Access.
Testing
The sell and bid spine was hardened in June 2026 to a fixed acceptance list: 30 test suites and 882 tests pass on every change. Integration with third-party services is instrumented in the pilot rather than assumed.
The score
Computed from verified inputs (identity, bank-sourced balances, source of funds and wealth evidence, screening results) and declared inputs (chain position, timing, financing), labelled separately in the interface so a developer never mistakes a claim for a fact. Designed and documented as an AML risk score, which is the framing the regulations require.
The gate
A developer cannot accept a reservation unless the bidder has passed identity verification, has captured source of funds and source of wealth, and has cleared PEP and sanctions screening. Screening runs automatically on submission and blocks on a hit, with the reason recorded; a daily refresh keeps it current while the reservation is live.
Suppliers
Identity verification through Veriff. Open-banking balance verification through Plaid. PEP and sanctions screening with daily refresh. Title data through the HMLR Business Gateway, in test today. Each supplier sits behind a service interface; none of them is the product.
The digital twin
At acceptance HomeBid generates a digital twin of the property and the parties: a JSON package conformant to a subset of the Open Property Data Association's Property Data Trust Framework, version 3.5.0, validated against the schema on generation, with a PDF rendering for firms that want to read it. It carries the property and plot data originated from the developer, the sales terms, the buyer's verified identity and verification status, the source of funds and wealth evidence, the screening results and the acceptance record with timestamps.
The package is delivered to the buyer's chosen firm and the developer's panel firm, and can be delivered to a settlement rail. It is an accelerant for their customer due diligence, not a substitute for it: the receiving firm re-verifies under its own obligations, and HomeBid never represents otherwise. The pilot measures whether firms actually use it, on at least four deals in five, before any downstream fee is charged.
The twin is deliberately not proprietary. A government data mandate or a rail adopting the same schema increases the value of having the data at reservation rather than commoditising HomeBid's position, because the moat is the qualification gate and the origination from the housebuilder's ERP, not the file format.
The COINS connector and data handling
COINS is the ERP used by the majority of the UK's top housebuilders. HomeBid's connector originates plots, prices and reservation events from the developer's own COINS environment so that the sales team never double-keys and the platform's data starts from the system of record. The connector is coded and integration-tested against the vendor's interface; it awaits live client credentials and is not used in the first pilot, where plots are loaded directly. Origination through COINS is one of the two assumptions the pilot exists to validate.
Personal data is processed under UK GDPR on a documented lawful basis, with retention aligned to the anti-money-laundering record-keeping requirements that apply to verification evidence. Buyers see and control what has been captured about them. Hosting is being moved to UK and EU resident infrastructure ahead of the pilot. No sensitive data appears in logs; verification evidence is stored encrypted and access is recorded.
These are design targets, not claims, and are reported with the baseline once the pilot has data.
Funded by the raise
A live walkthrough of the hardened platform on the pilot customer's developments, with the founder.