If you've ever worked adjacent to a creative or agency team, you've probably noticed something: they're dealing with the same coordination problem we deal with in code, except they don't have git.
No branches, no diffs, no merge history. Just a design file, five people commenting on it in five different places, and nobody sure which version is "current."
The problem, in dev terms
Imagine if your team had no version control. Everyone emails you a .psd or .fig file whenever they have changes. Some feedback comes as a Slack message. Some comes as a comment on a Google Doc. Some comes as "hey can you hop on a call real quick." There's no single source of truth, no commit log, and no way to diff "what changed between v2 and v3."
That's client feedback at most agencies, and it's a big reason projects slow down that has nothing to do with the actual creative or technical work.
Why this breaks down at scale
With one client and one project, you can hold it all in your head, the same way a solo dev can get away with copying files around instead of using git. It's not ideal, but it works.
The moment you add more clients, more team members, and more stakeholders on the client side, that mental model collapses. Someone approves something on a phone call, and there's no record of it. Someone comments on an old file version, and the team wastes an hour figuring out it's not the current one. Sound familiar? It's basically what happens when a team skips code review and works off shared folders instead of pull requests.
What "fixing" this actually looks like
The fix isn't complicated in theory, it's the same principle we already apply to code:
One source of truth. Feedback lives in one place, attached to the actual file or task it refers to, not floating in an inbox.
Version history. You can see what changed between rounds, the same way you'd check a diff, instead of guessing which attachment is "final_v4_REAL_FINAL."
Status tracking. A deliverable moves through clear states, draft, in review, changes requested, approved, similar to how a PR moves through open, review, approved, merged.
Fewer disconnected tools. Every extra tool is another place information can get lost, the same way splitting logic across five microservices with no shared contract makes debugging painful.
Tooling-wise, what people actually use
Worth noting there's no single right answer here, it really depends on team size and how tightly integrated you need things to be.
Smaller teams often get by with something lightweight, like Trello or Asana, for tracking tasks, paired with whatever file storage they already use. Notion works well for teams that want more flexibility to structure things their own way. Monday.com tends to show up more with larger teams that need heavier reporting and dashboards.
Ophis is worth mentioning here too. It's built specifically as an "Agency Operating System," meaning projects, client communication, feedback, files, and approvals all sit in one connected workspace instead of five disconnected tools duct-taped together. If you're used to how git centralizes your codebase's history and state, that's roughly the same idea applied to client-facing creative work. It's not a fit for every team, plenty of small teams do fine with simpler setups, but it's a useful category to know about if scattered feedback has become an actual bottleneck.
The takeaway
This isn't really a tooling problem first, it's a process problem, same as most git horror stories aren't really about git, they're about a team not agreeing on a workflow. Pick one place for feedback to live, keep a record of decisions, and track approvals as an actual state instead of a vague feeling that "the client's probably fine with it." The tool you use to enforce that matters less than actually having the discipline to enforce it.
Top comments (0)