A multi-surface estate operations platform spanning web, mobile, and a Node/Express API, designed for portfolio-scoped asset and compliance operations with field capture, role-based access, and auditability built into the core model.
Executive Summary
Core Domain
Portfolios, properties, areas, assets, and compliance obligations
Clients
React web operations UI + Flutter mobile field app
POC Signal
Audit trails, geospatial search, role guards, and presigned uploads already implemented
Delivery Focus
Validate domain model + operational workflows before deeper UI modules
Overview
The Problem
Estate operations teams need a portfolio-scoped system to manage properties, areas, assets, and compliance obligations, but field capture, auditability, and role-based operations are often split across disconnected tools.
The Opportunity
Build a multi-surface platform where web and mobile clients share a clear API/domain model, enabling operational dashboards, field asset updates, compliance workflows, and auditable change tracking from day one.
Current Stage
Proof of concept with production-relevant architecture decisions already in place: role guards, audit trails, geospatial queries, presigned uploads, and multi-client API consumption patterns.
My Role
Founder/product architect and hands-on builder shaping domain modeling, API design, client architecture patterns, security posture, and POC delivery scope.
Domain Model Snapshot
Estate Hierarchy
Portfolio -> Property -> Area forms the core location model. Assets and compliance records attach to that hierarchy for portfolio-scoped operations and reporting.
Asset Operations
Assets support lifecycle updates, condition tracking, optional GPS capture, presigned photo uploads, and nearby search to support field workflows.
Compliance Obligations
Compliance records carry category, risk, status, due dates, and review cadence linked to portfolio/property/area/asset context.
Access + Audit
Role-based access and auditability are first-class platform concerns, especially for asset state changes and field evidence capture.
Architecture Decisions
EstateOps is early-stage, but the architecture is already built around operational realities: auditability, geospatial queries, field capture, role-based access, and shared API consumption across web and mobile clients.
Cross-Surface Runtime Flows
Why These Decisions
Multi-surface platform from the start
Why: Estate operations spans desktop admin workflows and field/mobile capture; one client would under-serve one of those contexts.
Impact: Web and mobile can optimize UX independently while sharing the same API/domain contracts.
Thin API clients + normalized payload mapping
Why: Both web and mobile need stable, predictable data handling while the backend evolves during POC.
Impact: Cleaner client code, easier testing, and lower coupling to backend response shape changes.
Audit trail as a core feature (not an afterthought)
Why: Operational systems need trust and traceability for asset updates and evidence changes.
Impact: Asset events such as CREATED, UPDATED, and PHOTO_ADDED are captured with diffs for auditability.
GeoJSON + 2dsphere indexing for asset location
Why: Nearby search and location-aware field workflows need a real geospatial storage/query model.
Impact: Native distance queries and scalable geospatial operations without bolted-on filtering logic.
Presigned uploads via Cloudflare R2
Why: Photos and media should upload directly to object storage instead of transiting the API server.
Impact: Lower backend load, better upload reliability, and clearer storage boundaries.
Password policy enforced on client and server
Why: Consistency matters in UX and security; client-only or server-only enforcement creates avoidable friction and gaps.
Impact: Predictable validation behavior and reduced weak-password acceptance risk.
POC scaffolding kept intentionally visible
Why: Some UI surfaces (maps/plans/gallery/action buttons) are roadmap placeholders and should preserve architectural direction without overbuilding too early.
Impact: Fast proof-of-concept delivery with a clear path for future feature depth.
API / Backend
The API handles the platform's core domain behavior, access control, validation, audit events, geospatial queries, dashboard summaries, and upload orchestration for both client surfaces.
Login, current-user bootstrap, forgot/reset password, forced reset for invited users, profile update, and change password are implemented behind JWT auth and role guards.
Portfolio/property/area hierarchy administration is implemented with default role seeding on portfolio creation and naming/index constraints to protect data quality.
Assets support create/list/detail/update workflows, condition tracking, optional GPS capture, photo uploads, nearby search, and first-class audit events with diffs.
Compliance records capture category/risk/status, review cadence, due dates, and links back to the estate hierarchy or specific assets.
GM-only user CRUD, role assignment, primary-role handling, and custom role management for non-system roles support portfolio-scoped administration.
Dashboard APIs support risk summaries, overdue/compliance insights, attention-needed assets, and recent updates for both web and mobile surfaces.
Express 5 middleware stack includes Helmet, CORS, JWT verification, role guards, and centralized validation/runtime error handling.
Cloudflare R2 uploads are handled via presigned URL flows from the API, keeping file transfer off the backend server while maintaining authorization control.
Web App (React)
The web app uses React 19, Vite, and MUI/DataGrid Premium to handle operational tables, dashboards, and portfolio administration while keeping client integration logic thin and typed.
TypeScript + Vite + React 19 web app using MUI and DataGrid Premium for portfolio-scoped operations, dashboards, and admin workflows.
Dashboards visualize risk summaries, overdue compliance, attention-needed assets, and recent updates for estate operations monitoring.
Web workflows support asset CRUD/detail flows, condition changes, media evidence interactions, and compliance record management in a portfolio context.
Asset views intentionally include placeholders (map/plan/gallery and action surfaces) to preserve extensibility while the POC validates the core domain model and workflows.
Mobile App (Flutter)
The mobile app focuses on field usability: secure auth persistence, service-based API access, optional GPS capture, photo uploads via presigned URLs, and failure-tolerant operational flows.
Flutter mobile app supports field data capture and operational views with Provider state management, secure token storage, and an HTTP service layer.
Mobile supports asset operations with optional GPS capture and photo uploads through presigned URLs, designed to tolerate failures without blocking core workflows.
Mobile mirrors the platform's role-based access patterns while keeping the client implementation thin and focused on operational capture and insight surfaces.
The mobile codebase already has meaningful test coverage across services, auth, uploads, asset-detail behavior, and root app flows.
Tradeoffs & Constraints
EstateOps is intentionally at proof-of-concept stage, but the implementation already reflects durable architecture choices. The remaining tradeoffs are mostly about delivery sequencing, not structural direction.
POC speed vs full feature completion
Rationale: The goal is validating core estate operations workflows, data model fit, and multi-client architecture before fully building map/plan/gallery and advanced action surfaces.
Tradeoff: Some UI scaffolding remains intentionally incomplete, but the structural architecture is already clear and extensible.
Shared backend for multiple clients vs faster single-surface prototype
Rationale: The product thesis depends on both office/admin and field/mobile usage, so API design must work for both from the start.
Tradeoff: More upfront architecture work, but fewer rewrites when expanding beyond the proof of concept.
Direct presigned uploads vs API-managed media handling
Rationale: Media uploads are operationally expensive and better handled directly by object storage.
Tradeoff: Additional upload orchestration complexity, but better performance and cleaner backend boundaries.
Strict data indexes/constraints early vs looser prototype schemas
Rationale: Operational and role data becomes difficult to clean up later if integrity is deferred too long.
Tradeoff: More modeling work in POC stage, but stronger data quality and less migration pain later.
Outcomes / Metrics
This project is currently in proof of concept, so the portfolio emphasis is on architecture quality, domain modeling, and execution signal rather than production-scale metrics.
Outcomes / Delivery Signals
Quality / Maturity Signals
What I'd Improve Next
The next phase should focus on finishing the roadmap-visible UX surfaces, strengthening automated test coverage, and deepening operational analytics and workflow orchestration on top of the existing model.
Expand map/plan/gallery and operational action surfaces beyond current scaffolding into full workflow modules.
Increase server automated coverage beyond health-route baseline into asset/compliance/audit and role-guard behaviors.
Add deeper observability and audit reporting views for operational activity across portfolios and field teams.
Strengthen offline-first behavior on mobile beyond current upload/session resilience where product needs justify it.
Formalize shared API contracts/DTOs across web and mobile clients as the schema stabilizes beyond POC.
Introduce richer compliance analytics and remediation workflow orchestration after core usage is validated.
Contact
I can help shape the domain model, API boundaries, and multi-client delivery strategy so the product scales beyond the proof of concept.