Chroma

Role

Solo end-to-end ⁠— research, product, design system, front-end & back-end; built with Claude Code

Client

Self-initiated product

Disciplines

Product · Design systems · Tooling · Front-end · Accessibility

Year

2025–2026

A colour tool I designed and built end to end: palettes from any image, WCAG contrast checks and eight export formats on one surface. It cut my own colour work from 3.1 to 1.0 hours per project (−68%). In 2026 I redesigned it around one object: a printer that prints your palette as a receipt

Problem
My colour work was scattered across 5–⁠6 disconnected tools and cost 3.1 hours per project
Insight
The pain wasn’t missing tools but the seams between them ⁠— one opinionated surface mapped to my real workflow
Solution
I solo-built Chroma end-to-end (research, design, React/TS frontend, FastAPI backend, DevOps): image + live-site extraction, WCAG matrix, OKLCh scales, 8 export formats, 25 days; in 2026 redesigned as a 3D printer I modelled in Cinema 4D, which prints the analysis as a thermal receipt
Outcome
My own colour work down to 1.0 h/project (−68%), €0 hosting ⁠— a small early sample

One surface for the whole colour pipeline

Colour decisions start almost every design project ⁠— client decks, brand audits, product UI, marketing. The work behind them lived across 5–⁠6 browser tabs: an eyedropper, an image extractor, a contrast checker, an exporter that never matched the format developers needed. Chroma collapses that into a single surface.

chroma.ontwrpn.com in 2026 ⁠— the printer redesign, idle and waiting for a photo

The seams between tools

A typical engagement: gather references, extract palettes, test WCAG contrast, build 50–950 tonal scales, hand off in the format the consumer actually uses. Each step lived in a different tool ⁠— Coolors, Adobe Color, contrast checkers, Figma plugins ⁠— and the outputs never lined up. Accessibility got checked too late. Baseline: 3.1 hours of colour busywork per project, audited across 12 shipped projects.

The pain isn’t the absence of tooling ⁠— it’s the seams between tools

Validate first, then build in 25 days

Discovery before code: a self-audit of 12 shipped projects (3.1 h average), 20-minute interviews with three people who work from my palettes, and structured walk-throughs of 8 competing tools. A second-order cost surfaced ⁠— the people downstream were re-deriving my palettes because the handoff format didn’t fit their tools. I then built solo through gated phases ⁠— alpha ⁠→ beta ⁠→ production ⁠— so the launch landed already proven on real work.

The receipt opens with the scan, then the palette by true pixel proportion

Extract ⁠→ balance ⁠→ check ⁠→ export

One web tool covering the whole lifecycle: image and live-site extraction (true pixel proportions, not generated samples), a live WCAG matrix with colour-blindness simulation, OKLCh tonal scales, and eight export formats including W3C design tokens. Built on Vite + React + TypeScript + Tailwind over FastAPI / Python.

chroma.ontwrpn.com — live preview
Live demo
chroma.ontwrpn.com
Open

Live ⁠— drop a photo or a site URL into the printer

One surface instead of six better tools

Every step in the colour workflow already had a stronger standalone tool than anything I would build: Coolors for palettes, Adobe Color for harmony, dedicated contrast checkers, Figma plugins for application. Assembling best-of-breed was the obvious move. It was also exactly what I was replacing, since the work lived across five or six tabs whose outputs never lined up and an exporter that never matched the format developers needed.

So the trade was explicit. Each feature is individually weaker than the specialist tool, in exchange for one surface covering the whole lifecycle where the outputs agree with each other. Extraction reads true pixel proportions rather than generated samples for the same reason: a palette that misrepresents the source image is faster and useless.

The test was the handoff, not the feature list: palettes had to reach decks and code without being re-derived, the two places the old five-tab workflow always leaked.

Shipped and measured

First two weeks on my own projects (a small early sample, n = 3, against a 12-project baseline): colour-work time 3.1 h ⁠→ 1.0 h (−68%), €0 hosting. Honest read ⁠— a tiny early sample, not re-measured since. The one known friction: website extraction (vs. image upload) takes 10–⁠12 s with no visible progress indicator ⁠— a loading state is on the backlog.

Redesign: the printer

In October 2026 I redesigned the whole product around one metaphor: a printer and its receipt. You drop a photo into the top slot of a light 3D printer, a red laser scans it, and a long thermal receipt prints out of the front slot with the full analysis ⁠— the palette by true pixel share, a donut, harmony, shades, the WCAG contrast matrix, colour-vision simulation and a tear-off export coupon. The engine underneath is the same; what changed is how it feels to use.

The redesign on the live site, in 34 seconds: a photo goes into the top slot, the laser scans it, the receipt prints, a HEX copies with the COPIED stamp. Dahlia photo: vultilion, CC BY 2.0

Process first. I collected receipt and thermal-printer references in Figma next to a capture of the live site, then drew greyscale wireframes on a small wireframe design system whose Figma variables switch every frame between a Wireframe and a Hi-fi mode. On top of that I drew three concepts: A “Lab” ⁠— warm concrete #CFCBC4, an off-white printer, paper #FBFAF7, ink #141414, a red scan laser #FF4D2E, set in Archivo and JetBrains Mono; B “Transmission”; and C “Cobalt”. I chose A, the quietest of the three, so the colour on screen belongs to the photo.

Scan: the photo stands in the top slot, the laser steps down it

Print: the receipt feeds out of the front slot

I built the 3D printer in Cinema 4D and rendered it with Redshift: a rounded shell with a panel cut, feet and two slot throats, lit by a softbox key, a fill, a rim and a dome. The page is the render. The DOM controls ⁠— source, colours, mode, tolerance, alpha ⁠— are overlaid on it at anchors measured on the render, so they sit exactly on the printer’s panel and stay real, keyboard-reachable HTML.

The printer, built in Cinema 4D

…and rendered in Redshift

Motion is mechanical rather than decorative: the scan moves in roller steps, the paper feeds out in thermal line steps, the body hums while it works and settles when it stops. The details are small and tactile ⁠— scan stages on the LED, a HEX scramble as values land, buttons that press in, a slot that glows on drag-over, a COPIED rubber stamp, a spring tear-off coupon for the exports, and receipts that can be shared by link.

Mobile: the panel folds down to a single row

Mobile: the same receipt, full width

Even the 404 stays in character: the printer reports a paper jam and prints a VOID RECEIPT for the missing page. Underneath the metaphor it is still built to WCAG 2.2 AA, with a 14px type floor, a strict CSP, and a printer sized to the viewport so the whole machine fits on the first screen.

404 on desktop: a VOID RECEIPT

404 on mobile

Next project
Axonis