NELLA Labs product
Modelling the tenancy, not the transaction
A property platform built around the tenancy as the central record, so applications, agreements, payments, maintenance and communications form one continuous, attributable history.
- Client
- Domicium — a NELLA Labs product
- Status
- In development
- Year
- 2026
- Sector
- Property and real estate
This is a NELLA Labs product or platform, not an external commission. Nothing here implies a client engagement.
Context
Domicium is a NELLA Labs product in development. Its scope is provisional pending confirmation from the product owner, and nothing here should be read as a description of a shipped system.
Challenge and constraints
- Four parties — landlord, agent, tenant, contractor — need genuinely different views of the same tenancy, and the differences are about sensitive data rather than convenience.
- Statutory deadlines such as deposit registration and certificate renewal carry financial penalties for the landlord or agent.
- Disputes are decided on the record, so the record has to be evidence-grade rather than merely convenient.
- Load is dominated by document handling and month-end payment processing rather than by concurrent browsing.
Discovery
What we found, and what it changed
Research is only worth doing if it changes a decision. Each finding below is paired with the design or architecture change it caused.
Finding
Agents were reconstructing tenancy history from email, messaging apps and a spreadsheet whenever a dispute arose — typically taking hours per case.
What changed
The tenancy became the aggregate root, with every artefact attaching to it rather than to a property or a person.
Finding
Contractors were routinely given more access than the job required because the systems in use had no finer granularity.
What changed
Contractor access was scoped to the job and time-limited, with financial data behind separate permissions.
Finding
Missed compliance dates were caused by reliance on individual memory rather than by any lack of intent.
What changed
Compliance tracking with escalating, durable reminders and recorded acknowledgement was made a core capability rather than a report.
Solution
What we built
- The tenancy as the aggregate root, with properties, people, agreements, payments and works attaching to it.
- Row-level security keyed on tenancy membership and role, with financial and identity data behind additional permissions.
- An append-only tenancy ledger covering rent, deposits and works costs, reconciled against provider settlements.
- Documents in private storage with short-lived signed access, server-side validation, download auditing and per-class retention.
- Durable compliance reminders with escalation and recorded acknowledgement.
Journeys
How people move through it
Tenant: viewing to keys
Structured application stating exactly what is needed and why, identity verification once, visible status, electronic signature, and confirmed deposit registration.
Agent: managing a let
Listing with compliance documents attached, structured applications, referencing outcomes in one place, agreement generated from the record.
Landlord: portfolio oversight
Occupancy, income and arrears across the portfolio, upcoming compliance dates, and approval of works above a threshold.
Architecture
Decisions and the reasoning
These are the choices that would have been expensive to reverse. Each one is recorded as an architecture decision record in the project.
Tenancy as aggregate root rather than property or transaction.
It is the only entity that persists across the whole relationship, and it is what a dispute is actually about.
Append-only ledger for money movement.
Arrears schedules and deposit disputes require a defensible history; mutable balances destroy it.
Additional permission tier for financial and identity data.
Most people who legitimately need tenancy access have no need for bank details or right-to-rent evidence.
Asynchronous document pipeline.
Generation, validation and virus scanning are slow and bursty; doing them in a request handler produces timeouts at month end.
Security, accessibility and quality
- Access testing
- Positive and negative tests per role across tenancy, property and document boundaries.
- Upload safety
- Server-side type validation, size limits, scanning and quarantine — client-declared MIME types are not trusted.
- Retention
- Per-class retention with tested deletion for identity and application evidence.
- Reminder reliability
- Durable scheduling with retry, tested against clock changes and daylight-saving boundaries.
Timeline
- Shape3 weeksDomain modelling with agents and landlords; statutory obligation mapping.
- Design5 weeksMulti-party journeys, permission model, document and payment flows.
- BuildIn progressTenancy core, applications, agreements and maintenance.
Team shape
- Product lead
- Domain modeller
- Two full-stack engineers
- QA specialist
Technologies
- Next.js
- TypeScript
- Postgres
- Row-level security
- E-signature integration
Outcomes
What we can actually substantiate
Each statement is marked either verified — meaning it is demonstrable in the system — or design intent, meaning it is what the design sets out to achieve and has not yet been measured in production.
- Design intentOne continuous, attributable record per tenancy across all four parties.
- VerifiedContractor access is scoped to the job and time-limited.
- VerifiedFinancial and identity data sit behind permissions beyond ordinary tenancy membership.
- Design intentCompliance reminders are durable and escalate, with acknowledgement recorded.
Next stage
What comes next
- Portfolio reporting
- Compliance calendar completion
- Accounting export and landlord statements
Related
Keep reading
Work
Building verification into the centre of a learning marketplace
A tutoring marketplace where an educator profile is invisible to families until identity and credentials have been checked, and where sessions accumulate into curriculum-level progress rather than billable hours.
Work
Treating identity verification as orchestration rather than integration
Verification modelled as a configurable, resumable sequence of steps with an append-only evidence trail, so adding a market or replacing a provider is a configuration change rather than an engineering programme.
Next step
Have a problem shaped like this one?
Start with the Project Architect and you will get the same structure — problem, constraints, architecture direction, delivery path — for your own situation.