Skip to content

HousingBrixx Rebuild — Technical Architecture & Build Estimate

Date: 2026-02-18
Author: AI Software Architecture Estimate (based on OYN codebase + prior Brixx/HousingBrixx research)

Executive Summary

Reproducing MRI HousingBrixx as a modern, advisor-led SaaS is feasible, but this is a domain-complex financial platform, not a typical CRUD SaaS. The highest-risk and highest-value areas are:

  1. 30-year integrated 3-way engine correctness (P&L ↔ BS ↔ CF with monthly/annual granularity)
  2. Regulatory compliance outputs (FFR + SORP/FRS 102 conventions + RSH viability/stress expectations)
  3. Treasury/covenant logic under stress scenarios
  4. Data migration + trust parity vs incumbent models/Excel

A realistic path is a phased delivery: - Phase 1 (MVP/pilots): 9–12 months, targeted feature set for first 5 pilots - Phase 2 (Production): +9–12 months to support 50 clients reliably - Phase 3 (Scale/leadership): +12–18 months to reach 200+ with strong moat

Total build investment (3 phases): ~£3.3m–£8.3m depending on team size, pace, and compliance depth.

OYN Baseline Assessment (What was reviewed)

I reviewed: - /root/clawd/repos/oyn/README.md - OYN backend architecture and pipeline files (notably): - oyn/backend/api/main.py - oyn/backend/processing/pipeline_v2.py - oyn/backend/processing/calculations.py - oyn/backend/core/schema.py - settings, db/session, user/xero models - Prior research: - brixx-deep-research-2026-02-18.md - brixx-technical-spec.md - housing-brixx-deep-research.md

Key finding on OYN

OYN is a financial data ingestion/analysis platform (Excel/Xero parsing, snapshotting, AI commentary), not a full 30-year deterministic planning engine. It provides reusable platform foundations, but the core HousingBrixx-equivalent planning engine is largely net-new.

1) Architecture Design

1.1 Text-based System Architecture Diagram

┌─────────────────────────────────────────────────────────────────────┐
│                           Client Applications                      │
│  React/Next.js SPA  | Advisor Portal | Board/Read-only Portal     │
└───────────────┬───────────────────────────────────────┬─────────────┘
                │                                       │
                ▼                                       ▼
      ┌──────────────────┐                   ┌──────────────────────┐
      │ API Gateway/BFF  │                   │  AuthN/AuthZ Service │
      │ (REST/GraphQL)   │                   │ (SSO, RBAC, Audit)   │
      └───────┬──────────┘                   └──────────┬───────────┘
              │                                         │
              ├──────────────────────────────┬──────────┘
              ▼                              ▼
   ┌──────────────────────┐       ┌───────────────────────────────┐
   │ Plan Orchestration   │       │ Scenario & Version Service    │
   │ (workflows, jobs)    │       │ (branching, compare, stress)  │
   └──────────┬───────────┘       └──────────────┬────────────────┘
              │                                  │
              ▼                                  ▼
   ┌────────────────────────────────────────────────────────────────┐
   │                Core Financial Engine Service                  │
   │  - Component compiler                                          │
   │  - Time-series calc graph (360 months/30 years)               │
   │  - 3-way linkage (P&L, BS, CF)                                │
   │  - Covenants, treasury, dev appraisal hooks                   │
   └───────┬──────────────────────────────┬────────────────────────┘
           │                              │
           ▼                              ▼
┌───────────────────────────┐   ┌──────────────────────────────────┐
│ Reporting & Reg Service   │   │ Asset & Development Engines      │
│ FFR, SORP/FRS102 maps,    │   │ stock lifecycle + scheme models  │
│ board packs, exports      │   │                                  │
└────────────┬──────────────┘   └──────────────┬───────────────────┘
             │                                 │
             └──────────────┬──────────────────┘
                            ▼
            ┌──────────────────────────────────────┐
            │ Data Integration Layer               │
            │ CSV/Excel, GL systems, HMS, APIs,   │
            │ migration tools, validation pipeline │
            └─────────────────┬────────────────────┘
                              ▼
        ┌────────────────────────────────────────────────────────┐
        │ Data Platform                                         │
        │ PostgreSQL (OLTP) | Object Storage | Redis/Queue      │
        │ + optional warehouse for analytics/benchmarking       │
        └────────────────────────────────────────────────────────┘
                              │
                              ▼
                   ┌───────────────────────────┐
                   │ AI Layer (optional first) │
                   │ anomaly, narratives, NLP  │
                   └───────────────────────────┘

1.2 Core modules & relationships

  • Core Financial Engine is the system of record for projections.
  • Component System feeds the engine with locked formula objects.
  • Scenario Manager clones/overrides assumptions and runs differential recalc.
  • Loan & Treasury, Development, and Asset modules are specialized sub-engines writing cashflow/P&L/BS entries.
  • Regulatory Reporting maps engine outputs to formal templates (FFR, SORP/FRS narrative structures, VfM packs).
  • Consolidation aggregates intercompany-adjusted outputs across entities.
  • Dashboard/Reporting reads curated output marts.
  • Import/Export handles onboarding and periodic sync.
  • User Management secures tenant/entity/scenario access.
  • AI Layer consumes curated data, never source-of-truth for calculations.

1.3 Proposed Data Model (high level)

Core entities

  • Tenant (advisor firm or HA organization)
  • Organization (group)
  • LegalEntity (subsidiary/SPV/RP)
  • Portfolio / AssetBlock / UnitClass
  • Plan (30-year model)
  • PlanVersion (immutable snapshot)
  • Scenario (branch + overrides)
  • ComponentDefinition (formula-locked template)
  • ComponentInstance (parameterized in plan)
  • AssumptionSet (inflation, rent, voids, arrears, capex, rates)
  • Period (month index 1..360 + FY buckets)
  • JournalLine (engine postings, typed by statement)
  • LoanFacility, CovenantDefinition, CovenantResult
  • DevelopmentScheme, Phase, GrantAssumption, TenureMix
  • LifecycleRule, StockConditionRecord, CapexProgram
  • ConsolidationRule, IntercompanyBalance
  • ReportTemplate, ReportRun, RegulatorySubmission
  • ImportJob, MappingRule, ValidationIssue
  • User, Role, Permission, AuditEvent

Key relationships

  • Tenant 1:N Organizations; Organization 1:N LegalEntities
  • Plan belongs to LegalEntity or Group scope
  • Plan 1:N Scenarios; Scenario 1:N ComponentInstances/Overrides
  • ComponentInstances produce many JournalLines over Periods
  • JournalLines aggregate to statement marts (P&L/BS/CF)
  • LoanFacility + CovenantDefinition produce CovenantResults by period/scenario
  • Consolidation consumes entity outputs + intercompany eliminations

1.4 How this differs from OYN; reuse potential

OYN strengths reusable

  • FastAPI service scaffolding, settings discipline, env-driven configuration
  • File ingestion and validation pipeline patterns (Excel-first pragmatism)
  • Snapshot construction and schema validation approach
  • Basic multi-model AI orchestration and guardrails
  • Auth/session patterns, observability hooks, retention controls

Major gaps vs HousingBrixx-class platform

  • No 30-year deterministic planning graph
  • No native component-based planning model with locked formulas
  • No loan covenant engine / refinancing optimizer
  • No development appraisal engine for HA pipelines
  • No asset lifecycle/Decent Homes/building safety model
  • No FFR-compliant output engine
  • No group consolidation engine

Net: OYN accelerates platform plumbing, not domain core.

2) Module-by-Module Estimate

Estimates assume experienced team, parallel workstreams, and that regulatory design is available from domain SMEs. “Dev weeks” are elapsed feature-delivery weeks with a focused squad (not person-weeks).

Module Complexity Dev Weeks (elapsed) Typical Team Composition
a) Core Financial Engine Very High 24–36 2 backend staff/principal + 1 quant/financial engineer + 1 QA automation
b) Component System High 14–22 1 backend + 1 frontend + 1 financial modeller
c) Scenario Manager High 10–16 1 backend + 1 frontend + 0.5 QA
d) Loan & Treasury Very High 14–24 1 backend + 1 treasury SME + 1 QA
e) Development Appraisal High 12–20 1 backend + 1 frontend + 1 housing dev SME
f) Asset Management Very High 16–28 1 backend + 1 data engineer + 1 asset SME + 1 frontend
g) Regulatory Reporting Very High 12–20 1 backend/reporting + 1 finance/reg SME + 1 QA
h) Consolidation High 10–18 1 backend + 1 finance SME
i) Dashboard & Reporting Medium-High 10–18 1 frontend + 1 backend + 0.5 designer
j) Data Import/Export High 12–22 1 data/backend + 1 integration engineer + 0.5 QA
k) User Management Medium 6–10 1 backend + 0.5 frontend
l) AI Layer Medium (non-core) 8–14 1 ML/backend + 1 prompt/app engineer
m) Frontend (Next.js app shell + planner UX) Very High 20–36 2 frontend + 1 product designer + 1 backend support

Notes by module (critical nuances)

  • Core Engine: must support deterministic recompute, dependency graph ordering, circular dependency prevention, audit trace per number.
  • Component System: formula locking is key to replacing spreadsheet risk.
  • Scenario Manager: copy-on-write + override inheritance prevents data bloat.
  • Loan/Treasury: covenant breach early-warning and refinancing actions are must-have for treasurers.
  • Regulatory: needs rigorous test packs against known FFR examples and multiple accounting edge cases.
  • Consolidation: intercompany elimination UX can be a hidden complexity sink.
  • AI Layer: should be assistive only; never authoritative for compliant numbers.

3) Build Phases

Phase 1 — MVP (first 5 pilot clients)

Goal: deliver a credible, auditable alternative for pilot HAs with advisor support.

Include: - Core 3-way engine (monthly + annual rollups, 30 years) - Initial component library (income, opex, capex, asset, loan, equity, tax basics) - Scenario manager (base + 3–5 stress scenarios) - Loan/covenant essentials (ICR, gearing, liquidity headroom) - Basic development appraisal (scheme pipeline + grant + tenure split) - FFR export v1 + board report pack basics - Import/export via Excel/CSV templates - Tenant/user roles + full audit trail

Defer: deep connectors, advanced consolidation, advanced AI, broad benchmarking.

Phase 2 — Production (to 50 clients)

Goal: harden operations, broaden coverage, reduce advisor implementation effort.

Add: - Asset lifecycle module depth (decent homes, safety programs, EPC-style drivers) - Consolidation v1 (multi-entity, eliminations) - richer dashboards/custom reports - stronger integration layer (Xero + selected housing/GL imports) - migration toolkit from HousingBrixx/Excel patterns - compliance hardening + regression test harness - SRE maturity (SLAs, DR, monitoring, support workflows)

Phase 3 — Scale (200+ clients, category leadership)

Goal: enterprise depth + moat.

Add: - Full connector marketplace + API ecosystem - AI copilot for scenario design, anomaly detection, board narrative drafting - benchmarking network data products (opt-in, anonymized) - advanced treasury (hedging, refinancing optimization) - performance scaling (large portfolios, concurrent scenario runs) - partner/advisor operating layer (multi-client command center)

4) Team & Timeline

  • 1 Product Lead (HA finance domain)
  • 1 Tech Lead / Architect
  • 4–6 Backend Engineers
  • 2–3 Frontend Engineers
  • 1 Data/Integration Engineer
  • 1 ML/App Engineer (Phase 2+)
  • 2 QA/Automation Engineers
  • 1 DevOps/SRE
  • 1 UX/Product Designer
  • 1–2 Domain SMEs (treasury/regulatory/asset)

Core delivery team: ~10–15 FTE during peak build.

4.2 Timeline by phase (realistic)

  • Phase 1 MVP: 9–12 months
  • Phase 2 Production: +9–12 months
  • Phase 3 Scale: +12–18 months

Total: ~30–42 months to robust market-leading position.

4.3 What 1–2 senior devs can do vs needs a team

With 1–2 senior devs (6–12 months)

  • Build proof-of-concept 3-way engine core
  • Deliver limited component framework
  • Basic single-entity scenario analysis
  • Prototype UI and import templates

What requires a full team

  • Production-grade compliance, auditability, and UAT across HA edge cases
  • Loan covenant + development + asset lifecycle depth
  • Consolidation and reporting at enterprise scale
  • Reliable onboarding/migration pipeline for multiple clients
  • 24/7 operations, support, and security posture expected by larger RPs

5) Cost Estimates (GBP)

Assumes UK-based blended loaded rates and mixed seniority.

5.1 Phase 1 MVP (9–12 months)

  • Lean (6–8 FTE): £700k–£1.3m
  • Stronger (9–11 FTE): £1.2m–£2.0m

5.2 Phase 2 Production (+9–12 months)

  • Incremental: £1.0m–£2.0m

5.3 Phase 3 Scale (+12–18 months)

  • Incremental: £1.6m–£4.3m

5.4 Ongoing monthly run costs (post-Phase 2)

  • Cloud/SaaS infra: £15k–£60k/month (depends on tenant scale, data workloads, environments)
  • Support + success + QA + SRE staffing: £60k–£180k/month
  • Continuous product/compliance dev: £80k–£250k/month

Typical mature burn: £155k–£490k/month.

6) OYN Reuse Analysis

6.1 Directly reusable (high confidence)

  • FastAPI project skeleton, API conventions
  • Config/settings and environment patterning
  • Logging/observability foundations
  • File ingestion workflow patterns and schema validation style
  • Authentication/session baseline
  • AI integration scaffolding (for narrative/anomaly assistants)

6.2 Reusable with modification

  • Data pipeline orchestration (adapt for planning data instead of extracted actuals)
  • Snapshot concepts (extend to plan/version/scenario snapshots)
  • User and connection models (extend for multi-tenant enterprise RBAC and advisor hierarchy)
  • Reporting pipeline approach (must be redesigned for compliance output templates)

6.3 Net-new build required

  • Calculation graph engine for 360-period integrated forecasts
  • Formula-locked component compiler/runtime
  • Loan/treasury covenant simulation engine
  • Development appraisal engine
  • Asset lifecycle + stock condition logic
  • Consolidation/elimination engine
  • Regulatory mapper for FFR + SORP/FRS aligned outputs
  • Large new planner UX (drag-drop model builder, compare, diagnostics)

6.4 Acceleration impact from OYN

Estimated acceleration vs greenfield: - Engineering platform acceleration: 15–25% - Domain engine acceleration: 0–10% - Overall program acceleration: ~10–20%

Reason: OYN’s reusable value is mainly in platform plumbing and data discipline, not HousingBrixx-equivalent modelling semantics.

7) Key Risks & Decisions

7.1 Build vs extend decisions

  • Decision: whether to architect a bespoke deterministic engine or embed external modelling tech.
  • Recommendation: bespoke core engine (domain moat + auditability), modularized so select pieces can be swapped.

7.2 Regulatory compliance risk

  • Risk: failing edge-case compliance/format expectations can block adoption.
  • Mitigation:
  • Regulatory SME embedded in product loop
  • Golden test packs from real anonymized HA models
  • Formal model validation harness and sign-off process

7.3 Data migration from HousingBrixx/Excel

  • Risk: migration friction is a primary switching blocker.
  • Mitigation:
  • Import adapters for common workbook shapes
  • Assisted reconciliation (difference checker by statement/period)
  • Dual-run period tooling for confidence with board/lenders

7.4 Go-to-market timing risk

  • Risk: long sales cycles (6–12+ months) and incumbent inertia.
  • Mitigation:
  • Advisor-led distribution (already trusted channel)
  • Start with 3–5 lighthouse pilots and publish quantified outcomes
  • Win on speed, transparency, scenario power, and service quality

7.5 Technical risk hotspots

  • Engine performance at scale with many scenarios/entities
  • Formula governance/versioning and backward compatibility
  • Explainability: every number must be traceable to assumptions and formulas
  • Security expectations for social housing sector procurement

Suggested Delivery Blueprint (practical)

  1. First 8 weeks: domain blueprint + canonical chart-of-accounts mapping + engine contract tests
  2. Months 3–6: core engine + component runtime + first UI planner
  3. Months 6–9: scenarios + loan/covenant + FFR v1 + pilot onboarding tooling
  4. Months 9–12: pilot hardening, reconciliation tooling, production readiness
  5. Year 2: asset/development depth, consolidation, connectors, enterprise operations
  6. Year 3: AI differentiation, benchmarking, ecosystem play

Final Recommendation

This is a strong opportunity because the market is concentrated, sticky, and underserved by modern UX and AI-native workflows. Success depends less on generic SaaS execution and more on financial model trust. The winning strategy is:

  • Build deterministic, auditable modelling core first
  • Pair with advisor-led implementation and migration support
  • Use AI as leverage around planning productivity and narrative, not core arithmetic
  • Treat compliance and reconciliation as product features, not afterthoughts