Modjen — Modular Design & Component Platform

Overview

Modjen is a modular design and component management platform that lets product teams build, version, and collaborate on design systems in real time. Think Figma for component logic — teams can compose complex component trees, preview them live across breakpoints, and publish versioned snapshots to their design system registry.

I was the primary full-stack engineer on a four-person team, responsible for the real-time collaboration layer, the component tree state engine, and the backend API.

The Challenge

The core product challenge was state synchronization. A component tree is a deeply nested, mutable data structure. When two users edit it simultaneously — one adding a child component while another updates a parent's props — you need conflict resolution that's both technically correct and feels natural to users. Naive last-write-wins would corrupt trees in ways users couldn't even detect.

Additionally, component trees could be extremely large: enterprise design systems with 10K+ components, hundreds of levels deep. Rendering and diffing these in the browser naively caused 3-5 second freezes.

Architecture & Technical Decisions

Operational Transform for Collaborative Editing

I implemented a simplified operational transform (OT) system for the component tree. Every edit is expressed as an operation (insert-node, delete-node, update-prop, move-node). Operations are stamped with a vector clock and sent to the server, which serializes concurrent edits and broadcasts the resolved operation log to all collaborators. Clients apply operations using an immutable reducer pattern, making rollback trivial.

• Operation types: insert, delete, update, move — each fully invertible for undo
• Vector clock conflict detection with server-side serialization
• Client-side optimistic application + server confirmation / rollback
• Operations stored in PostgreSQL for full edit history and time-travel

Virtualized Tree Renderer

The component tree UI used a custom virtualized renderer built on top of react-window. Only visible nodes were rendered to the DOM. Expand/collapse state was stored separately from the component tree data, allowing instant re-rendering without touching the tree structure. For very large trees, we used a worker thread to compute diff patches off the main thread.

• Custom react-window integration for infinite-depth tree virtualization
• Web Worker for off-thread tree diff computation
• Memoized subtree rendering — only dirty branches re-render
• Reduced large-tree render time from 4.2s to <200ms

Asset & Version Management

Component snapshots (JSON serializations of the tree at a point in time) were stored in S3 with versioning enabled. A PostgreSQL table tracked version metadata — author, timestamp, changelog, semver tag. Publishing a new version triggered a webhook to the client's CI pipeline, enabling automated design token updates downstream.

Results

• Real-time collaboration latency: <50ms p99 for operation broadcast
• Supported component trees with 10K+ nodes without browser performance degradation
• Zero data loss incidents across the collaboration layer in 10 months of production
• Design system teams reported 60% reduction in component documentation time
• Conflict resolution accuracy: 100% — no corrupted trees in production

What I Learned

Collaborative editing is one of the hardest problems in software. The theory (OT, CRDTs) looks elegant on paper but the edge cases are brutal in practice — especially around undo/redo across concurrent sessions. Starting with a narrower operation set (just the operations you actually need) and building confidence in each before adding more is the only sane path. We intentionally left out "paste-subtree" for three months until we were sure the core OT was bulletproof.