The problem
Palette tools generally assume you know what you want and need somewhere to store it. That is backwards. Choosing colour is iterative and comparative. You arrive at a palette by putting candidates beside each other and discarding most of them, so the interesting problem is not storage, it is making iteration cheap and comparison honest.
What I built
Version control over palettes rather than a flat save. If iteration is the actual activity, then the history of a palette is part of the artefact, and being able to go back three steps without having kept a screenshot is the feature.
Real-time collaboration, because colour decisions are almost never made alone and the alternative is a thread of exported PNGs where nobody is sure which one is current.
An Express API over Prisma against SQLite. SQLite is a deliberate choice at this scale: the entire dataset is small, reads dominate, and the operational simplicity of a single file is worth more than headroom that will not be used. If it outgrows that, Prisma makes the move to Postgres a configuration change rather than a rewrite.
The interface is the product here in a way it is not for the other projects. A tool for people with taste is judged on its own taste, which raised the bar on every spacing and contrast decision in it.
A detail worth explaining
A colour tool has to be honest about contrast
The quiet failure in palette tools is presenting swatches in a context that flatters them. Colour is relational: a value that looks right in a 200px square can be unreadable as text, and a pair that passes beside each other can fail against the page they will actually sit on. Showing candidates in the conditions they will be used in, rather than as isolated squares, is the difference between a tool that produces palettes that look good in the tool and one that produces palettes that survive contact with a real interface.
Outcome
Colorra is deployed and in use for palette creation with versioning and collaborative editing over the Prisma store.