Content engine
StoriHQ
The system that keeps my client brands publishing: from a photograph library to a scheduled, rights-checked queue, without the whole thing resting on anyone’s memory.
The problem
A brand’s photographs are usually its most neglected asset. After every shoot, hundreds of frames go into a folder and are seen twice: once when they’re delivered, and once more when somebody, months later, needs “that photo of the pool” and can’t find it. Meanwhile the posting schedule runs on whoever remembers, and the question of whose photo it is, and whether it may be published at all, is answered by hoping.
Consistency is not a personality trait. It’s a system, and most brands are asked to supply it out of willpower.
How it works
1 · Catalogue
Point it at the source folders and it reads every photograph and video with Claude’s vision: describing each frame, tagging it, and filing it in a searchable catalogue, with the photographer, the event, and the usage rights stamped on from the folder it came from.
2 · Write
Pick photos, or just describe a campaign idea and it suggests them, and it drafts copy in the brand’s own voice for Instagram, Facebook, Stories, LinkedIn, Threads, or a long-form blog post with the frames as hero images. Drafts land in a review table; nothing publishes itself.
3 · Queue
Approved drafts move to the publish queue only after two checks: that the photo’s rights actually allow it, and that the copy fits the platform’s limits. Anything that fails is blocked, with the reason written next to it.
In use
781
Photos and videos catalogued for one brand alone
6+
Platforms written for, from one selection
100%
Of published photos traceable to a photographer and a permission
How it’s built
Python under the hood, Airtable as the catalogue and review surface, because clients already know how to use a table, and Claude for the eyes and the pen. It grew out of running content for Kahana Baler and now serves the other brands I photograph; each new one is a folder, not a project.