The Client Does Not Need My File Management System
The reason I built a delivery interface instead of sending clients a storage link.
Why I keep the storage workflow on my side and give clients only the interface they need.
Delivery is not file management
When I deliver video files to a client, I already have a system for storing them.
The files are organized in folders. They have filenames. They live in Google Drive. From my side, this structure makes sense because it is part of the production workflow.
But the client does not need that system. They do not need to understand why one folder exists, how the files are organized, or how I manage the material internally.
They usually need to do only a few things:
Preview the videos.
Select the ones they need.
Download the files.
Everything else belongs to my side of the workflow.
A storage interface is not a delivery interface
Google Drive works well as storage.
That does not mean its interface is always the right interface for delivery.
A folder full of video files asks the client to think in terms of files and folders. Open a folder. Find a filename. Open a file. Go back. Open another one.
None of those actions are difficult.
But they are not the actual task.
The task is to look at the work and judge which files matter.
There is a tendency to expose whatever system already exists, because it is convenient. If the files are already in Drive, sending a Drive link is the shortest path.
But the shortest path for the person delivering the files is not necessarily the simplest path for the person receiving them.
The interface should remove that internal structure rather than explain it.
Not every delivery needs a review platform
The opposite direction can also create unnecessary complexity.
A full review platform can add comments, approvals, user accounts, notifications, version management, timecode notes, and other collaboration features.
Those systems are useful when the work actually requires them.
But not every delivery does.
Sometimes a client only needs to see a set of finished videos, identify the relevant ones, and download them.
In that situation, adding a larger workflow does not make the delivery more professional.
It simply adds another system to learn.
Keep the source of truth where it already is
I did not want to upload the same files into another service just to create a better viewing experience.
The files already existed in Google Drive.
So I kept Drive as the source of truth and built the Client Video Portal as a thin interface in front of it.
It does not become another media library. It reads the videos from the existing Drive folder and presents them as a simple gallery.
The client can preview, select, and download without seeing the Drive interface itself. They never need to know about Drive permissions, media proxying, or how the portal is deployed.
Large files that are not set up for browser preview are not treated as errors. They can simply be downloaded when they are needed.
The storage remains storage. The portal only changes how the delivery is experienced.
Selection does not need to become a database
The same principle applies to selection.
If a client marks a few videos, I do not necessarily need to create a user account, a project database, or a persistent approval system.
For this workflow, selection can remain lightweight.
The browser remembers the selected files locally. The client can copy the filenames or export the selection as CSV or JSON.
Nothing has to be written back into Google Drive.
Nothing changes the original files.
The selection exists only to help complete the delivery.
That boundary is intentional.
The delivery system should not become another project
This became more important once I started using the portal for multiple clients.
I did not want every new project to require another deployment, another set of environment variables, or another copy of the application.
That would replace one form of operational friction with another.
Instead, I moved the project boundary into the Drive structure itself.
Each client project can live inside its own folder under a common parent. The folder defines the project, while a small configuration file defines its title, password, and delivery settings.
A new delivery can then be created from the storage side without rebuilding the system around it.
The portal remains one tool.
The projects remain separate.
Interface after storage
This is the principle behind the Client Video Portal.
I did not build it because Google Drive cannot store video. I did not build it because I needed another review platform.
I built it because storage and delivery are not the same problem.
The files can remain where they already belong. What changes is the interface placed in front of them.
FrameBase sits at the other end of the same job. It creates the structure before the media arrives. Here the structure already exists, and the only new thing is the interface in front of it. Structure before media, and interface after storage.
The client never needed my file management system. They needed a clear way to see the work, make a decision, and receive the files.
The Client Video Portal grew out of that distinction.