Two portals. One backend. Zero confusion.
The core design challenge wasn't technical. It was conceptual. Two completely different types of users needed to interact with the same underlying data in ways that could never overlap. Funeral directors manage tribute projects on behalf of their clients. The families going through the process need a clean, guided experience with no exposure to operational complexity or other clients' information.
We built a token-based access control system from scratch. Every route, every session, every database query is scoped to the correct user type at the server level before any data is returned. A funeral director can create a tribute, nominate a client, and track production status without the operational layer being visible to the family. No client can ever see another client's tribute, not through a UI bug, not through a direct URL.
The two portals share one codebase and one database. The separation is enforced entirely through the access layer, which keeps the system maintainable without duplicating infrastructure.
A schema built around a life's worth of photos.
The tribute lifecycle has more moving parts than it appears. A single tribute involves a funeral home (the business account), a nominated project, one or more contributing clients, a collection of uploaded photos and video files, per-photo notes and preferences, multiple production stages, payment state, and a final delivery confirmation. Every one of those relationships needs to be explicit, owned, and correctly scoped. A file attached to the wrong project, or a client accessing the wrong tribute, isn't a UX issue. It's a breach of trust at the worst possible moment.
We designed the relational schema to reflect the actual business model, not a generic project management structure. Every table maps to a real entity in the tribute process. Every foreign key enforces the relationship that matters. The schema is also built to extend: photo restoration services, additional collaborator types, and multi-tribute family accounts are all addable without structural changes.
Files that go straight to the edge.
Memorial photo and video uploads are large, emotionally sensitive, and often time-critical. Submitted by people who are not technical and cannot afford a failed upload, they demand a storage layer that never falters. We built on Cloudflare R2 for its combination of global edge delivery, zero egress costs, and reliability under concurrent load.
The upload flow works through pre-signed URLs generated server-side. The client's browser sends the file directly to R2. It never routes through the application server. Once stored, every file is accessible only through time-limited, ownership-verified signed URLs. There is no public path to any asset. A direct URL to a stored file returns nothing without the correct token.
Payment that feels like part of the product.
The tribute submission flow includes package selection and payment. The decision was to embed Stripe directly into the flow, not redirect to an external checkout and not use a pre-built payment UI that breaks the visual context. We built the integration from raw Stripe API calls. Package selection, payment intent creation, capture, and confirmation happen in sequence as part of the tribute journey. The user never feels like they've left the product.
This also gave us full control over error handling, retry logic, and payment state, all of which feed back into the tribute's status in the database, so the production team always has accurate information about which tributes are paid and ready to proceed.
Review, approve, and sign off. Without leaving the portal.
Once a tribute is produced, it's delivered back to the client via Vimeo Pro, embedded directly in their portal. The embed is domain-restricted: the video plays only within the Timeless Tributes platform. It can't be downloaded, shared, or accessed via a direct Vimeo URL.
The client watches, reviews, and formally approves the tribute through a sign-off step that captures T&Cs acceptance and records the approval against the project in the database. Nothing is marked as final until that confirmation exists. The production team has a single source of truth for the status of every tribute at every stage.
Security isn't a feature. It's the baseline.
The content on this platform is some of the most personal material imaginable: decades of family photos, information about people who have passed, grief context shared at a vulnerable moment. Security was treated as a first principle throughout the build, not a layer added at the end.
Every portal route is protected by server-side token validation before any data is touched. Upload endpoints verify file ownership before accepting a request. Session management, CSRF protection, and input sanitisation are implemented at every entry point. No record, file, or page is accessible without explicit, server-enforced authorisation. We documented the access model so it can be audited and extended by any developer who works on the platform in future.
