Every client engagement starts with the same email. "Could you send us your logo, a few photos and the brand PDF?" What comes back is a Drive link, a Dropbox request, two WhatsApp images and a PowerPoint. Three months later the site's hero image lives in Drive, the Instagram crop lives in Dropbox, and the approved logo is in a chat thread nobody can search.
I run SharpHaw, a small agency in Lisbon, and I built SharpOS, the workspace we run every client in. This series takes our replacement ledger one row at a time. This row: Google Drive and Dropbox, and the surface that stands in for them, Media Center.
TL;DR: a shared folder stores files. A client workspace needs a library that every other surface writes into and reads from, so an image uploaded anywhere is the same asset everywhere. That is the whole design, and it has real limits.
What a shared drive is for, and where it strains
Drive and Dropbox are good at the job they were built for: a folder tree, sync to a laptop, a share link, permissions per person. For a company's own documents that is exactly right, and I'm not going to pretend an agency workspace does any of that better.
Where it strains is the client relationship, and the r/agency threads on this are blunt. "We frequently run into issues with clients not having Gmail accounts or Gmail connected work emails and having them set that up is annoying." Another agency creates a folder per client, shares it, then asks the subreddit how to take it back when the engagement ends. The failure is structural. The folder belongs to someone's account, the link belongs to whoever was emailed it, and the files end up wherever the last tool needed them. Nothing about a folder knows that the file inside it is the cover of a page, the logo in a brand kit, or the image a form respondent uploaded ten minutes ago.
What Media Center does instead
Media Center is the organisation's shared file library: images, documents, video and other approved files, uploaded once, organised into nested folders, searched, and reused across the product. Every org member can browse it. Uploads, moves, renames and deletion sit behind the asset-edit right, checked at the route and again in the client. The Media Center feature flag gates the route and the save and delete mutations server-side, like every other surface in the workspace.
The part that matters is what else writes into it. A cover set on a page or a board card, an image property on a card, a media field on a public form, an image pushed over the API: all of them register in the same library. Form uploads land in an auto-created a Forms folder named after the form folder keyed to the form id, so renaming the form doesn't orphan the folder. REST callers get folder and asset CRUD, moves and both upload paths, through the same Media Center flag and the same capability the hub checks. There is one asset pool per organisation, and every surface is a door into it.
You can open one and click around: the Media Center inside a showcase workspace. It runs on fixtures in your browser, no account, nothing persisted.
How it works
Storage follows the same pattern everywhere in SharpOS: the browser asks for an upload slot, sends the bytes straight to storage, then records the asset — its name, type, size, folder, tags and what kind of preview it gets — as a small record that points at the stored file rather than containing it. Two decisions I'd defend in a review.
Validation reads storage, never the caller. File types are filtered before upload for the user's benefit, then enforced again when the asset record is created, from what storage itself reports about the file, never from a type or size the client claimed. That one backstop is shared by the hub, by form uploads from strangers, and by the API, so there is no path where a caller's claim about a file is trusted.
Two-step uploads because of a proxy cap. Production API traffic goes through a proxy that caps request bodies at 20 MB, while an organisation's upload limit reaches 250 MB. So the API mirrors the hub's flow: ask for an upload slot, send the bytes directly, then register the asset. A one-call route that takes a public URL or an inline payload exists for anything under the cap. Deleting a folder over the API requires an explicit "recursive" flag when the folder isn't empty; the hub can afford a confirm dialog, an API caller cannot.
Browsing is paged at 48 records, and a page never resolves preview URLs up front. Previews are requested separately for the files a new page added, deduplicated, and refused above 60 at a time. The upload bar reports real bytes sent rather than an animation, because I wanted the percentage to mean something.
What it doesn't do
Media Center is shallower than Drive or Dropbox, on purpose, and you should know where.
There is no desktop sync client and no offline copy. There is no version history on a file; you upload the new one. There is no share-with-an-outsider feature: access is membership, a public form's respondent can upload in, but nobody outside the organisation browses the library. There is no document editing in place; the collaborative writing surface in SharpOS is Pages, and Media Center is where Pages puts the images. Deleting an asset that a page or card still uses as its cover leaves a stale reference the cover UI treats as empty, rather than blocking the delete.
If the job is the client's own company files, keep the drive. If the job is the files the engagement produces and consumes, the library is where they should already be.
Where it sits in the service
Every SharpHaw subscription runs inside SharpOS, and Media Center is the asset pool under the Content Engine: the photos, exports and brand files a week's content draws on sit next to the pages and boards that use them. The SharpOS overview shows the rest of the workspace, and the feature page has the walkthrough.
The question I'd ask you
If you've moved a team off a shared drive into something purpose-built, what did people quietly keep using the drive for? That list is usually the honest spec for what the replacement still lacks.
This is part of SharpOS, surface by surface. Part 1 covers the whole ledger and the row we couldn't replace: https://dev.to/sharphaw/we-replaced-a-12-tool-client-stack-with-one-workspace-we-built-heres-the-row-we-couldnt-pg3
Top comments (0)