Records Platform
Property Records Platform
Multi-tenant records system with a .NET 8 API and a React TypeScript frontend
- Role
- Full-stack developer
- Visibility
- Confidential case study
Overview
A property records application built on a .NET 8 API using Clean Architecture, SQL Server, and multi-tenancy, with a React and TypeScript frontend.
Business problem
Property records need to be accurate, searchable, and strictly separated between the organisations that own them. The same application serves multiple tenants, so every query and every write must be scoped to the correct tenant without relying on developers remembering to add a filter.
Users and workflow
Users belonging to a tenant manage that tenant's property records: creating and updating entries, searching, and reviewing history.
Tenant context is resolved at the API boundary and flows through the application so that data access is scoped automatically.
- Tenant-scoped property records
- Search and filtering
- Record history
- Tenant and user administration
My role and contributions
Worked as a full-stack developer within a team. The list below describes the areas I contributed to; it is scoped to what I worked on and does not represent the entire platform.
- Worked within a Clean Architecture solution structure: domain, application, infrastructure, and API layers with dependencies pointing inward.
- Implemented tenant-scoped data access on SQL Server so queries are filtered by tenant by default.
- Built React and TypeScript frontend features backed by typed API contracts.
- Contributed to API design and validation for record management endpoints.
Technical stack
- C#
- .NET 8
- ASP.NET Core Web API
- Clean Architecture
- Multi-tenancy
- SQL Server
- React
- TypeScript
Architecture
Frontend
- React
- TypeScript
- Typed API client
API
- .NET 8 Web API
- Tenant resolution
- Request validation
Application and Domain
- Use cases
- Domain entities
- Interfaces
Infrastructure
- SQL Server
- Tenant-filtered data access
Technical challenges
Tenant isolation without repetition
Adding a tenant filter to every query by hand is fragile. The data layer applies tenant scoping centrally so that a forgotten filter is not possible for standard queries, and cross-tenant operations have to be explicit.
Design and engineering decisions
Clean Architecture layering
Business rules live in the application and domain layers with no dependency on the web framework or database. That keeps use cases testable and makes infrastructure choices replaceable.
The trade-off is more files and mapping code than a single-project API. For a records system expected to grow, the separation paid for itself in clarity.
Shared schema with tenant discriminator
A single SQL Server database with a tenant key on tenant-owned tables kept operations simple while still enforcing isolation in the data layer. A database-per-tenant model was considered and set aside for the initial scope.
Results and lessons learned
- A layered .NET 8 codebase where tenant isolation is a property of the data layer rather than of individual queries.
- A working model for pairing a Clean Architecture API with a typed React frontend that later work can reuse.
Quantified business metrics are not published for this engagement; the results above describe delivered functionality and engineering outcomes.
Related
More case studies
Veterinary Management and Reporting Platform
A business platform that runs veterinary service operations: user management, test and report workflows, orders and requisitions, tasks, payments, and client records.
- C#
- ASP.NET Core
- REST APIs
- Entity Framework Core
- SQL Server
Travel Management Platform
A business application for travel operations covering tours and groups, reservations, invoices, tasks, and integrations with external services and payment providers.
- C#
- ASP.NET Core
- REST APIs
- SQL Server
- JavaScript