Organised the way the business thinks, not the way the files arrived.

The problem

Every project a developer builds produces photographs: progress week by week, drone footage, renderings, site plans, finished interiors, a logo from 2019.

Over a few years that is thousands of files in folders named by whoever created them. Finding the right exterior shot of one building means asking the person who remembers where it is, and when they are away the document goes out with the second-best photograph.

The file that does get found is a twelve-megabyte camera original, and it goes onto a page an investor opens on a phone.

A digital asset manager would have meant a licence, a migration and training for a team that would have gone on using the folders anyway. This is the small version instead.

It is organised the way the business thinks

Assets belong to a project and are typed within it — photographs, video, logos — with counts on each, so what exists is visible before anything is opened. A project opens to everything it has in a grid, split by kind, and new files are dragged straight onto it. Projects filter by asset class: senior living, behavioural health, multifamily, commercial, hospitality. The business's own vocabulary, not a taxonomy invented for a filing system.

Files used to be organised by who uploaded what, when — how the material arrived. The library is organised by what it is of, which is how anybody looks for it.

Nobody had to change how they work

The team already used a shared file service and was never going to stop. Every internal tool that begins with first, everyone needs to start doing this differently dies quietly.

So the file service stays the home of originals. A file dropped into the project folder is picked up immediately, with a sweep every fifteen minutes to catch anything missed; one uploaded through the library is written back. Nobody was asked to adopt, retrain or migrate — the library is authoritative about structure and delivery, the file service about the original file.

The rest of it

• Four versions from one upload. A thumbnail for the grid, a web version for a page, a web-native version of any video, and a poster frame. Nobody thinks about formats and no page is optimised by hand.
• Made in the background. One asset at a time, at the lowest possible priority, so it never competes with the people using the tools.
• Addressed by key, never by path. Paths leak the structure of a business and can be guessed at; a key is neither guessable nor descriptive.
• The original is never served. Only derived versions are reachable, whatever is asked for. The twelve-megabyte file sits in one place and no investor's phone downloads it.
• It supplies the offering pages, and lives inside the operations record. The photograph at the top of an offering page comes from here; those pages hold no imagery of their own, exactly as they hold no project data. The same component is mounted inside the operations record without its own header — a section of the system, not a second application to find, and only one of it, so it cannot drift.

What changed

• Finding a photograph stopped going through a person. 53 assets across 7 projects, organised by project and kind rather than by who uploaded them. Nobody is the index now.
• Nobody changed their habits. Two-way sync with the file service the team already used meant adoption cost nothing — there was nothing to adopt.
• Pages stopped carrying camera originals. Four versions per asset, generated automatically. Originals are never served — not once, to anyone.
• Structure and originals both have one home. The library owns organisation and delivery, the file service owns the original file, and neither is reconciled against the other.
• The offering pages got a supply side. Imagery is catalogued once and reused everywhere, so a better photograph replaces a worse one in one action, not in six documents.

---