Sevro

A non-destructive node-based procedural image processing sandbox directly in the browser.

Sevro started in October 2025 as a node-based image editor in the browser. The original goal was a fully procedural pipeline for graphic design.

Most image editors encourage you to work destructively. You make an adjustment, paint over something, flatten a layer and continue. That is fast until you need to change an early decision or produce twenty variations of the same asset. Then the document becomes a history of decisions you can no longer properly see.

With Sevro, each operation is a node. An image can be loaded, transformed, blurred, recoloured and combined while every step stays visible in the graph. Change an input near the beginning and the rest of the image is rebuilt from it. It is closer to a small graphics program than a conventional image document.

The first public Sevro build, showing an image canvas, node graph and parameter panel

The first public build of Sevro, posted in October 2025.

The early editor already had the basic relationship I wanted between the canvas, the graph and the currently selected node. The viewport showed the result while the graph remained the editable source of that result.

An early Sevro composition combining multiple image-processing branches

An early composite built from image, colour, mask, position and layer nodes.

One of my first proper tests was a film halation effect. Building it as a graph meant the effect was no longer attached to one photograph. It became a reusable process that could be adjusted and applied to anything.

A monochrome motorsport image processed with an early Sevro graph

Tool or product

Once the editor worked, I got stuck on a more difficult question: what was Sevro actually for?

There were two plausible directions. It could be a creativity tool for people who enjoy constructing their own visual systems, or it could become a business tool for automating repetitive image production. The same graph could power both, but the products around it would be very different.

The creative version needed video and real-time processing before it could become more than an interesting toy. At that point I would be rebuilding a slice of TouchDesigner in the browser. The automation version needed accounts, storage, collaboration and a convincing market. Even a generous storage allowance disappears quickly when every user is working with source images and generated outputs.

I briefly explored the second direction. I built a backend, added AI image nodes and let people connect their own API keys. The result could create complete AI image pipelines in the browser, with generation and processing living in the same graph. It worked, but it also made the shape of the business problem clearer. The potential audience was specialised while the infrastructure needed to serve them was not.

This is one of the useful things about building past the exciting prototype. A product idea can sound coherent until it meets storage bills, user expectations and the awkward question of who will pay for it.

how many 8k advertising images could I realistically store?

What remained

I wrapped up Sevro in 2026. It did not become a SaaS business or the browser version of TouchDesigner, but it became a capable procedural image sandbox. It also gave me practical patterns for node editors, parameter systems, image pipelines and the boundary between a graphics engine and a React interface. Some of those lessons went straight into other work.

The tool is still online because it is fun to use and because the central idea still feels right. A creative process is easier to understand, reuse and change when its structure is visible.

Open Sevro or watch an AI image pipeline running in the browser.