What a wedding content brand taught me about database design
A client of mine runs a content production business — they shoot content for wedding vendors and local brands. When we started working together, "tracking the business" meant memory, DMs, and whatever the founder could recall when someone asked "wait, did we deliver the reels for that shoot yet?"
It worked, until it didn't. And the way it broke down turned out to be a database problem I've solved a dozen times before — it just didn't look like one at first, because there was no database in sight yet.
The mistake: treating a shoot like one thing
Early on, if you'd asked the founder to describe "a shoot," they'd have described it as a single event. Client hires them, they shoot, they deliver. One thing, start to finish.
But that's not what a shoot actually is. A single shoot might produce three reels, two photo sets, and a testimonial clip — each with its own status, its own deadline, its own revision requests. One client might book multiple shoots across months. And separately from all of that, there's a content calendar deciding when each finished piece actually goes live.
Treating all of that as "one thing to remember" meant that as soon as there was more than one client active at once, things started slipping. Not from a lack of organization — from trying to hold a many-to-many relationship in your head like it was a single fact.
This is, almost exactly, the mistake I see in early-stage software all the time: modeling something as one flat record when it's actually several related things that each need to be tracked on their own.
What we actually built
Once we recognized the shape of the problem, the fix was familiar. We built it in PostgreSQL, structured as:
Clients — the business or person being shot for
Shoots — linked to a client, one row per shoot date/event
Deliverables — linked to a shoot, one row per individual piece of content (a reel, a photo set, a clip), each with its own status
Content calendar — linked to deliverables, tracking when each finished piece is actually scheduled to publish
Each level links to the one above it. A client can have many shoots. A shoot can have many deliverables. A deliverable has one calendar slot. None of that is exotic schema design — it's the same "one-to-many" relationship you'd use to model orders and order items, or authors and blog posts. The insight wasn't the technique. It was noticing that this small creative business had the exact same shape as the systems I build for much larger clients, and nobody had thought to apply it yet.
What changed once the data had a shape
The obvious thing improved first — nothing gets lost. The founder can see exactly what's shot, what's edited, what's delivered, and what's scheduled, without reconstructing it from memory or a DM thread.
But the less obvious benefit mattered more: once shoots and deliverables were separate, trackable things, patterns became visible. Which clients generate the most deliverables per shoot. How long a deliverable typically sits between "shot" and "published." Where the actual bottleneck was — editing, not shooting. None of that was visible when a "shoot" was one blurry memory instead of a set of rows you could look at.
The takeaway
Most small businesses don't need a database in the literal sense. But they run into the same failure mode software does: treating a multi-part process as one flat thing, until the parts start falling through the cracks. If a business is tracked in someone's head, or in a spreadsheet that's turned into one giant undifferentiated list, the fix isn't necessarily "get more organized." It's asking what the actual separate, related things are — and giving each one a place to live on its own.
I work as a full-stack engineer, and I take on exactly this kind of problem for small businesses and teams — not just big platforms. If your business's information lives in someone's head or a spreadsheet that's stopped making sense, that gap between "messy" and "modeled" is smaller than it looks. I'm easy to find.
