The Technology Roadmap

The engineering build path for the Intelligent Letting Agency · 9 June 2026

Sequence, dependencies, and what's next — not a full spec. The vision is unchanged; the journey is staged to manage risk: build the platform once, then onboard every acquired business onto it. Companion to the process catalogue, the build plan, the data architecture, the process map, integrated suppliers, the record-layer stance and diligence → onboarding.

The two documents. Doc 1 — this — is the plan to build our technology platform once. Doc 2 — the process catalogue — is every process a letting agency runs, classified for the build and used as the per-target current-state survey (how / who / what-tech today). The filled survey is the ingestion brief; walking the catalogue is the DD. Build once; onboard many off the same catalogue → the DD & onboarding playbook.

0Ownership, roles & trigger

Owner: Ed. Owns the build and the architecture, delegates to the team, and is also an operator of the system — he has to be, to train the team.
Pablo — delegated technical build (Supabase + n8n + Claude API).
Jemima — accuracy / QA.
Rachel — the ops layer: sets up and integrates the services and suppliers (banking, comms, deposit / referencing / e-sign, maintenance), and is an operator who trains the team.

Build now — don't wait for completion. The synthetic dataset (below) lets us build and test before a real book exists. Glenn Flegg + Flatman completion is the first real-data milestone, not the start gun — per diligence → onboarding, diligence is the first ingestion.

1Map the processes — the three axes, and the thirds

Every process in the process map sits on three axes (all 63 classified in the process catalogue): where the work is (physical / local / anywhere) × who is accountable (AI delivers vs human decides) × the core delivery + AI enhancement — is the core Alto (CRM/Base), an AI outcome (we build the automation), an AI copilot (AI assembles, human decides), or physical (a body must attend); and what net-new AI adds on top.

The operational work splits almost exactly in thirds:

Core	Trad. hrs / 100 props	Verdict
Alto — Base	~736 (35%)	Use the CRM properly; don't build (Tier 2)
AI outcome — build	~659 (31%)	The cognitive work Alto only logs — what we build (Tier 3)
Physical — armed	~653 (31%)	Body irreducible, but AI makes it 2–3× more effective (Tier 3)
AI copilot — assist	~61 (3%)	High-stakes; AI assembles, a human decides (Tier 3)

So the build divides cleanly: build the AI-outcome cluster (maintenance, comms, drafting, arrears, rent-review), arm the physical (precision dispatch from the digital twin; the AI valuer/viewer pack; batching), ride Alto for the Base, and coordinate (don't build) the outsourced physical execution. The physical third is armed, not untouched — that correction matters: it is real efficiency on the biggest single hour-bucket.

2Prioritise the build order — value × dependency

Two axes: value (the AI-native delta × volume × revenue, per the catalogue) and dependency (what must exist first).

The data/context layer is the root dependency — no skill works without it.
The financial trio (rent collection · landlord payment · statement + reconciliation) is mostly Alto/Base now — a ride-and-ingest, not a build; the banking feed still matters for our mirror + the proxy model.
The prize to build first (highest delta × volume): maintenance (triage + contractor, ~300 hrs + £18k, the twin) and tenant comms (133 hrs), then drafting / rent-review (S13) / disputes / onboarding.

#	Workstream	Depends on	Why here
1	Context/data layer (the spine + the Alto mirror)	—	Root dependency for everything
2	AI-build prize — maintenance, comms, drafting, arrears, rent-review	the spine + the banking feed	Highest AI-native delta; carries revenue
3	Arm the physical — inspection / viewing / cert coordination + the twin	the spine + the photographic asset layer	Big-hours efficiency on the irreducible floor
4	B-skills, stakes band — disputes, possession, ombudsman	full context + precedent	Rare, heavy; AI assembles, Ed/legal decides

3The context & data layer the processes need

The substrate is the four layers in the data architecture: immutable event log → structured spine → flexible context → completeness/readiness. The job is to translate the prioritised processes into the concrete data each needs — per-property ledger + bank events for the financial trio; cert events + PDFs for compliance; messages-as-events for comms; the asset register for maintenance; the assembled file for disputes.

Go beyond — the photographic asset layer (the property's digital twin). Photograph every appliance, fixture and fitting and vision-extract them into structured asset records (type, make/model, location, install date, condition, linked warranty/cert). This is what arms maintenance (the contractor gets the exact part), makes deposit-dispute evidence automatic, and powers check-in/out comparison. No incumbent has this. A carefully-structured sub-layer — each asset a record, each image an immutable event — not a photo dump.

4The record-layer journey — ride → mirror → augment → own

The goal is unchanged: own a reliable, well-structured, AI-native system of record. What changes is the journey — staged and de-risked, not a day-one rebuild. We will not shut a working operational system down on completion out of principle; that is how you drop the ball.

Day 1 — inherit and ride. A corporate purchase (Flatman) inherits the live platform (Alto) with the book already on it. That stays the operational system of record on completion — simply where the book is managed. No disruption, no forced migration.
Then — integrate and mirror. Build our API integration and stand up our own database that tracks the incumbent — a continuously-synced mirror we own from the outset: a reliable, structured core immediately, validated against the live system, carrying zero operational risk (ops still run on the incumbent; the mirror is read-side until we promote it). Strangler-fig, not big-bang.
Then, staged on that core: (1) augment beyond the incumbent — the digital twin, comms-as-events, completeness/readiness, the proxy model — and later export and own it; (2) ingestion methods & tools; (3) outputs & AI — run the build-cluster skills against our core and use AI to improve what the system produces.

Per target (the path depends on the incumbent's API):

Flatman / Alto — modern platform with a real API → live API integration + mirror from day one. First, assess Alto's read/write API coverage — it sets how much mirrors live vs. must be exported, and whether Alto can be driven headlessly.
Glenn Flegg / Veco — API is portal/marketing, not operations (letting software research) → completion export → ingest; a batch core, no live mirror.
HouseShaw & others — capture the incumbent + its API at DD; assess the same way.

Own the layer, rent the rails. Own the differentiating layer — the spine, AI execution, governance, the twin, adjacencies, relationships. Rent the commodity rails — portals (Rightmove RTDF etc.), open banking, deposit schemes, e-sign, referencing, comms, the client-money ledger — riding Alto's in transition. A vendor dependency on a commodity pipe is fine; never rent the data, the AI or the relationships. The destination is always our substrate; the path is staged to manage risk.

5Build the data layer & ingestion integrations

The ingestion path (per diligence → onboarding): ingest into our substrate per-property, provenance-tagged (imported_unverified → landlord_confirmed), as ~350 small recoverable events — not a big-bang migration. Where there is a real API (Alto), this is the live mirror; where not (Veco), a completion export. Diligence is the first ingestion; the landlord sign-across upgrades provenance.

The integrations that feed the substrate — each must land events in the immutable layer, not sit in a portal we reach out to:

The Alto API integration + the mirror DB — the near-term Flatman build; assess read/write coverage first.
Banking — per-property accounts + read/write API + CMP segregation (provider open: integrated suppliers).
Email · WhatsApp · VoIP + notetaker — every message a structured event; calls → transcripts → context.
Function suppliers (integrated suppliers) — deposit schemes (statutory window gated); referencing; e-sign; maintenance triage (Fixflo API).
Visual/asset ingestion — a mobile photo-capture flow → vision extraction → the structured asset records of §3.
The per-table data model — the four layers as concrete event types + projected entities; register the Barbara domain in the Cockpit data_registry.

6Build enabler — a synthetic dataset

Before a real book exists, build a realistic synthetic lettings dataset — properties, tenancies, ledgers, comms threads, certs with live expiries, maintenance histories, a sample deposit dispute, and a synthetic photographic asset set. It unblocks the build now, shadow-tests throughput (the #1-risk headcount validation — the Dwelly benchmark), and gives day-1 readiness (completion swaps synthetic for real). It is also the model for the mirror schema — build it early, in parallel with the data model.

7What's next — the immediate path

Assess Alto's API (read/write coverage) + build the API integration + mirror DB — the near-term Flatman build.
Synthetic dataset + the per-table data model (parallel — they define and test each other).
Banking provider decision (integrated suppliers) — for the proxy model + the mirror's financial events.
The AI-build prize — maintenance + comms skills, shadow-tested against the synthetic data.
GF + Flatman completion → first real ingestion (diligence → onboarding).
Arm the physical (inspection / viewing / cert coordination + the twin), then the B-skills (disputes, possession).

Provenance: Ed + Claude, 9 Jun 2026 (v3) — restated as a de-risked, staged journey after the Alto-class CRM realisation: build once; ride the incumbent → mirror → augment → own; own the layer, rent the rails; the work splits in thirds (use-the-CRM / AI-build / arm-the-physical) per the process catalogue. Earlier (v2) additions retained: the synthetic-dataset harness and the photographic digital twin. Owner: Ed; technical delegated to Pablo; Jemima QA; Rachel ops/operator. Roadmap, not spec. · Live doc rendered from wiki tech-roadmap v3.