David versus Goliath: why I built Scissor
You learn their tools for a decade, you file everything in their formats, and then one day the thing you bought becomes a thing you rent
[Almost Ad] This one is about Scissor, which I make. scissor.studio ↗
I did not set out to build a vector editor. I set out to open a file.
The drawing was mine. The hours in it were mine. The only program that could open it properly belonged to a company I had been paying for years, and on that particular morning it would not open anything, because the terms had changed again and my licence had quietly stopped being a licence.
That is the part people underestimate about an ecosystem. It does not feel like a trap while you are walking into it. It feels like competence.
For years I learned those tools properly. Every shortcut sat in my fingers. Every file I produced was in their formats. Every tutorial, every plug-in, every habit, every piece of work I had ever handed to a client was shaped around one company’s decisions. That is what being good at a tool means: you pour yourself into it.
And then the model changed underneath all of it.
The thing I had bought became a thing I rent. Stop paying and your work does not legally stop being yours, which is the sentence everyone hangs the policy on. In practice you cannot open it, cannot edit it, cannot hand it over, and the archive you built across a decade turns into a folder of files you can look at the names of.
I do not think that is theft. It is something quieter and smarter: a business model that runs on the cost of leaving. They do not need to make the product better than the alternatives. They only need to make switching more expensive than paying.
That is the actual trigger for Scissor. Not a gap in the market, not a belief that I could out-engineer a company with thousands of people in it. A bill, and the realisation that the bill would arrive every month forever because of choices I made in my twenties.
So I asked a different question. Not how do I build something better than them, but how do I build something that cannot do this to anyone.
That constraint turned out to be the whole design.
What I actually wanted
The list was short, and every item on it is a reaction to the paragraph above.
- It opens in a tab. No download, no licence key, no waiting.
- My artwork never leaves my machine. Not as a setting, but as an architectural fact: there is nowhere to upload it to.
- It reads the files I already have, rather than demanding I convert my life into a new format first. Lock-in is the thing being solved, so it cannot be the thing being sold.
- It is fast enough that I forget it is in a browser.
- It still works when the network does not.
Every one of those is achievable now in a way it was not five years ago. The File System Access API means a web app can open a file from your disk and write back to the same file. Service workers mean the whole program can be cached and run offline. And WebAssembly means the parts that have to be quick can be quick.
The engine is the whole trick
Scissor’s document model and its geometry are written in Rust and compiled to WebAssembly. The interface is plain JavaScript over the top, hand-written, no framework.
That split matters more than it sounds. Vector editing is mostly geometry: hit testing, boolean operations on paths, offsetting, flattening curves, text layout. Those are the operations that make an editor feel slow when they are slow, and they are exactly the operations a browser’s JavaScript engine is least suited to doing thousands of times per frame.
Putting them in a compiled language, and leaving the DOM to do what the DOM is good at, is the difference between a demo and a tool.
The interface being hand-written is a smaller decision that I keep being glad about. There is no render loop fighting me, no reconciliation layer between a click and a shape moving. When something feels wrong I can find the code that caused it in about a minute.
About the help
I should say plainly that I did not type all of this myself. A good part of Scissor was written with an AI sitting in the editor next to me, and anyone claiming a solo build of this size in this time is leaving that out.
The first weeks were remarkable. Boilerplate evaporated. Panel after panel appeared in an afternoon. Parsers I had been putting off for a month turned up before lunch.
Then the ratio shifted, and most of my day became argument.
No, that is not what a curvature tool does. No, you have just deleted the thing that worked. No, the boolean operation cannot be approximate. Yes, I know it compiles. It is still wrong.
There is a specific kind of tiredness that comes from reviewing code that is confident and incorrect. It reads well. It has tidy names and a sensible structure. It is simply built on a misunderstanding of the geometry, and finding that out takes longer than writing it would have.
By about week six we were fighting over the mouse and the keyboard like two people sharing one desk, except only one of us gets to be visibly annoyed about it, and it is not the one with the API.
The honest accounting: it made the boring seventy percent much faster, made the subtle thirty percent slower, and the project still shipped sooner than it would have alone. I would do it again. I would also budget more time for the arguing than anyone’s marketing suggests.
What one person can and cannot do
I am not going to pretend this is an even fight. The incumbents have decades of accumulated behaviour in them, and a lot of that behaviour is correct, hard-won, and invisible until it is missing.
What I have instead is a short line between deciding something and shipping it. No committee, no quarterly planning, no obligation to keep a feature alive because an enterprise customer signed a contract about it in 2011. If a tool feels wrong on a Tuesday it can feel right on a Wednesday.
That is the only real advantage, and it is a genuine one. It is also why I keep the scope honest: a .ai file is read through the PDF path and never written, EPS is run as the PostScript program it is, and import fidelity for layered image files is good rather than perfect. I would rather say that plainly than claim parity I cannot back.
Where it is now
The current build has the things a drawing program needs before anything else is worth doing. The pen and curvature tools, live shapes, boolean operations, boards with their own grids, gradients, patterns, type with right to left support, pixel layers to paint on, effects that preview as you change them, and export to the formats people actually need to hand over.
The newest work was the interface itself. A command palette, so you can type the name of a command instead of hunting for it. Panels that dock, tear off and remember where you left them. A board strip along the bottom. Grids per board, including isometric and perspective, which turn out to be the quickest way to make a drawing look deliberate.
What comes next
The honest answer is that I do not keep a public roadmap, because I have watched too many of them become apology letters.
What I can say is where my attention is. Import fidelity is the thing I return to most: every file that opens imperfectly is a person who cannot switch. After that, the slow parts of the engine, which are slow in ways I can measure rather than ways I can guess at. And then the long tail of behaviour that separates a tool you can use from a tool you want to use, which is mostly made of small corrections nobody writes a changelog entry for.
If you draw for a living, Scissor is not going to replace what you have today. If you have ever wanted to open a vector file on a borrowed laptop and change one colour, it already does that better than anything I had before.
That gap is the project. It closes one commit at a time.