PropertyMetrics is designed to make a property research case inspectable. It retrieves a narrow set of public records, preserves links to their sources and asks the user to record decisions that the source cannot make. It does not estimate a property value automatically.
Method boundary: a result is a structured starting point for investigation. It is not a valuation, survey, title report, mortgage recommendation, tax calculation or planning search.
1. Resolve the search location
The user enters a complete UK postcode. The service normalises its format and resolves it through Postcodes.io, which supplies a postcode centroid and administrative geography. The first release connects planning datasets only when the returned country is England.
A postcode centroid represents a point associated with several addresses. It is not a verified title boundary. PropertyMetrics always displays the coordinates used so the geographic assumption remains visible.
2. Retrieve exact-postcode registered transactions
The service asks HM Land Registry's linked Price Paid Data endpoint for up to 100 transactions matching the exact postcode, ordered by completion date. It keeps only records with a transaction identifier, postcode, valid date and positive price.
The summary shows the observed count, low price, high price, median, lower and upper quartiles, number of observed years and latest completion date in that response. These are descriptive statistics for the returned records. No house-price trend or present value is inferred.
3. Assemble a labelled local candidate pool
When the full workspace is opened, Postcodes.io returns the subject postcode and up to seven nearest postcode centroids within 750 metres. The service makes a separate Price Paid Data request for each postcode and keeps the postcode and centroid distance attached to every transaction.
This step widens discovery when an exact postcode has few records. It does not assert that a nearby transaction is comparable. Centroid distance is not walking distance and does not describe street character, school catchments, physical condition, title boundaries or property attributes.
4. Build the comparable evidence set manually
A user selects one transaction as the subject reference and up to five other transactions as possible comparables. The workspace provides filters for property type, tenure and completion window, but the user remains responsible for confirming physical and legal similarity.
Each comparable can carry a positive or negative adjustment and a written reason. The original registered price remains visible beside the adjusted figure. This prevents an assumption from overwriting source evidence.
5. Describe the evidence set—not valuation confidence
The evidence-set label uses five simple checks: number of selected comparables, proportion matching the subject property type, proportion matching tenure and proportion completed within five years. It intentionally ignores facts the connected sources do not provide.
| Check | What it contributes | What it does not establish |
|---|---|---|
| Comparable count | Whether the conclusion relies on one or several transactions | Whether those transactions are genuinely comparable |
| Property type | Consistency of the recorded type label | Size, layout, condition or plot |
| Tenure | Consistency of freehold or leasehold classification | Lease term, ground rent or service-charge liabilities |
| Recency | How much of the set completed within five years | A market trend or current value |
6. Review annual, type and repeat-sale structure
The local evidence view groups the returned candidate pool by completion year and broad registered property type. It also identifies repeated, normalised address strings. Annual medians are raw observations rather than a mix-adjusted index. A repeated address is a prompt to inspect property and legal changes, not an annualised growth calculation.
7. Screen mapped planning designations
For English postcodes, the service asks the Planning Data platform for a defined set of mapped designations at the postcode centroid. A returned designation becomes a due-diligence prompt. The absence of a returned designation is never described as clearance because coverage differs by dataset and local authority.
8. Keep unknowns in the case
The due-diligence register tracks questions such as title and tenure, floor area, condition, lease obligations, achieved rent and boundary-specific planning checks. Each question can remain unknown, be marked as supported by evidence or be assigned for professional review.
9. Separate user assumptions from connected records
Purchase price, buyer position, residence status, deposit, mortgage rate, term, rent, voids, management, recurring costs, fees, works and reserve are editable planning inputs. Price and rent begin blank; percentage fields use visible defaults that the user must review. The model keeps scheduled rent, effective rent, operating costs, debt service and completion cash separate, then compares the base assumptions with a user-set rate and rent downside.
The illustrative SDLT calculation uses England and Northern Ireland residential bands effective from 1 April 2025. It does not determine relief eligibility, mixed-use treatment, linked transactions, company rules or a buyer's residence status.
10. Save a dated research snapshot
Saved cases are stored in the browser on the user's device. A case keeps the postcode, selected records, adjustment notes, dated case-journal entries and due-diligence statuses. Source data can change, so reopening a case also retrieves the current source response and retains only transaction identifiers that still match.
11. Compare postcodes under the same rules
The comparison board retrieves each postcode separately and presents the returned transaction count, median, middle 50% price interval, latest completion and planning-screen count. It does not convert exact-postcode samples into neighbourhood averages or rank locations as better investments.
Comparing medians is descriptive only. Different postcodes can contain different property types, tenures and transaction volumes, and registration delays can affect the current response.
12. Check a device-local watchlist
An area saved from the comparison board keeps a baseline response on the user's device. A manual refresh compares transaction identifiers, the latest completion date and the planning-screen record count with that baseline. A difference is recorded as an investigation prompt, not a market alert.
Review and change control
Material changes to source connections, field definitions, scoring or legal boundaries are recorded through the corrections process. Documentation is reviewed whenever an upstream data service changes and at least quarterly while the product remains active.