AI Image & Video Editing Platform
Media processing that never leaves the browser
Motifly is a browser-based media toolkit — background removal, smart compression, format conversion and enhancement. The defining decision was architectural: process media on the client via WebAssembly rather than uploading it to a server, which changes the cost model, the privacy story and the latency all at once.
- Type
- Browser-based media tool
- Role
- Architecture, UI/UX & full build
- Core stack
- Next.js · TypeScript · WebAssembly · Tailwind CSS
- Focus
- Client-side processing & responsiveness
The problem
The default architecture for a media tool is an upload pipeline: the file goes to a server, something expensive happens, a result comes back. It works, and it carries three costs that compound as usage grows. Every operation costs bandwidth twice and compute once. Every file becomes data you are now responsible for holding. And the round trip puts multiple seconds between the click and the result, which is fatal for a tool people expect to use iteratively.
That last point is the one that decides the product. Editing is not a single transaction — it is try, look, adjust, try again. A three-second round trip per attempt turns a two-minute task into an abandoned one.
The counter-argument to client-side processing is real: browsers were historically too slow for this, and a heavy processing bundle can block the interface entirely. Both objections had to be answered rather than waved away.
What I built
A Next.js application where the processing runs in the browser, with the interface built to stay responsive while it does.
Background removal — subject isolation performed locally on the user’s own machine.
Smart compression — size reduction targeting perceptual quality rather than a fixed quality number.
Format conversion — modern formats produced in-browser, with the decision about which format to use made for the user.
Media enhancement — adjustment tools designed for iteration, where the feedback loop is short enough to actually iterate.
The technical decisions, and why
WebAssembly on the client instead of a server pipeline
This is the decision the product rests on. WebAssembly runs the codec and vision work at near-native speed in the browser, which removes the upload round trip, removes the per-operation server cost, and means the user's media never leaves their device. Privacy stops being a policy paragraph and becomes a property of the architecture — there is no server copy to promise to delete. It also means the operating cost of a user is close to zero, which is what makes the tool viable to offer freely.
Processing off the main thread
The honest failure mode of client-side processing is a frozen tab: run a heavy WebAssembly task on the main thread and the interface stops responding, which feels worse than a slow server. Moving the work to a worker keeps the UI interactive — progress renders, controls stay live, and the operation can be cancelled. Without this, the architecture would trade a slow tool for a broken-feeling one.
Loading the processing bundle on demand
WebAssembly modules for media work are large — large enough that shipping them in the initial bundle would make the landing view slow for everyone, including visitors who never process a file. Each tool's module loads when that tool is opened, so the entry point stays light and the weight is paid only by the people who asked for it.
Choosing the output format on the user’s behalf
Format choice is a genuinely technical decision, and most people should not have to make it. The tool picks a sensible modern default and explains the trade-off rather than presenting a matrix of codecs. Exposing every option would have been less work; it would also have moved the expertise out of the product and back onto the user.
Where it landed
The client-side architecture gives the tool a feedback loop tight enough for real iteration — the try/look/adjust cycle that an upload pipeline breaks.
It also gives the product two structural advantages a server pipeline cannot match: media that never leaves the device, and a marginal cost per operation near zero. Those are properties of the architecture rather than promises in a privacy policy, which is what makes them durable.