What Inspired Us
This project started with a simple observation: designers don’t have anything close to Git inside their tools. In fast-moving teams, especially at the enterprise level, designs get overwritten, approvals happen in chat threads, and filenames like final-v3-really-final-this-time become the actual workflow.
We wanted to bring structure to that chaos — things developers take for granted — like branching, reviewing, and rolling back. And we wanted to do it inside Adobe Express, without making designers learn Git or developer tooling.
At its core, Stream was inspired by three beliefs:
- Designers should be able to experiment without fear
- Collaboration should include reviews and approvals
- Mistakes should be reversible in seconds
What We Learned
Going in, we thought we were just building “version control for design.” What we actually learned is that version control is about trust.
For designers to trust Stream, it must restore a snapshot perfectly, not “close enough.” That means fonts, alignment, rotation, colors — every detail that makes a design feel right.
Along the way, we learned:
- Saving JSON isn’t enough — snapshot fidelity matters
- The Adobe Express sandbox has rules that shape architecture
- Enterprise workflows need roles, review history, and audit trails to feel complete
Those were surprising lessons, especially under hackathon time constraints.
How We Built Stream
Stream ended up being a real full-stack product with three major parts:
1. Panel UI (in Adobe Express)
This is the part designers see. Here they can:
- Create canvases (like branches)
- Switch between them
- Ask for reviews
- Blend approved changes
- Revert mistakes
2. Sandbox Runtime (the “document engine”)
This is where the actual design data moves in and out. It:
- Exports the current design into a structured snapshot
- Rebuilds a design from a snapshot
- Ensures high visual accuracy
3. Backend (Node + Express + MongoDB + Storage)
This handles:
- Projects and teams
- Canvases and review requests
- Snapshot storage (like Git objects)
The result is a workflow that feels natural for designers, but has the safety and structure developers are used to.
What Stream Can Do Today
Here are the major things we actually shipped:
- Canvas switching (like Git branch checkout)
- Auto-saving snapshots
- Auto-loading snapshots
- Detecting unsaved changes
- Review requests with:
- Approval
- “Request Changes”
- Activity timeline + comments
- Blending strategy (approved canvas overwrites target)
- Rollback support (go back to any previous snapshot)
- Role system
- Manager = full control
- Designer = limited actions
- Real image handling
- Serialize + restore images with size and base64
It’s not just a UI — the system actually works end-to-end.
Challenges We Faced (and How We Solved Them)
1) The Sandbox Didn’t Support Modules
We assumed we could write modular JS and import it. The sandbox rejected that completely.
What happened:
"Add-on-provided modules are not supported"
What we did:
Merged everything into one file (code.js), but kept it readable through careful comments and sections.
2) Editing the Document Has Strict Rules
Adobe Express only allows edits inside a specific async context.
What happened:
Errors like:
"Editing the document is not permitted in this context..."
What we did:
Wrapped all edits in editor.queueAsyncEdit() and restructured async flows.
3) Merging Behaved Incorrectly
Merges didn’t always overwrite the target canvas or save the source state first.
Fix:
- Save source snapshot before blending
- Overwrite target snapshot completely
4) Images Were Painful
Images rendered black, or wrong size, or needed special nodes.
Fixes included:
- Validating base64 loading
- Carefully constructing bitmaps
- Restoring display rectangles instead of raw bitmaps
This gave us high-fidelity image restore, which was a big milestone.
Why This Matters for Enterprises
Enterprises care about:
- Audit trails
- Approvals
- Accountability
- Rollback
- Recovery
Design teams lose time every day due to accidental overwrites and unclear approvals. Even a small reduction matters at scale.
What We’re Proud Of
- We built more than a demo — it’s a working collaboration system
- We respected the constraints of a real production SDK
- We restored text, shapes, and images with fidelity
- We made something that feels like Git for design, but without exposing Git
That’s a big deal for a 24-hour build.
What’s Next
If we had more time, we’d love to add:
- Cloud snapshot storage (S3 / GCS)
- Visual + metadata diffs between canvases
- Real user accounts and invites (instead of role toggles)
- Real-time presence via WebSockets
Built With
- add-on-sdk-document-sandbox-backend-framework:-node.js
- adobe
- adobe-creative-cloud-web-add-on-sdk
- adobe/ccweb-add-on-scripts-cloud-services:-render.com-(backend-hosting)-apis:-adobe-express-api
- bcryptjs
- cloud
- cors
- creative
- crypto-development-tools:-nodemon
- css-frontend-frameworks/platforms:-adobe-express-add-on-sdk
- express-document-sdk
- express-validator-real-time-communication:-socket.io-(websockets)-file-handling:-multer-utilities:-dotenv
- express.js-database:-mongodb
- helmet
- html
- languages:-javascript-(es6+)
- mongoose-authentication-&-security:-jwt-(json-web-tokens)
- uuid
- web
Log in or sign up for Devpost to join the conversation.