We spent two years building an MVP that was basically “git for design”.
Not a metaphor. Actual version control over Adobe Illustrator and Photoshop files.
At the time, it sounded insane in the best way.
Like one of those ideas that makes you feel smart just for thinking it.
The core bet was brutal.
We had to invent a text-based format that stayed 100% compatible with Adobe files.
Git-friendly. Diffable. Mergeable.
And not in the “kinda works if you export” way.
Real compatibility.
If we missed it, even slightly, the product didn’t exist.
The first cliff: compatibility
That decision dictated everything.
It meant deep integration with Illustrator and Photoshop. This was pre-Figma dominance. Pre-AI hype.
Back when the default “collaboration workflow” was emailing a file called: final_v12_REAL_final_2.ai
We built a format where each new version didn’t store the whole file again.
It stored the change.
If you moved a layer, we stored that.
If you changed a color, we stored that.
Not a full 200MB blob with one pixel different.
That part felt like engineering purity.
Also, it was hell.
Adobe’s SDK wasn’t a friendly place to live.
Lots of undocumented edges. Lots of “we’ll just try it and see what breaks”.
Weeks where something worked on one machine and refused to exist on another.
You know that feeling when the bug isn’t a bug, it’s just a new law of physics you discovered?
We lived there.
But here’s the thing.
Compatibility was only the first cliff.
The second cliff: humans
Even if you solve the tech, you still have to insert yourself into a designer’s workflow.
And designers are not sitting around waiting to learn git.
They don’t want branches, merges, and conflicts.
They don’t want to think about history graphs.
They don’t want “resolve these changes” dialogs.
They want three simple outcomes:
My file is safe.
I can collaborate.
Nothing weird happens.
That’s it.
The workflow was the real fight
So we had to build a visual git workflow that made sense to designers.
Diffs you can actually understand.
Branches that look like choices, not commands.
Merges that feel like magic, but never destroy work.
We tried everything.
We made diffs visual.
We made branching feel like “try this direction” instead of “create branch”.
We tried to hide the ugly parts and keep the safety.
And for a while… it worked.
The MVP existed.
You could do real versioning.
Real collaboration.
Real merging.
You could do the thing everyone complains doesn’t exist.
And still… we couldn’t change habits.
Not enough to survive.
Because the hard truth was simple:
We didn’t just build a tool.
We asked people to adopt a new brain.
Designers already had a workflow.
It wasn’t perfect. It was messy and chaotic and full of “final_final”.
But it was theirs.
And ours was new.
Even if ours was “better”, it came with a cost.
A cost in attention.
A cost in trust.
A cost in fear.
Because when your work is visual, a broken merge is not a broken build.
It’s a broken day.
So every bit of complexity we introduced, even if hidden behind UI polish, created anxiety.
Trust was the feature
We thought the product would live or die on correctness.
So we obsessed over correctness.
We built conservative merges.
We built safety rails.
We built “nothing can break” systems.
But the emotional bar wasn’t “does it work”.
It was “do I trust it”.
And those aren’t the same thing.
When your work is visual, you don’t forgive glitches.
You don’t debug them.
You just stop trusting the tool.
And once trust is gone, people don’t complain.
They quietly go back to the old way.
The scar
That’s the scar I kept from it:
Deep tech is rarely the hard part alone.
The hard part is making it feel obvious to someone who never asked for your complexity.
And if I’m honest, we were naive about that.
We acted like the world was waiting for this.
Like the pain was obvious, so the solution would be obvious too.
But workflow change is not a feature.
It’s a tax.
People only pay it when the pain is unbearable, or when the transition is invisible.
We had neither.
We built something heavy. Powerful. Correct.
But it wasn’t inevitable.
If I could go back, I’d test the human part first.
Not with surveys. Not with “would you use this?” interviews.
I mean the real test:
Put it in front of a designer on a real project.
Stay there while they work.
Watch the moment they get annoyed.
Watch the moment they stop trusting it.
Watch the moment they quietly go back to the old way.
Because that moment decides if the product exists.
Not the architecture.
Not the format.
Not the compatibility checklist you’re proud of.
The moment they decide: “This feels safe.”
Or: “This feels like extra work.”
Years later, that’s still what I remember.
Not the clever parts.
Not the optimizations.
Not the impossible Adobe edge cases.
I remember realizing that we solved a problem nobody wanted to think about.
And that’s a painful lesson for technical founders, especially the ones like me.
We love hard problems.
We’re attracted to them.
Sometimes we even confuse “hard” with “valuable”.
But deep infrastructure only wins when it disappears into someone else’s world.
And if it doesn’t disappear, it doesn’t matter how perfect it is.
It’s just a beautiful machine sitting in a garage.
