Technical Architecture

Harla's platform is built as a single, multi-product architecture serving four connected solutions — Portfolio Intelligence, Customer Portal, Transaction Readiness, and Transaction Execution — from a shared data and AI backbone. This avoids the technical debt of building four isolated tools and positions the platform to compound value across modules as data accumulates.

The architecture has four tiers: an inbound layer that ingests documents, property data feeds, KYC/AML results, and lease records; an agentic AI pipeline that orchestrates model calls, embeddings, and document parsing; a data layer comprising a relational database, vector store, object storage, and job queue; and an operator-facing interface layer serving both landlord-side and occupier-side portals through a single authenticated application.

The current implementation is deliberately pre-scaling: built on managed services, serverless-first, and designed to move fast. The deliberate deferral of premature infrastructure is a considered choice, not a constraint.

Cloud provider: Vercel (compute and CDN) + Supabase (database and auth) + Cloudflare R2 (object storage). All three are managed services requiring no infrastructure operations at this stage.

Deployment model: Serverless-first. API routes and background functions run as serverless functions on Vercel. Long-running AI pipeline tasks are offloaded to a job queue (BullMQ on a small dedicated worker, or Inngest for fully serverless execution).

Data residency: UK and EU data residency is in place for all material data stores. Supabase offers a dedicated EU-West region; Cloudflare R2 stores objects in EU; Anthropic's API does not persist data between calls. Lease documents, KYC records, and compliance data never transit outside the EU/UK zone.

Backup and DR: Supabase automated daily backups with 7-day point-in-time recovery. Object storage versioning enabled. No formal DR runbook exists at pre-seed; this is a planned milestone before the first institutional development partner goes live.

Current monthly infrastructure cost: Estimated £80–£150/month at pilot scale (1–3 development partners, low document volume). This is dominated by Supabase Pro (£25), Vercel Pro (£20), and AI inference costs (variable, estimated £30–80/month at pilot usage levels). Infrastructure cost scales sub-linearly with customer count until approximately 50 concurrent operator organisations.

Authentication: Supabase Auth with JWT-based session tokens. Row-level security (RLS) policies on all database tables ensure tenants can only access their own data at the database level — not just at the application layer. The data room at data-room.harla.co.uk uses a JWT-gated access model with server-side token verification.

Data encryption: At rest — Supabase and Cloudflare R2 encrypt all stored data using AES-256. In transit — TLS 1.2+ enforced across all endpoints; HTTPS-only enforced at the CDN layer.

Access controls: Role-based access at the application layer (operator admin, team member, read-only). No direct database access is exposed to end users. API keys for third-party services (AI providers, KYC vendors) are stored as environment secrets in Vercel — never committed to the repository.

Third-party security tooling: Vercel provides automated DDoS protection and WAF at the edge. Dependabot is enabled for dependency vulnerability scanning. No formal SIEM is in place at pre-seed.

Penetration testing: Not yet conducted. This is planned ahead of the first full development partner onboarding. A targeted assessment covering the authentication model, RLS policies, and API surface is scoped as a pre-launch milestone. Estimated cost £3,000–6,000 for a scoped engagement.

Data processing agreements: DPAs in place with Supabase and Cloudflare. Anthropic API usage reviewed against their data processing commitments — no training on API inputs by default.

The current architecture is designed for the pre-seed period — fast to build, fast to change, and sufficient for the first cohort of pilots. The following is an honest account of what has been deferred and at what point those investments become necessary.

10 concurrent customers (current target): The existing stack handles this without modification. Supabase's shared infrastructure, Vercel's serverless autoscaling, and a single job worker are sufficient. The main constraint is AI inference latency on document-heavy workloads — mitigated by async processing and background queuing.

100 concurrent customers: The primary pressure points become database connection pooling (Supabase's PgBouncer covers this to ~200 concurrent connections), vector index size (pgvector begins to degrade beyond ~5M vectors — Pinecone or a dedicated Qdrant instance would be introduced), and AI inference cost (prompt caching and model tiering become financially material). A dedicated background worker fleet and more granular observability would also be introduced at this stage. Estimated engineering investment: 4–6 weeks.

1,000 concurrent customers: At this scale, the architecture requires a meaningful evolution: database sharding or migration to a dedicated Postgres cluster; a dedicated vector database; a multi-region CDN and data residency strategy per customer type (REIT vs BTR vs private landlord may have different compliance requirements); and formal SLA infrastructure including blue/green deployments and an incident response playbook. This is a Series A-stage infrastructure investment, not a pre-seed one. The current architecture does not constrain growth to this point — it defers the cost appropriately.

What is not deferred: Multi-tenancy isolation (RLS is in place from day one), data residency (UK/EU from day one), and authentication model security. These are not scaling concerns — they are compliance baselines that have been implemented regardless of stage to ensure the quickest route possible to SOC 2 and ISO accreditation.