The Brief
Montra was building a desktop-class video editor that ran entirely in the browser.
I joined as Lead Three.js Developer with responsibility for the product’s real-time graphics work. My role was to build production features at the point where media, editor state, interface controls, and the Three.js runtime met.
This was commercial creative tooling rather than a campaign site or isolated visual experiment. The graphics layer had to behave as part of an editor people could repeatedly use, not simply produce an impressive first render.
Why a Browser Video Editor Is Difficult
A video editor contains several systems with different ideas of time and state. Media playback advances continuously. The interface responds to user input. Application state records edits and selections. The graphics runtime has its own render loop.
Those systems cannot drift apart. A change in the editor must be reflected in the rendered scene and media output, while playback must continue to represent the current application state. Small synchronization errors quickly become visible and undermine trust in the tool.
The browser adds another constraint: the product has to deliver desktop-like behaviour inside an environment originally designed around documents and short-lived page interactions.
Leading the Three.js Work
I was responsible for the product’s Three.js development, building features that connected real-time graphics to the rest of the application.
The work required more than writing scene code. I had to reason about where state should live, how editor actions should reach the graphics runtime, and how rendering behaviour should remain predictable as users moved between playback and editing.
As lead, my focus was on making the graphics system support the product around it. Visual output, media behaviour, interface feedback, and application architecture had to be considered together rather than handed off as separate concerns.
The Technical Foundation
The core stack used TypeScript, React, Next.js, React Three Fiber, Three.js, and WebGL.
React and Next.js provided the application structure, while React Three Fiber connected component state to the Three.js runtime. TypeScript was particularly important in a system where media objects, editor controls, application data, and rendered entities passed information across multiple layers.
I worked to keep the boundary between interface state and render state explicit. When an editor value changed, the graphics layer needed a controlled way to respond without turning the entire product into one tightly coupled render loop.
From Demo Quality to Product Quality
Many browser graphics projects are evaluated through a short, directed interaction. Creative software is different. Users make repeated changes, scrub through media, revisit decisions, and expect the same action to produce the same result every time.
That changes the engineering standard. A feature is not complete because it looks correct once; it has to remain synchronized with application state and media playback throughout a working session.
My contribution was to bring that product discipline to the real-time layer: treating Three.js as part of the application architecture rather than a visual surface added after the editor was designed.
The Outcome
I delivered production Three.js features inside a demanding browser-based creative application and led the work required to connect them to the wider editor.
The role demonstrates a different side of my real-time graphics experience from the metaverse and visualization projects. I can work inside an established product, take ownership of a specialised technical domain, and make it cooperate with complex media and application systems.
Montra shows that my Three.js work is not limited to portfolio experiences. I can apply the same rendering knowledge to serious creative tooling where reliability, state design, and usability matter as much as visual quality.