Strata Reserve Planning Depreciation Portal

User research began with the creation of detailed personas representing the primary users of the platform. These personas captured user demographics, engagement levels, daily routines, and the specific value the application would provide to each user type.

User Personas

Bruce, Property ManagerLinda, Council President

User Flows

Detailed user flow diagrams were created for each of the four roles, mapping every interaction from login through to task completion. These flows informed the navigation structure, permission boundaries, and feature priorities for each role.

Admin User FlowClient User FlowInspector User FlowAssistant User Flow

Agile project management was adopted using Jira to organize sprints, track progress, and manage the product backlog. Weekly sponsor meetings were held each Friday, followed by a team meeting to assign the upcoming week's tasks and a sprint review to discuss what was completed and what could be improved. Team members took turns pushing code and tasks were assigned to play to individual strengths, whether that was tackling work immediately, deep research, or refining UI details, maximizing overall output.

Jira Project Management

Jira BoardJira Backlog

Naming Conventions & Project Structure

Clear naming conventions and a well-defined project structure were established early in development to ensure consistency across the three-repository architecture. These conventions governed everything from git branch naming to database column formats.

frontend/src/
├── admin/                    # Admin-specific features
│   ├── components/           # Admin-only UI components
│   ├── pages/                # Admin-only pages
│   ├── routes/               # adminRoutes.tsx
│   └── styles/               # Admin SCSS (components/, pages/)
├── client/                   # Client-specific features
│   ├── components/           # Client-only UI components
│   ├── pages/                # Client-only pages
│   ├── routes/               # clientRoutes.tsx
│   └── styles/               # Client SCSS (components/, pages/)
└── shared/                   # Shared across admin & client
    ├── assets/               # Images, icons, static assets
    ├── components/           # Reusable UI components
    ├── contexts/             # React contexts (AuthContext)
    ├── hooks/                # Custom React hooks
    ├── lib/                  # apiClient, supabaseClient
    ├── pages/                # Shared pages (Login, SetPassword)
    ├── routes/               # ProtectedRoute, DashboardRouter
    ├── styles/               # Global SCSS (base/, variables/, utilities/)
    ├── types/                # ALL TypeScript type definitions
    └── utils/                # Date formatting, strata plan formatting, recurring patterns

frontend/src/
├── admin/
│   # Admin features
│   ├── components/
│   ├── pages/
│   ├── routes/
│   └── styles/
├── client/
│   # Client features
│   ├── components/
│   ├── pages/
│   ├── routes/
│   └── styles/
└── shared/
    # Shared code
    ├── assets/
    ├── components/
    ├── contexts/
    ├── hooks/
    ├── lib/
    ├── pages/
    ├── routes/
    ├── styles/
    ├── types/
    └── utils/

backend/src/
├── admin/                    # Admin-specific features
│   ├── controllers/          # Admin HTTP handlers
│   └── routes/               # Admin route definitions
├── client/                   # Client-specific features
│   ├── controllers/          # Client HTTP handlers
│   └── routes/               # Client route definitions
└── shared/                   # Shared across admin & client
    ├── config/               # Static mappings and configuration
    ├── constants/            # Validation rules, Prisma includes
    ├── controllers/          # Shared controllers (auth, lookup)
    ├── helpers/              # responseHelper, dateUtils, etc.
    ├── lib/                  # prismaClient, supabaseClient, emailService
    ├── middleware/           # auth.ts, adminMiddleware
    ├── routes/               # Shared routes (lookup, auth)
    ├── services/             # Business logic & all DB access
    └── types/                # ALL TypeScript type definitions

backend/src/
├── admin/
│   # Admin features
│   ├── controllers/
│   └── routes/
├── client/
│   # Client features
│   ├── controllers/
│   └── routes/
└── shared/
    # Shared code
    ├── config/
    ├── constants/
    ├── controllers/
    ├── helpers/
    ├── lib/
    ├── middleware/
    ├── routes/
    ├── services/
    └── types/

supabase/functions/
├── _shared/                  # Shared utilities (cors, supabase, dropbox)
├── upload-document/          # Document upload handler
├── delete-document/          # Document deletion handler
├── preview-document/         # Document preview handler
├── download-fn-documents/    # Bulk document download
├── sync-documents/           # Document sync handler
└── archive-fn-documents/     # Document archival handler

supabase/functions/
├── _shared/
├── upload-document/
├── delete-document/
├── preview-document/
├── download-fn-documents/
├── sync-documents/
└── archive-fn-documents/

Figma prototypes were created for both the Admin and Client platforms, serving as the initial design reference for development. These prototypes were then iterated on in the live application through weekly client meetings, allowing real-time feedback to shape the final user experience.

Admin Prototype

Admin Prototype - DesktopAdmin Prototype - Mobile

Client Prototype

Client Prototype - DesktopClient Prototype - Mobile

The platform was built as a three-tier architecture spanning three separate repositories: a React/TypeScript/Vite frontend, a Hono/Prisma backend API, and Supabase Edge Functions (Deno) for serverless document handling.

Strategic Build Order

A deliberate strategy was employed for the development sequence. The Admin and Client platforms were designed and built first, as these two roles encompassed the full feature set of the application. This approach allowed for comprehensive user testing and bug resolution on the most complex interfaces before proceeding further.

The Inspector and Assistant platforms were then developed after the core platforms had been stabilized through testing. These roles are essentially filtered versions of the Admin platform, sharing the same underlying architecture but with restricted access and streamlined interfaces tailored to their specific workflows.

Architecture Highlights

• Frontend: Role-based routing with separate admin and client route trees, shared component library, custom hooks for data fetching, and SCSS modular styling.
• Backend: RESTful API with Hono framework, Prisma ORM for type-safe database access, role-based middleware for route protection, and shared service layer for business logic.
• Supabase Edge Functions: Deno-based serverless functions handling document operations (upload, download, preview, archive, sync) with Dropbox API integration.
• Database: PostgreSQL with Prisma schema, snake_case conventions, and role-based data access patterns.

Iterative UI Improvements

Weekly client meetings drove continuous iteration on the UI, with several key improvements emerging from real-world usage and feedback:

• Question CRUD & Filtering: A question management system was added for admin, allowing the company to configure survey questions and document filtering logic directly, handling edge cases without code changes. Strata plan and strata name filters were linked to auto-update when either is entered.
• Dropbox Sync: A sync button was added for documents to reconcile the database with Dropbox, preventing orphaned database entries from files that were manually deleted or moved outside the platform.
• Pop-out Navigation: A collapsible navigation bar was added on mobile and tablet views to maximize screen space for table data.
• Appointment Locations: Location grouping was added for appointments to ensure multiple appointments scheduled on the same day are within the same region.

Question CRUD SystemDropbox SyncTablet View - Locations & Pop-out Nav

Before expanding the platform to include the Inspector and Assistant roles, in-person testing was conducted with the sponsor using the completed Admin and Client platforms. This hands-on testing session validated core workflows, uncovered usability issues, and confirmed that the foundational features were stable enough to build upon.

User Testing Outcomes

The testing sessions produced a structured bug fix plan of over 80 items, prioritized into five phases by complexity and dependency. Each phase was executed in order, with fixes verified before moving on.

• Text & Label Corrections (14 items): Field labels were clarified across forms (e.g. "Unit Number (if applicable)"), button text was made more descriptive (e.g. "Save Pending Future Changes", "Finalize Answers & Submit"), and login page copy was updated to reflect the correct contact information and branding.
• UI & Component Fixes (22 items): Validation rules were tightened (strata plan number flexibility, required property types and strata plans for client users), modal behavior was improved (removed accidental close-on-click-outside, increased configure document modal height), conditional form fields were added (showing property types and strata role only for client users), and session persistence was added for active tabs.
• Survey & Appointment Flow Logic (33 items): Survey workflows were enhanced with "Unknown" and "Not Applicable" toggles, conditional sub-questions, mid-survey save, and download functionality. Appointment scheduling was tightened with mandatory inspector assignment, multi-inspector support, restricted draft meeting times, and proper client-facing status updates. Timeline calculations were corrected to use fiscal year end dates with overwrite restrictions.
• Backend & Data Fixes (9 items): File number formatting was standardized to a "5 digits - 2 digits" structure, the admin profile page was connected to live database data, dashboard queries were updated to filter out in-progress documents, and a time-range filter was added for recent activity.
• Document & Storage Fixes (11 items): Multi-file upload support was added, accepted file types were expanded (PDF, Word, Excel, JPG, PNG), file size limits were increased, original filenames were preserved after upload, and "Not Available" / "Not Applicable" statuses were made persistent across sessions.

Follow-Up Testing

A second round of testing after the initial fixes uncovered additional edge cases, particularly around appointment lifecycle management (cancellation and rebooking flows), notification visibility across multiple users on the same strata, survey finalization logic for users with restricted property type access, and document resubmission status tracking. These were triaged and addressed in subsequent sprints.

Documentation

To support the sponsor in adopting the platform, documentation was created in both video and PDF formats. These guides walked through key workflows and features, providing a practical reference for day-to-day use of the system.

Given the sensitive nature of client documents and financial data handled by the platform, security was a foundational design principle rather than an afterthought.

• Canadian Data Residency: All data is hosted on Canadian servers to comply with regulatory requirements for handling client financial and property documentation.
• Route Security: Supabase authentication secures all API routes with role-based access control. Each endpoint validates the user's role and permissions before processing requests.
• No Public Registration: The platform does not include a public registration page. Client account creation is restricted to the company and its president, as new clients must be verified through existing business processes before gaining access to the system.
• Internal Business Tool: The platform was intentionally designed as a secure internal tool for an existing business, not a public-facing application. This design decision simplified the threat model while ensuring that only authorized personnel interact with sensitive data.